Secure messaging apps like Signal have set the gold standard for private digital communication. When you chat with someone, your messages are end-to-end encrypted, meaning only you and your conversation partner can read them. This is made possible by a clever cryptographic handshake that lets both parties generate shared secret keys, which evolve with every message. Even if someone intercepts the traffic, the encryption holds strong.
But while the content of the message is secure, the act of messaging itself is not invisible. To see how this exposure can lead to problems, consider the following example:
Suppose a journalist messages a source. The message content is encrypted, but a passive observer, perhaps a hostile government or a compromised ISP can still learn that these two identities communicated repeatedly at specific times. That pattern alone can be incriminating.
The above scenario is possible because Signal still relies on central servers to deliver messages and store pre-keys. This means that each time you send a message, your app connects to Signal’s infrastructure. And even though they are encrypted, the server still sees metadata, i.e. who you are talking to, when, and how often. And so does anyone capable of monitoring network traffic, such as ISPs, surveillance agencies, or even attackers watching Signal’s server logs.
Worse, under certain threat models, if an adversary compromises a device while it’s still active, the risk isn’t just theoretical. Encryption keys that were meant to be ephemeral and discarded after use might still be sitting quietly in memory, waiting for a scheduled sync or a user to come online, which is all the window an attacker needs.
Lets understand this attack with two journalists: Alice and Bob.
Bob, reporting from a remote region. While he’s offline, Alice, his confidential source, sends him four encrypted messages using Signal. No worries, right? Signal’s encryption mechanism ensures every message has its own unique key.
But just before Bob gets back online, his phone is confiscated at a border checkpoint. It’s still unlocked. The app is running. The memory, still warm.
The adversary doesn’t need to crack the encryption. They simply extract the residual keys, lying there unused. Suddenly, messages 2, 3, and 4 still unread become fully visible. What was meant to be forward-secret is now retroactively exposed. The clock, for a brief moment, rewinds.
Swarm flips the model entirely. Rather than treating messages as real-time packets to be delivered, Swarm stores them as encrypted content distributed anonymously across the decentralized network. Each message is broken into indistinguishable chunks and pushed into Swarm’s storage layer. Only someone with the right decryption key and location hint can ever retrieve or read them.
This article explores how Swarm doesn’t just improve privacy, but fundamentally redefines the rules of secure communication by eliminating the very surfaces attackers rely on. You’ll discover how Swarm enables asynchronous, real-time messaging without leaking a single bit of metadata.
We’ll introduce you to Trojan chunks, the stealthy heroes of this architecture that slip through the network camouflaged as ordinary data, delivering encrypted messages without revealing who’s talking to whom, or even that a message was sent.
We’ll dive into how personal outbox feeds allow users to publish messages without creating visible trails, how Swarm’s unique feed indexing protects against timing analysis, and how features like ENS usernames, Access Control Trees, and built-in mailboxing make the system private, scalable, resilient, and easy to use.
If you’ve ever wondered what rebuilding Signal for a decentralized world might look like, this is it.
The Trojan Horse of Metadata Resistance
Picture this: a city under siege, gates locked tight, enemies watching every movement. No messenger can enter without being spotted, no package delivered without suspicion. Then, one night, a wooden horse appears as a gift, seemingly innocent. It’s wheeled inside, carrying a stealth strike force that topples the city from within.
Now swap Troy for today’s internet, and the horse for Swarm’s Trojan Chunk.
In most messaging systems, even encrypted ones like Signal, adversaries can watch the gates. They might not see inside the messages, but they see who’s talking to whom, when, and how often. Like guards watching from the towers, they log every interaction: Alice messaged Bob at 11:42 AM, then again at 12:00, then again…
That metadata — the when, the who, the how often — becomes a trail. And trails can be dangerous.
But Swarm flips this paradigm. Instead of smuggling messages through the gates, it hides them in plain sight. When a message is wrapped in a Trojan Chunk, the data package looks just like a piece of any other file, an instagram reel, a pinteresty home decor image, or an archive. Using Swarm’s content-addressed storage, these chunks route naturally through the network, with no explicit sender or receiver metadata.
No Trails, No Tells
Now imagine the Greeks didn’t use a single horse, but disguised their messengers as traders, artists, or builders blending into the city’s daily rhythm. That’s how Swarm works.
When Alice sends Bob a message, she doesn’t create a direct connection. She doesn’t even announce she’s sending something to Bob. Instead, she mines a chunk, that is, she slightly tweaks its contents until its hash matches the Swarm address space near Bob’s node.
The network then routes the chunk like it would any other data. There’s no “message” header. No recipient ID. No visible envelope. Just bytes.
Later, when Bob’s node syncs, it finds the chunk, decrypts it with his key, and discovers: a message from Alice.
To everyone else, including the nodes, it’s just more data. Only Bob knows it’s a message. Only he holds the key to unlock it.
Obfuscating the Attack Surface
This subtle disguise isn’t just clever, it erases the attack surface.
In a traditional setup, observers can trace message flows. They see when two nodes communicate. They can monitor frequency and timing. And if they compromise one device, they might even glean clues from past metadata or unrotated keys.
Swarm’s architecture denies them that opportunity. Here’s how:
No observable flows: Messages are stored and retrieved like files, with no “send” or “receive” events to watch.No identifiable addressing: Chunks are routed based on hashes, not node IDs or IPs. No one knows who it’s meant for, not even the node carrying it.No access patterns: Senders can randomize or mine indexes making it nearly impossible to track how many messages were sent or when.No linkability: Without knowing the shared secrets, a message chunk is indistinguishable from random data.
Trying to trace Alice and Bob’s communication is like sifting through the ocean for a bottle with an invisible message that only glows after you know the exact wavelength.
A Story of Rethinking the Problem
This idea wasn’t in the original blueprint. Early on, the team assumed messaging would involve direct communication between nodes, just like most systems today. But direct node-to-node messaging comes with a fatal flaw: visibility. Even with encryption, observers can still monitor communication patterns. And over time, such metadata becomes a goldmine for profiling and surveillance.
Then came the epiphany: What if messaging wasn’t messaging at all?
The Swarm team began to ask themselves: Could a message pretend to be storage? Could the file system itself do the talking?
From this spark came the Trojan Chunk. They realized they could piggyback on Swarm’s existing storage protocols, using the same infrastructure meant for documents or media to also carry private conversations.
And with a clever sleight of hand, the messaging problem was inverted:
No special protocol.No inboxes or mail servers.Just data… hiding in plain sight.
Bootstrapping a Secure Conversation
Before two people can chat securely, they need to agree on a shared secret key. Signal solves this using the X3DH (Extended Triple Diffie-Hellman) protocol. It’s designed for asynchronous communication: Bob can be offline, yet Alice can still initiate a secure chat by grabbing a bundle of Bob’s public keys and encrypting the first message in a way only Bob can decrypt.
In the classic Signal setup, these pre-key bundles live on a central server. In Swarm, users publish their pre-key bundles to Swarm feeds — think of them as decentralized, append-only bulletin boards. Each bundle includes an identity key, a signed pre-key, and a set of one-time-use keys. Optionally, this can be tied to an ENS name like alice.eth so you don’t have to deal with cryptographic hashes to find someone.
When Bob wants to initiate a chat with Alice, he looks up her Swarm feed (perhaps via alice.eth), downloads her public keys, and performs the X3DH computation locally, combining his own ephemeral keys with hers to derive a shared secret. This secret will seed the encryption keys for the rest of their conversation.
The tricky part? Delivering that first message when Alice might be offline.
Enter PSS, or the Postal Service over Swarm. It’s a messaging mechanism that disguises private messages as ordinary Swarm data traffic. Alice wraps her encrypted handshake in a Trojan chunk that looks like any other piece of uploaded content, but whose hash prefix has been carefully crafted to route it near Bob’s node.
The Swarm network doesn’t recognize it as a message, it just stores and routes it like regular content. Only Bob, using his private key, can decrypt the payload when his node syncs. There’s no inbox, no direct connection, and no metadata trail. From the outside, it’s as if nothing happened at all.
With this, Alice and Bob have achieved mutual authentication, forward secrecy, and even deniability; no one can prove they communicated, and neither party can be impersonated.
Outbox Feeds: Decentralized Mailboxes for Real-Time Messaging
Once Alice and Bob establish a shared secret with X3DH, they shift into Double Ratchet mode, the same method Signal uses to ensure every message is encrypted with a unique key. If a key is ever compromised, the rest of the conversation stays safe. This gives both forward and future secrecy.
But how do they exchange these encrypted messages on Swarm?
Rather than sending messages directly, Swarm lets users post encrypted messages to outbox feeds, personal, append-only timelines. Think of these as personal mailboxes that live entirely on the decentralized storage network. Alice writes her messages, encrypts them, and drops them into a feed, a kind of digital dead-drop that Bob knows how to find and decrypt.
Here’s how it works in practice:
Each user maintains an outbox feed, essentially a stream of signed, append-only updates stored as Swarm chunks.These updates are cryptographically tied to the sender and ordered by sequence number, ensuring integrity and proper ordering.After their handshake, Alice knows the address of Bob’s outbox feed (and vice versa) which could be derived from their public keys, shared secret, or even an ENS name like bob.eth.
So, when Alice wants to send Bob a message:
She encrypts the message using her Double Ratchet key, ensuring forward secrecy.She posts the ciphertext as a new entry in her outbox feed for Bob.Bob’s node watches that feed or checks it periodically and sees a new update.Using the ratchet state he shares with Alice, he decrypts it.
To make delivery feel instant, Alice can optionally send Bob a Trojan chunk ping, alerting him that a new message is waiting at index X. The message itself lives on the feed; the Trojan just rings the doorbell.
Now here’s the clever part: the feed’s address and indexing can change with every message. Swarm supports randomized indexing, which breaks predictable patterns. Even better, each encryption key from the Double Ratchet can influence where the next chunk is stored, so only Bob, who shares the secret, knows where to look.
Imagine Alice and Bob as secret agents in Paris, exchanging messages through scraps of paper tucked into hidden drop boxes. Alice never tells Bob where the notes are — she doesn’t need to. One might be folded into a chocolate wrapper behind the florist, another under a baguette crate at the bakery, or scribbled on a cinema ticket tucked into a sugar jar.
Bob knows where to look. He might find three notes at once — under a doormat, behind a metro tile, or slipped into a secondhand book. Each message is numbered, signed, and encrypted, waiting silently until he retrieves it.
To everyone else, these are just paper scraps or forgotten clutter. But to Bob, a cracked tile or folded receipt is a signal: something mundane, hiding something extraordinary.
Conclusion: Swarm’s Value Proposition for Secure Messaging
By building Signal-style encryption on top of Swarm, we marry proven cryptographic security with a decentralized, censorship-resistant infrastructure. The result is a messaging system that’s end-to-end encrypted, features forward secrecy and where the network itself learns nothing about the communication. There are no central servers to trust or attack.
Messages are leak-proof, an eavesdropper can’t even tell you are sending a message, let alone to whom or what it contains, because it just looks like random chunks of data flying around.
Users are identified by cryptographic address or pseudonyms, preserving anonymity at the network level. And yet, the experience can feel instantaneous. Through the combination of Trojan chunk pushes and feed updates, messages arrive as fast as the network can propagate them.
Swarm enables asynchronous, privacy preserving communication without any direct node-to-node messaging or proprietary servers. This architecture is resilient as long as the Swarm network is up, your messages will get through and your data will persist. It’s also censorship resistant, there is no central point to block or subpoena messages and since content is encrypted and indistinguishable, it’s nearly impossible to target specific communication for censorship.
Every message is just another chunk in a sea of content-addressed data indistinguishable from a photo, blog post, or backup file.
This is privacy not just in message content, but in message existence.
And for developers? The implications are massive. “Signal on Swarm” unlocks the possibility of having truly decentralized social apps, wallet messaging or dApps communicating confidentially, all built on public infrastructure. Imagine a dApp where your account’s ENS name is also your messaging handle, anyone can drop you an encrypted message via Swarm but only you can read it. You don’t need their phone number or IP address.
It’s like having the privacy of an encrypted email, the immediacy of a chat app and the resilience of BitTorrent, all in one. And because it’s all Ethereum aligned, your identity, messaging and data storage can all tie together seamlessly under your control.
Signal on Swarm was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.