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
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 download a third-party wallet, scan their passport, or understand what ZK 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. And even so, sometimes they tend to be extra careful with login, and they want none at all.
While ZK must be part of the solution, we learnt that 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 participant input, run analysis 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 anonymity
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 or verifying any credential. This is especially common during events or within closed communities. Minimizing friction for these users matters. We also need to support ticket-gated participation (using Zupass) 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 lighter on Nostr and Logos Messaging — no PDS to provision, no PLC directory to register with, no repository to initialize.
Logos Messaging is especially well-designed for this use-case because it is key-scheme agnostic at the protocol layer: the application is free to decide how to identify its users.
Unlike Logos Messaging, Nostr enforces the use of secp256k1. This means that without third-party wallets, on the Web private keys are unavoidably exposed to JavaScript, since non-exportable key storage is only available for Web Crypto-supported curves (P-256, Ed25519). That's an unacceptable security risk.
Someone who votes once at an event shouldn't need the same infrastructure as a committed user. They shouldn't be asked to download anything. Just scan a link and go.
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 (fully integrated in the protocol, notably with moderation tools such as Ozone, 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.
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: On standard AT Protocol, your PDS operator holds your Rotation Key — you only truly own your identity if you self-host, and most users won't. DDS proposes to fix this with an Encrypted Key Vault — a reusable component for the AT Protocol ecosystem, still work-in-progress and requiring serious security review. The vault stores the Rotation Key encrypted, client-side, in your AT Protocol repository, archived to decentralized storage. Different modes serve different users: web3-native users can bind their recovery key to an external wallet; web2 users get a device-based key graph. 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 analysis — whether clustering (PCA, Reddwarf), LLM-based sensemaking, or other methods — 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) — is an iterative loop. Plan defines the consultation: which modules, which rounds, who participates, how analysis from one round informs the next. A community platform plans. A deliberation tool collects. An Analyzer processes. Multiple Analyzers can compete on the same data; multiple collection streams can feed one analysis. Rounds repeat until the consultation is complete. What happens with the results — a binding vote, a DAO proposal, a published report — is outside DDS, handled by external systems that consume the outputs. Different apps handle different parts, composing 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.
Classic server-based self-hosting — each organization running its own isolated instance, à la pol.is — is not in our roadmap. It's already been done, and it's not as easily interoperable as AT Proto, because data is siloed and its semantics are not standardized.
On AT Protocol, self-hosting means running the full decentralized stack (PDS, Relay, AppView), which is always possible — all components are open source and every user's data lives in their PDS. But the real value is in the shared network: open, semantically structured data across a common transport. And the advantage of open data is that it's not just organizations self-hosting for their own benefit — the entire community can run whichever components make sense for them, while the shared data lake stays alive.
Open data and business models
A natural concern: if all deliberation data is public, how does anyone build a sustainable business? The answer is that AT Protocol is orthogonal to charging. Every component in the stack — AppViews, Feed Generators, Labelers, PDS hosts, Analyzer Agents — can independently offer paid services. Bluesky itself sells subscriptions. Third-party developers already monetize custom feeds. The data transport is open and standardized; the services built on top of it are not. This is no different from how the web works: HTTP is open, but web services charge money.
Conversation privacy
Conversation privacy — restricting who can participate in a deliberation — is a separate concern from participant anonymity (hiding who said what). It's a practical need: organizers often want frictionless conversations (no login) restricted to invited people only.
The common case is participation-gated: the conversation is publicly viewable, but only link-holders can submit opinions and votes. The goal is to gate the conversation to a specific crowd while providing a seamless experience witout any login friction whatsover. This could work by embedding an asymmetric signing key in the share link (URL fragment, never sent to server), only known to the organizer initiallly, and sharing the public counterpart to the network. Then the organizer shares the link to their target community, and when participants start, their browser sign their submissions automatically. Only valid signatures are accepted by the network.
A rarer mode — restricted conversations (not even viewable by outsiders) — could use encryption instead, with a symmetric key embedded in the link. AT Protocol currently only handles public data, so our long-term priority for restricted conversations is end-to-end encryption (Signal model) — research in this direction is already underway in the AT Protocol community. That said, this use case is marginal.
Why not pure AT Protocol?
DDS is built on AT Protocol, not exclusively within it. Each layer uses the protocol best suited to its role.
More broadly, DDS is designed to complement voting protocols — systems like Vocdoni's DAVINCI that handle secure, anonymous, verifiable decisions. The collaboration point is shared semantic data: DDS consultation results could inform what gets voted on, and election results could flow back into the shared data lake via AT Protocol lexicons. Each system keeps its own infrastructure; interoperability happens at the data layer.
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.
Guest accounts on AT Protocol
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 but second-class citizen so it wouldn't be supported by tools like Ozone, etc).
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.
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
