The demo that sells peer-to-peer is always the same. Two devices. One message. Nothing of yours in between.
No database holding the conversation. No server to scale, patch or subpoena. Just two people, two keys and a direct, encrypted line. Earlier this year, when Circo was still deciding what kind of company it would be, that demo was hard to ignore.
This is the first in a series of field notes on taking decentralisation seriously at Circo. It starts with chat, because chat is where the idea first felt real.
Why P2P chat looked right in 2024
Circo was always going to be about the relationship between a creator and the people who show up for them. Video was the centre, but conversation was the connective tissue: a creator talking to their community, fans talking to each other, the private messages that turn an audience into a following.
Messaging is also the part of a platform that carries the most trust. Private conversations are the data you least want to hold, and the data people most expect you to protect. Every message you store is a liability you have agreed to carry forever.
Peer-to-peer offered a different bargain. If messages travel directly between the people in the conversation, end-to-end encrypted by construction, then the platform never holds them. You cannot leak what you never had. Costs scale with the users, not with your infrastructure bill. And the conversation belongs, in a very literal sense, to the people having it.
The timing helped. Holepunch had released the Pear Runtime as open source in February 2024: a platform for building peer-to-peer applications, with its own messaging app, Keet, as proof that the approach worked in the real world. This was not a research paper. It was a working stack you could pick up and build on.
So we picked it up.
What we actually explored
The Holepunch stack is built from a small number of ideas, each one well designed.
The foundation is Hypercore, a signed, append-only log. Each writer has a key pair. Everything they write is appended to their log and signed, and anyone reading it can check every block against a Merkle tree, so you can trust a message even when it reaches you through a stranger. A chat, in this model, is not rows in a table. It is a set of logs, one per participant, that peers replicate between themselves.
Group conversation needs many writers, which is where Autobase comes in. It takes the logs of everyone in a room and folds them, deterministically, into one shared view. Every peer that runs the same rules over the same history arrives at the same conversation. It is eventually consistent by design, which matters later.
Finding each other is the job of Hyperswarm. Peers join a topic, a 32-byte key, and the distributed hash table underneath connects them, punching through home routers so two ordinary devices can talk directly. Every connection is end-to-end encrypted.
And for a mobile product, the piece that made this plausible at all: Bare, the small JavaScript runtime underneath Pear, can be embedded in a native app. The same peer-to-peer code could, in principle, run inside an iPhone or Android app rather than only on desktops.
One message, peer to peer
→
→
→
→
The sender appends the message to their own signed log. Nothing is sent to a server; the log lives on the device.
One message, peer to peer
Write. The sender appends the message to their own signed log. Nothing is sent to a server; the log lives on the device.
Announce. The device joins the conversation's topic on the distributed hash table, so other members can find it.
Connect. Peers connect directly, punching through home routers where they can, over an end-to-end encrypted stream.
Replicate. The recipient downloads the new blocks and checks each one against the sender's signature before trusting it.
Merge. Every member folds all the logs into the same conversation, in the same order, on their own device.
Laid out like that, it is beautiful. The message is a fact the sender signed. Delivery is replication. The server is gone.
The questions the experiment forced
The value of an experiment is not the demo. It is the questions you cannot answer until you try to turn the demo into a product. P2P chat gave us a long list, and they were good questions.
Who is online? A peer-to-peer log is only available while some peer holding it is online. If I send you a message and close my laptop before your phone connects, the message has nowhere to wait. Holepunch's own answer, for Keet, is the blind peer: an always-on peer that stores the encrypted blocks it cannot read and hands them over when you return. That is a clever design, and it is also an admission. Offline delivery needs something that is always on.
Who are you? In this model your identity is your key pair. Lose the device and the seed phrase, and you lose the identity. That is a principled position, and it is the right one for some products. For a creator platform where people sign in, change phones and expect to recover their account, it is a different product.
What does a phone allow? Phones suspend background work aggressively to protect battery and data. A peer that cannot stay awake cannot relay, seed or receive. The network works best among devices that stay connected, and a fan's phone in their pocket is not that.
Who keeps the room safe? A creator community needs reporting, blocking and moderation. When every member holds the history, the question of what "removing" a message means gets genuinely hard.
None of these were reasons to stop thinking. They were the shape of the problem, and every serious P2P team is working on them. But they told us clearly what we would be signing up for.
The experiment still paid for itself. It taught the team to think of a message as a signed fact rather than a row. It made the offline case, the dull case everyone skips in a demo, the first thing we design for. It gave us a precise vocabulary for what "serverless" really means: not that nothing is always on, but that you do not own the thing that is.
Most of all, it taught me how I want my team to approach technology that excites us. Build the smallest real thing. Ask the questions a product will ask. Write down what you learned, especially when the answer is "not here, not yet".
Two devices, one message, nothing in between. It is still the best demo in networking. The work is everything the demo leaves out.