Built to Outlive Its Storage, Group Chat on Base with Signal-Family Encryption

When you send a photo in a group on Base ■, where does it live? The answer should outlast the answer.

When you send a photo to a group chat in ANO on Base, the question you’d expect a developer to obsess over is “where does the file live?”

The answer is: somewhere that doesn’t matter. The chain holds a pointer and a small encrypted fragment for each person in the group. The bytes live in some content store. Which content store is a deliberate non-decision? The architecture is designed so that wherever the bytes are hosted, the privacy guarantee is identical.

That’s the whole story. The rest is unpacking why this matters.

The principle

The chain holds the access list. The storage holds the locked box. The storage is pluggable on purpose.

The chain is where consensus belongs. Who can read this message, at what timestamp, as part of which group. Tiny, public, auditable, censorship-resistant. The chain does what chains are good at and nothing more.

The storage is where bytes belong. Megabytes of ciphertext, opaque to whoever hosts them. Could be a centralized bucket fronted by a CDN today. Could be IPFS tomorrow. Could be Arweave or Filecoin or self-hosted the day after. The protocol doesn’t pick a winner because picking one would be a bet against the others, and the entire point is that the bet doesn’t need to be made.

BASE MAINNET
            [pointer + per-member keys]
                      │
                      ▼
         ┌────────────────────────────────┐
         │       BLOB STORAGE             │
         │     (pluggable backend)        │
         ├────────────────────────────────┤
         │                                │
         │  ┌──────┐ ┌──────┐ ┌────────┐  │
         │  │ IPFS │ │ S3   │ │Arweave │  │
         │  └──────┘ │ +CDN │ └────────┘  │
         │           └──────┘             │
         │                                │
         │  Privacy comes from the        │
         │  encryption layer.             │
         │  Storage is implementation.    │
         └────────────────────────────────┘

The cryptography is in the Signal family

For 1:1 messages, we use the same shape Signal made famous: a per-message ephemeral key encrypts the content, the key is wrapped with the recipient’s public key, only the matching private key can unwrap it. Standard, well-studied, broadly considered the gold standard.

For groups, Signal uses Sender Keys: each member holds a long-lived sending key, distributed pairwise to other members. When membership changes, keys rotate. Beautiful design, more complex implementation, optimized for large groups.

ANO ships the simpler variant of the same family: a fresh symmetric key per message, individually wrapped for each member. Same forward-secrecy property as Sender Keys, simpler state, gets us to shipped today. When average group size hits ~20 members, we’ll graduate to Sender Keys. Until then, per-message wrapping is the right cost/complexity trade.

The point isn’t which variant we use. The point is that cryptography is in a lineage that has been audited, attacked, and validated for over a decade. No novel crypto. No clever tricks. Just the well-trodden path.

Storage-agnostic by design

The chain payload for a group attachment is small. It carries a pointer string, the IV, an array of wrapped keys (one per recipient), and basic file metadata.

The pointer is the interesting bit. Today, it’s a path into a centralized object store. Tomorrow, it can be an IPFS CID, an Arweave transaction ID, a Filecoin deal reference, or a self-hosted URL. The chain doesn’t know or care. The recipient code doesn’t know or care. Whoever hosts the bytes just has to respond to a fetch with the ciphertext.

This isn’t a hypothetical. The protocol already accepts any string in the pointer field. The frontend will fetch from whatever backend the project routes to. Adding IPFS as a primary or fallback backend is a one-file change in the frontend and a deployment change in the backend. Zero protocol-level work.

We use a centralized backend today because content-addressed storage networks (IPFS, Filecoin, Arweave) are doing meaningful work to make decentralized hosting performant and economically sustainable, but they’re not yet at messenger-grade latency for hot reads. When they are, the architecture is already there to graduate. Until then, the encryption layer makes the storage choice cosmetic from a privacy standpoint.

Why this matches the IPFS, Filecoin, and Arweave bet

Those projects are tackling the hard problem that consumer crypto needs solved: how do you store user-generated content in a way that’s verifiable, censorship-resistant, and economically self-sustaining? It’s slow work. It’s the right work.

ANO is built to ride that wave. The moment IPFS-pinned content can be fetched at sub-100ms reliably, or Arweave’s economics make daily messenger files affordable, or Filecoin’s deal lifecycle becomes seamless for one-byte reads, we point our pointer at them. Users who want operational decentralization today can already self-host an IPFS pin and route ANO to it. The protocol is ready before the infrastructure is.

We think this is what coexistence between centralized infra and decentralized infra looks like in 2026: not one camp winning the argument, but applications designed to graduate from one to the other as the math changes.

What WhatsApp and Telegram hold that ANO doesn’t

Other e2e messengers do the encryption well. WhatsApp uses the Signal Protocol for cryptography, which is in the same family as ours. What’s different is everything around the encryption.

WhatsApp holds: phone number · contact graph · iCloud backups (often plaintext) · group membership state · admin account recovery

Telegram holds: phone number · contact graph · all message history in Telegram cloud (default chats) · group state · account recovery

ANO holds: nothing. Identity is your wallet. Backups are encrypted with a key only you know. Group membership lives on-chain. No admin recovery exists because there’s no admin.

ANO holds nothing about you that you didn’t put there yourself, and even what you put there is encrypted before it leaves your device. There’s no “ANO admin team” with master keys. There’s no platform that can ban you, recover your account, or push a protocol-changing update overnight, because the platform is a static PWA and the protocol is contracts on Base that we don’t control unilaterally.

This isn’t about which messenger has stronger encryption. The encryption is comparable across all serious players. It’s about which messenger has the fewest things stacked on top of the encryption that you have to trust.

What an attacker actually sees

Honest breakdown by layer.

Looking at the Base chain: a transaction happened. A group ID. A file size. The number of envelopes (equals group size at send time). Visible: that something was sent. Not visible: content, file type, which envelope is which recipient.

Looking at the storage layer (whoever hosts the ciphertext, today centralized, tomorrow potentially IPFS): an encrypted blob. The byte size. The fetch time. Subpoena it, breach it, leak it. You get garbage.

Looking at the network layer (an ISP, a national firewall): that you talked to Base, that you fetched some bytes from a CDN-shaped endpoint. Not the group, not the file, not the content.

Looking at the recipient’s device: everything they downloaded, in plaintext. This is the unsolvable problem in every messenger ever built. ANO doesn’t fix it. Nobody can.

Three of four layers are opaque to attackers. The fourth is the endpoint, which is true of every messenger.

Why Base specifically

Per-recipient encryption only works at scale if calldata is cheap. A 20-person group costs a fraction of a cent per message in Base calldata. On the Ethereum mainnet, the same architecture would cost a few dollars per group message. On Bitcoin or any L1 that isn’t optimized for cheap calldata, it wouldn’t work at all.

We didn’t pick Base because Coinbase is the parent company. We picked Base because the architecture we wanted to build only works on a chain where N-envelope group messages are essentially free, and Base is the chain where that math holds.

Try it

Open ANO. Add it to your iPhone home screen from Safari, no app store gate, no install permission. Join a group, send a photo, then look at the Base transaction your phone just made. You’ll see a small JSON payload with a pointer and an array of envelopes. Click the pointer URL. You’ll get bytes of garbage.

That’s the whole architecture. Encrypted before it leaves you. Stored wherever’s reasonable today. Designed to outlive whatever’s reasonable tomorrow.

→ ano.ww8.io on Base mainnet, real chain, self-custody, end-to-end encrypted.