What ATProto Needs to Support Consentful Distributed Community Governance

This is a working draft. The current version is heavily LLM-assisted and I haven't fully rewritten it in my own voice yet as I try to do before publishing anything, but the speed at which the conversation is advancing vs the speed of my perfectionism, I thought it best to publish something before I was comfortable doing so. Expect that I'll be making revisions to remove any AI slop that is likely present. (Like tamping down on that academic voice. ugh. Also if I've cited you inaccurately, lmk and I'll correct straight away.)

This document started as LLM code project documentation for a consent-based governance protocol+app for cooperative and distributed organizations I'm calling "Groundwork". (More on that in the next few weeks.)

While it started a few months ago as a higher level explanation of my views on collective agency and how they should inform product design, it's evolved into my reasoning behind what I think ATProto needs from the permissioned data spec to be the right substrate for communities to define their own governance systems and exercise collective agency, rather than adapting to the implicit governance assumptions baked into the tech they use.

Robin Berjon said it at Eurosky last year: "The properties that define the architecture of a protocol and those that define the rules in an institution are the same." Laurens Hof followed that thread in Where Does Community Live?. Protocol decisions aren't neutral. They shape which kinds of communities can form, which kinds of governance are possible, and which are foreclosed.

This document is about one gap in that institutional design: governance infrastructure for distributed communities. What such infrastructure needs to do, what properties it must have, what processes it must be able to express and record, and what that means for ATProto specifically.

This conversation has been building for a while and across a lot of people. baldemo.to organized a working group proposal that mapped the problem space and named the risk clearly: if one approach to community infrastructure wins out as a protocol standard, "its design can inadvertently foreclose others through implicit defaults that go unexamined until a group or community with different needs tries to build on it. Constraints become semipermanent once baked into a standard." The window to shape those defaults is before they calcify.

Four parts follow: what distributed communities actually require from governance infrastructure (the needs); what any adequate governance system must have (the properties); the acts governance infrastructure must be able to express and record (the processes); and where the governance layer needs to go and what the protocol needs to support (what this means for ATProto).

Mosh Lee put it plainly in Building for Organizers: "the most enduring social networks aren't the prettiest or the most addictive. They're the ones that empower organizers." Erlend Sogge Heggen has been making the same case through On-protocol Organizing. Organizers and builders need each other, and builders have too often forgotten who they're building for.

The organizers I'm thinking about (union stewards, cooperative members, mutual aid coordinators, community builders, cultural community leaders) have governance needs that current infrastructure was never designed to meet. Nathan Schneider identified the root of this in Implicit Feudalism: the Internet has a technical and cultural bias toward generating absolutist fiefdoms. "Most neighborhood garden clubs have something similar [to bylaws and governance structure]. Most online communities do not." Communities with genuine governance traditions (consent-based, distributed, accountable) are forced to either adopt feudal infrastructure or build from scratch with no shared primitives.

Consent-based authority. In many governance models, authority isn't assigned from above. It's offered to a person who chooses to accept it, through a process the group has agreed to. A consent ceremony is the act of making that offer, deliberating on it, and recording the outcome. The difference between "you have been added to the admin group" and "you have been offered this role, here is what it carries, do you accept" is a difference in authorization model: one treats people as agents, the other treats them as resources. The infrastructure must express that distinction and record that it happened.

Accountability through provenance. A governance record that says "Alice is the moderator" is less useful than one that says "Alice was offered this role on this date, accepted it through this process, with these specific authorities, traceable to this chain of prior decisions." The provenance of authority (the auditable record of how it came to exist) matters for trust, dispute resolution, legal accountability, and the basic question of whether governance is real or performed. An audit trail is what accountability requires.

Cross-boundary federation. Distributed communities don't exist in isolation. A coalition of mutual aid organizations, a network of gaming guilds, a research collaboration all require recognizing authority across organizational boundaries without either organization surrendering sovereignty to a shared platform. That requires record types expressing "this circle recognizes the authority of that circle's members in this specific context," not just "these DIDs have access to this space."

Portability of governance history, not just data. Platform dependency is a governance risk. When decision-making history lives in a server database, organizational continuity depends on that server staying up and that company staying honest. Communities have been destroyed by platform decisions that erased their governance context, even when the underlying data survived. Migration must carry history, not just current state.

Deliberate control over all participant types. Communities need enforceable decisions about who and what participates in their governance: humans, institutions, automated systems, AI agents. The question is what specific capabilities a participant holds in a specific context, through what process those were granted, and who can revoke them. The infrastructure doesn't prescribe answers. Communities need real technical means to enforce whatever they decide.

Schneider's garden club has governance infrastructure that most online communities lack. The tools for self-governance exist and are used. Robin Berjon argued in The Web Is For User Agency that user agency requires removing external authority from the system to prevent chokepoints of capture, replacing it with what Jay Graber called "user-generated authority, enabled by self-certifying web protocols." These are the properties governance infrastructure must have for that to be real in practice.

Sovereignty. Governance records belong to the people and communities they describe. Governance state must live in infrastructure the community controls and must be portable without losing continuity. Sovereignty is the precondition. Without it, the other properties are promises with no ground under them.

This includes what holobrine calls permission sovereignty in Capability Trees (an ATProto-native capability proposal currently at draft stage): the ability to control what others are authorized to do with your data, selectively and unilaterally, even against a malicious application. Under an ACL system, permissions are defined and enforced by the administrator. The application is the enforcement point. A malicious application can redefine or ignore the permission structure entirely. Permission sovereignty means you hold the levers over your own authorization relationships independently of any application. Enforcement lives in the protocol, not the application. Where enforcement lives determines whose interests it serves.

Verifiability. Claims about authority must be checkable by a third party without trusting the system that made the claim. If a community says "this person holds this role with these authorities," anyone who needs to verify that (a collaborating organization, a legal body, a new member who wasn't there when the decision was made) should be able to do so by examining records, not querying a server controlled by whoever granted the role. Verifiability separates governance infrastructure from governance theater.

Composability. Governance primitives must compose. Capabilities must delegate. Consent chains must build on each other. Organizations must relate to each other (as peers, as parent and child, as federation members) using the same primitives at every scale. The same primitives that govern a two-person collaboration should scale to a network of hundreds of organizations. Composability also means that complexity doesn't have to be in the protocol to be available. It can emerge above a simple shared primitive, in records that applications know how to interpret.

Legibility. Governance acts must be understandable by the people performing them, not just by the systems processing them. Authorization systems can be technically correct and completely opaque to participants. Legibility is what makes that record meaningful to the people it's about.

Specificity. Consent must be specific to be meaningful. "Access to everything in this community" is a blank check. Governance infrastructure must make specific consent the path of least resistance and bundled consent a visible, deliberate choice. Specificity is a security property as much as a communication norm. Specific consent produces auditable records. Bundled consent produces opaque ones that are harder to reverse and easier to exploit.

Properties describe what the system must be like. Processes describe what it must be able to do.

Baldemo.to's Composable Trust draws a distinction that cuts across all of these: "who belongs" and "what belonging means" are different questions answered by different governance acts. The first is slow, high-stakes, and infrequent. The second is fluid, contextual, and continuous. Conflating them (as most platforms do) makes governance fragile. The processes below build from this distinction.

Consent. The act by which authority is legitimately transferred between sovereign entities. The specific offer, the specific acceptance, the specific authorities conveyed, the specific process by which the decision was made. Consent is how sovereignty becomes social. It's how authority moves between entities without either losing their standing.

Delegation. The act by which a capability holder extends a scoped portion of their authority to another entity without losing it themselves. Delegation must be specific: which authorities, to whom, under what conditions. It must be traceable: the chain from original grant to current holder must be followable. And it must be revocable: withdrawal must propagate through the chain.

Revocation. The act by which previously granted authority is withdrawn. Revocation is the hardest process to implement well in a distributed system because it requires propagation without a central coordinator. Organizations need to be able to undo governance acts, not just accumulate them.

Migration. The act by which a community moves its governance state from one infrastructure to another without losing continuity of identity or history. Baldemo.to puts it precisely: a credential must be verifiable "by anyone, anywhere, without the issuer's cooperation, even if the issuer no longer exists." Member lists can move. The record of every consent act, every delegation, every role assignment and its provenance cannot move if it lives off-protocol. Migration must carry history, not just current state.

Federation. The act by which two sovereign entities recognize each other's authority structures without merging them. Federation enables coalitions, mutual aid networks, research collaborations, and inter-organizational relationships to exist as protocol-level records rather than platform-level agreements. Both parties remain sovereign. Neither adopts the other's governance system. The relationship between their authority structures is legible, verifiable, and revocable.

Holmgren describes the permissioned spaces design intent in Permissioned Data Diary 6 as "the simplest thing that could possibly work, with a clean place for apps to do their own thing on top." That framing is useful. What follows is about what that clean place needs.

That clean place needs to stay clean. The value of a minimal access boundary isn't just simplicity for its own sake: it's that anything left unspecified at the protocol layer remains available as design space above it. If the protocol stays narrow, the work of figuring out what governance should look like (consent ceremonies, role provenance, delegation chains, capability-based authorization) can happen in records, lexicons, and applications, where it can be tried, contested, and revised without a protocol change. If that work gets pulled into the protocol layer instead, by specifying a particular governance or authorization model as part of the access boundary itself, the design space closes for everyone who wanted to try something else. The rest of this section is about what the protocol needs to leave open, and why.

The design choices in the permissioned spaces proposal connect directly to the properties above. Typing spaces by Lexicon NSID (so a forum space and a chat space are distinct, each with its own consent surface) is what makes consent specific rather than bundled. "Access to your AtmoBoards forums" is legible in a way that "access to your community" is not, and the specificity isn't just UX: it produces auditable, scoped grants rather than blank-check access. The narrow access boundary (a minimal shared primitive kept deliberately simple) enables composability. Communities of any scale, from two people to a million, run on the same primitive. And keeping governance complexity above and below the protocol, rather than encoding it in the protocol, is what allows governance logic to live in records the community controls rather than in infrastructure it doesn't.

This framing has been developing across several people's work. Bryan Newbold laid early groundwork in Community Spaces on AT Protocol. Meri Leeworthy traced the identity question in Owning Group Data, observing that group identities behaving like individual users "would create a clear pathway towards interop." Boris Mann put the same point more sharply: "if you make these 'shared accounts' fully work as first class regular accounts, then they will automatically work with any app." Sashank from Habitat noted in the community modeling thread that Habitat is tracking permission state as records specifically for migratability and working on a permission model lexicon proposal. The working group proposal asked how governance authority can be "represented, scoped, delegated, and transferred without prescribing any single governance model" and whether governance decisions should be "legible and auditable." These questions are still open. What follows is my attempt to say what answering them requires.

Governance history must be records, not server state. The member list is on-protocol, synced via the space protocol as a record. That handles membership. But Holmgren notes in Modeling communities on permissioned data that arbiters managing roles above the member list will be "storing off-protocol state for all the roles/memberships that they manage." The governance complexity that matters most for accountability (who holds what role, under what conditions, traceable to what decisions) ends up off-protocol in practice, because the protocol deliberately leaves it there.

Migration is the test. The migration process requires carrying history, not just current state. A community's governance identity is its decision record, not just its current member list. A community whose role assignments and consent history live in an arbiter's database can move its member list but not the provenance of how it got there. The protocol doesn't need to mandate on-protocol governance records. But without shared lexicons for governance history, migration will remain an approximation for any community that needs accountability more than convenience.

The governance layer needs authorization that doesn't require a live server. Verifiability requires that claims about authority be checkable without trusting the system that made the claim. The current credential flow involves an OAuth credential from the user's PDS, traded for a member grant, traded with the space owner for a space credential. This depends on live coordination at every step. Space credentials are asymmetrically signed and verifiable without coordinating with the space owner, which is a meaningful move toward verifiability. But the path to obtaining one still requires every party to be reachable.

As Holmgren notes in Permissioned Data Diary 6, this is a deliberate simplicity choice, and it works for most use cases. The cases it forecloses are the ones where governance verifiability matters most: a mutual aid network operating during infrastructure disruption, a community on a local mesh network, an application auditing governance records without internet access. The structural risk as the ecosystem scales is that space owners and PDSes become chokepoints, simply because there's no alternative path when the live flow is unavailable. The governance layer needs authorization that is cryptographically self-contained, verifiable from local records, not dependent on any server being reachable.

Individuals and communities should be isomorphic at the infrastructure layer. Governance is data. Data sovereignty is governance sovereignty. Sovereignty requires that governance state live in infrastructure the community controls and be portable without losing continuity. For individuals, ATProto already provides this: data lives under a self-certifying DID, on a PDS the user controls, portable by design. Communities should have the same guarantee.

In Owning Group Data, Meri Leeworthy noted that group identities behaving like individual users "would create a clear pathway towards interop. If the community went in this direction, we might one day want to reconsider the term 'Personal' in PDS." Holmgren raises the practical shape of this question in Modeling communities on permissioned data: does the PDS need a controlled DID system, or do arbiters suffice? He notes that communities created through different apps will end up scattered across different platforms. They'll be discoverable on-protocol, but users will need to manage their communities across different services. A community DID on a PDS inherits ATProto's existing portability guarantees. A community DID managed by an app or arbiter inherits that service's continuity guarantees, which are not the same thing. The goal is PDS-hosted community governance as a baseline, not a special case. How to get there remains an open design question in the current work.

Capabilities are the authorization primitive the governance layer needs above the access boundary. ACL-based authorization places enforcement in the application. Capability-based authorization places it in the protocol. Where enforcement lives determines whose interests the system structurally serves. Governance interactions are inherently multi-principal. Consent chains, delegation, and cross-boundary authority all involve more than two parties. ACLs cannot make correct access decisions in these contexts: required information about who authorized what doesn't survive message sends. Tyler Close demonstrated this precisely in ACLs Don't.

The Arbiter, built alongside the permissioned spaces proposal, scopes itself to membership management by design. As the Arbiter's documentation makes explicit, what a moderator can do in an app is up to the app to enforce, not the Arbiter. Keeping authorization semantics out of the membership primitive is what leaves the design space above it open. An app can express role authorization as records in the space, composable with the member list, without requiring the protocol to know what a role is. The Arbiter's federation design extends this: space delegation lets one community's admin group grant access in another community using the same membership primitive, which is composability at organizational scale.

What that layer still lacks, as Meri observed in Evaluating permissioned spaces for community contexts, is that "the space primitive places all authority to mutate the ACL with the space owner, so a 'managing app' is required to provide this kind of accountability/governance layer." The managing app can provide governance logic. But governance logic that produces no community-owned record of how it was exercised is not verifiable. Shared lexicons for the governance layer above the member list are what make that record portable across arbiters and apps. Without them, a capability grant that lives only in an arbiter's internal state travels with the arbiter. Expressed as an ATProto record, it travels with the community.

Holmgren names this directly as an open gap: shared lexicons for roles, authorization, and consent provenance are things he expects to emerge rather than things the protocol specifies. Sashank from Habitat is working on a permission model lexicon proposal that would address part of this, specifically putting permission state in records that any third party can examine rather than in server state only the space host can query.

holobrine's Capability Trees is the only work in the ATProto ecosystem I know of that picks up the object capability tradition and asks what it looks like as ATProto records. It isn't a finished implementation; it's a design proposal at draft 5, with feedback from Brooklyn Zelenka and Daniel Holmgren. But the difference is striking: delegations live as records on the issuer's PDS, authority exists in the state of the world rather than in a token, and revocation works by deletion rather than a revocation list. ATProto's existing infrastructure (DAG-CBOR, content addressing, DID resolution) does the work that in other systems requires custom capability machinery.

I'm not arguing that permissioned data should adopt Capability Trees or center capability-based authorization in its proposal. The ask is the one made at the outset: keep the access boundary narrow enough that this kind of work can happen above it. Capability Trees is what that design space looks like when someone uses it.

Capability Trees names one question as explicitly out of scope: how does a collective make binding decisions, and how is the legitimacy of those decisions made legible and enforceable at the protocol level? That question needs its own answer. But it can only be asked well if the capability layer beneath it exists.

This extends to every participant type. The governance question for an AI agent is the same as for a human member: what specific capabilities does this participant hold, through what consent process were they granted, and who can revoke them. Communities that want to exclude certain participant types have the same primitives available as communities that want to include them. The governance decision belongs to the community; the infrastructure makes that decision possible without making it for them.

Cross-boundary authority recognition needs protocol-level expression. Coalition organizing, federated community networks, and inter-organizational collaborations: this is what distributed organizing looks like at scale.

The Arbiter's space delegation already handles federation within shared infrastructure: one community's admin group can grant access in another community using the same membership primitives, without either community managing the other's membership directly. That's composability at organizational scale, using the same primitive that governs a private chat. What it doesn't yet reach is federation between communities on separate infrastructure. There is no record type for declaring a relationship between two community DIDs that don't share an Arbiter, no standard for expressing that one community's members have scoped authority in another community's space, and no way for a third party to verify that relationship without trusting either community's infrastructure. A coalition whose member organizations run on different services has no on-protocol way to express their relationship. Federation as an on-protocol record (sovereign, verifiable, scoped, not dependent on a shared service) is what's missing.

The protocol layer the permissioned spaces work is building is intentionally minimal: a space, a member list, and a typed consent boundary. The governance complexity communities described at the start need (consent provenance, role authorization, delegation chains, migration history, cross-boundary federation) belongs above that primitive, in records. What records, in what lexicons, with what shared semantics, is where the work is now.

The choices made in that layer will determine whether the governance infrastructure that emerges is verifiable by third parties or only by the systems that issued it, sovereign to communities or dependent on the services that host them, portable across arbiters and apps or trapped in whichever service a community happened to start on.

Groundwork is my attempt to build that layer: making the processes above first-class records on ATProto. More on that soon, with lexicon and a working prototype.