We've been building Agora — a platform for public deliberation using Polis-style clustering — for a while now. Along the way, we've written about what we think about Nostr, AT Protocol, Polis, Community Notes, and protocol interoperability. Those posts are somewhat outdated now. This one describes where our thinking has landed — and why we're proposing the Decentralized Deliberation Standard (DDS) as an open protocol for deliberation, built on AT Protocol.
Where we started: Racine and the ZK-first approach
Our first protocol idea was Racine — a meta-protocol for verifiable provenance, designed to be transport-agnostic. It worked with Logos Messaging (then called Waku), Nostr, AT Protocol, IPFS, or plain HTTP. The core idea: use zero-knowledge proofs as the root of identity. A ZK nullifier derived from a real-world credential (biometric passport, verifiable credential) acts as a privacy-preserving, one-human-per-account identifier. No email, no phone number, no social login. Just math.
We still believe this is the technically superior approach for privacy. ZK anonymous identity solves real problems: Sybil resistance without surveillance, credential verification without disclosure, participation without identification.
Racine also supported verifiable moderation in a centralized context — using did:key identities and UCAN, a platform could monetize data access while providing cryptographic transparency about its moderation decisions. This is how Agora works right now. We no longer think this is the right approach for us. From a business perspective, the value we deliver isn't just in product or technology — it's in knowledge, network, human assistance, reputation, and community. That realization led us to fully embrace open data. Even though Racine could work with open data, for the reasons above and below, it's no longer our path.
What we learned: the adoption gap
But we kept running into the same wall: users don't adopt products this way.
People want to sign up with their email. Or their phone number. Or "Sign in with Google." They don't want to manage cryptographic keys, scan QR codes for device pairing, or understand what a ZK nullifier is. We believe we'll get there one day, but the market is far from ready.
We also encountered credential fragmentation. Each protocol has its own identity system, its own key format, its own account model. Building a meta-protocol that bridges all of them is theoretically possible — we loosely designed it in theory with Racine — but in practice, the integration surface is enormous and the R&D required to make it work would be excessive for our small team.
The lesson wasn't that ZK is wrong. It's that ZK anonymous identity is the wrong default for a public deliberation platform. The participants who need hard anonymity, whistleblowers, activists under authoritarian regimes are a real but niche use case within the broader deliberation space.
ZK MUST be part of the solution, but the whole authentication system cannot reliably be built on ZK alone, and hard-privacy isn't the most important to optimize for. What matters more is ease of use, flexibility, interoperability, transparency and verifiability.
Why AT Protocol
We evaluated three protocol families seriously: AT Protocol (Bluesky), Nostr, and Logos Messaging (formerly Waku).
What convinced us about AT Protocol wasn't any single feature — it was that the problems we'd need to solve to build deliberation infrastructure were already solved at the protocol level:
-
Identity with recovery:
did:plcseparates Signing Keys (for posting) from Rotation Keys (for migration). Nostr ties identity to a single keypair — lose it, and you lose everything. Logos Messaging has no identity layer at all. -
Composable architecture: AT Protocol's AppViews, Labelers, and Feed Generators aren't just features of Bluesky — they're pluggable components that any team can build and any user can choose. An Analyzer component can be built on the Feed Generator pattern. A moderation service can be built as a Labeler. Each connects to the same Firehose. This is separation of concerns as a protocol primitive.
-
Schema enforcement: Lexicons are machine-readable and PDS-enforced. If data doesn't match the schema, it's rejected — not silently malformed. Nostr's event kinds and Logos Messaging's content types enable interoperability through convention, but without enforceable validation.
-
Complete data stream: The Firehose gives every connected service a complete, real-time view of all data. In Nostr, each relay sees a partial view. In Logos Messaging, messages are ephemeral. For deliberation — where you need to aggregate all votes, run clustering algorithms, and produce verifiable results — a complete input stream is essential.
-
Web2 UX: OAuth login, handles, familiar account management. Users don't need to understand cryptography to participate.
-
Public social graph as input: AT Protocol is built for pseudonymous accounts with persistent social graphs — and unlike Nostr, it has mainstream adoption. Public figures have official Bluesky accounts. For deliberation, this is a unique asset: their public posts can be imported as inputs to opinion mapping — "how do personalities think about X?" becomes a query over AT Protocol data, not a manual curation exercise. Building on a protocol with an existing, active social graph means deliberation doesn't start from zero.
Building all of this on Nostr or Logos Messaging would mean reinventing most of what AT Protocol already provides.
Where Nostr and Logos Messaging genuinely excel
Hard privacy
Nostr's client-relay architecture enables routing through Tor and mixnets. Logos Messaging's P2P gossip means no server ever knows a user's identity. For applications requiring deep anonymity — ZK-anonymous voting, whistleblower platforms, censorship-resistant communication under authoritarian regimes — these protocols are the right foundation. Anonymity feels native on them.
Hard privacy can be implemented on AT Protocol, but the PDS pattern is an anti-pattern for strong ZK-anonymity. The server inherently knows the user's identity. Anonymity requires workarounds rather than flowing naturally from the architecture.
However, our experience with our end-users taught us that hard anonymity is not the default to optimize for. For most users, a pseudonymous account with full history across conversations is more useful than per-conversation unlinkability. But some use cases — like ticket-gated conference conversations — genuinely need per-context identities. The protocol needs to support both, and AT Protocol's identity model makes the anonymous path harder than it would be on Nostr or Logos Messaging. It's good to know we CAN optimize DDS for it, and it's an area where we expect the design to evolve.
Ephemeral identities ("Guest" accounts)
Deliberation tools often have one-off participants: people who arrive via a shared link, vote on a few statements, and leave — without ever creating an account. This is especially common during events or within closed communities. Minimizing friction for these users matters. We also need to support credential-gated participation (Zupass event tickets) and imported data from external sources: existing pol.is conversations, third-party consultation tools like LLM-based listening platforms, or social media APIs.
Ephemeral identities are frictionless on Nostr and Logos Messaging. A conference attendee generates a keypair and votes — no PDS to provision, no PLC directory to register with, no repository to initialize. The identity is as lightweight as the interaction. This matters for guest participation: someone who votes once at an event via a Zupass ticket shouldn't need the same infrastructure as a committed user.
AT Protocol's PDS model — which gives us Labelers, Firehose, and schema enforcement — also makes throwaway identities more expensive. How to handle this gracefully is an open design question for DDS: whether to use managed did:plc accounts even for guests (simpler moderation, but heavyweight), did:key "soft accounts" within the lexicon data (lightweight, but harder to upgrade and second-class in the AT Protocol ecosystem), or some hybrid.
Each has real trade-offs, particularly around upgrading a guest into a permanent account and around per-conversation anonymity for credential-gated deliberations (Zupass event tickets).
The Decentralized Deliberation Standard
DDS is our proposal for a vendor-neutral protocol for public deliberation. It's not just for Agora — any app can build on it.
The design is organized around four tensions:
-
Ownership vs Convenience: Users own their cryptographic identity (Rotation Keys) without needing hardware wallets. An Encrypted Key Vault stores the recovery key — encrypted, client-side — in their AT Protocol repository, which is archived to decentralized storage. If the provider vanishes, the key is still yours. The design goal is to pass Vitalik's "Walkaway Test" — if all providers disappear, can users still recover?
-
Discoverability vs Durability: AT Protocol handles the hot path (real-time search, discovery, interaction). Arweave/Filecoin/Logos Storage handles the cold path (archival, walkaway recovery). Best of both worlds.
-
Provable vs Economical Computation: Running clustering analysis (PCA, Reddwarf) is expensive. DDS separates computation from verification — Analyzer Agents publish results that anyone can independently verify by re-running the same algorithm on the same public inputs.
-
Autonomy vs Interoperability: Apps define their own data formats (product lexicons) while sharing a common base (base lexicons). A deliberation platform, an analysis engine, and a voting app can interoperate without bilateral agreements — each reads the other's data from the Firehose.
The deliberation lifecycle — Plan → Collect → Analyze → Execute — is designed so different apps can handle different phases. A community platform plans. A deliberation tool collects. An Analyzer processes. A voting app executes. They compose permissionlessly via shared lexicons.
Why open data?
DDS publishes all deliberation data to the Firehose in plaintext. This is a deliberate choice, not a limitation. The goal isn't just interoperability between Polis-like tools — it's interoperability across all governance and collective intelligence solutions: voting apps, DAO governance, participatory budgeting platforms, and tools that don't exist yet. Open data on a shared transport enables an ecosystem that siloed, self-hosted systems cannot.
Self-hosting is preserved as a walkaway option — the protocol guarantees you can run your own PDS if you need to — but it's not the default deployment model. The value is in the shared network. Private conversations are a future goal: AT Protocol is actively working on end-to-end encryption (Signal model), and when available, DDS could support private or restricted deliberations. But most deliberation is public, and transparency is the point.
Why not pure AT Protocol?
DDS is built on AT Protocol, not exclusively within it.
The verification layer uses Ethereum. Archival uses Arweave/Filecoin/Logos Storage. Each layer uses the protocol best suited to its role.
What's next
DDS is a draft. The cryptographic mechanisms (Encrypted Key Vault designs), verification layer (on-chain proofs), and security model need formal review and prototyping. The full spec is on GitHub.
Our immediate roadmap prioritizes AT Protocol compatibility — specifically, supporting the different ways users already log in to Agora (email, phone, guest, ZK passport) as PDS authentication methods.
A key design challenge is guest accounts: Agora currently uses device-bound did:key identities for unverified guests, with an account merge operation when they upgrade to a real account.
On AT Protocol, we need to decide whether guests get managed did:plc accounts (full compatibility but heavyweight, and merge is still needed if they later create a separate verified account), or did:key "soft accounts" within the data (lightweight, supports per-conversation anonymity, but needs moderation adaptation and a more complex upgrade path).
We also need to support data flowing in from external sources — other deliberation tools, social media APIs — where participants may not have AT Protocol identities at all.
This "Guest Mode" for AT Protocol accounts is a design problem worth solving at the protocol level — it's not just a DDS concern, and we'd love to see it become a reusable pattern. That's where the practical work starts.
We're also looking at on-chain result commitment — when a consultation finishes, the Analyzer Agent commits a hash of the inputs, algorithm, and outputs to Ethereum. This makes results permanent and tamper-evident without requiring expensive on-chain computation. Anyone can verify by re-running the open-source algorithm on the public Firehose data and comparing against the on-chain hash. This is inspired by how Vocdoni notarizes election results on Ethereum, adapted to DDS's architecture where AT Protocol serves as the data layer and Ethereum as the commitment layer.
Why now?
We've spent our time so far focused on UX, using ZK-login for pol.is conversations, augmenting pol.is with LLM capability for sensemaking, and on funding a community-owned, simple, modular Python rewrite of the underlying pol.is algorithm — all in service of delivering value to real users who care about having better conversations, not about interoperability or decentralization in the abstract. We're now at a stage where we have a valuable product and actual users, and we want to interoperate with other tools in a standardized way.
We also have growing interest from the DAO and web3 ecosystem — communities that understand and value this kind of development, as opposed to most of the population who don't think about these issues until centralized platforms fail them.
We've always been at the crossroad of DWeb, SSI, Privacy Tech, Web3 and Civic Tech, and we're proud to be one of the few doing this hard work. If you're interested in contributing — ideas, code, or just conversation — we'd love to hear from you.
The journey from Racine to DDS taught us that the best protocol isn't the most technically pure — it's the one that matches how people actually use products while preserving the option for sovereignty when it matters.
Acknowledgements
Special thanks to Puja and Boris for inspiration.
Written by Nicolas Gimenez
