In conversation with Daniel Holmgren's Permissioned Data Diary series

Daniel Holmgren's permissioned data diary has done valuable work narrowing in on a design for non-public data in atproto — worth reading in full for context on what follows. The proposal centers on permission spaces: authorization and sync boundaries representing shared social contexts, ranging from personal bookmarks to large community forums. Each space has a space owner — a DID that serves as the root of trust — and a single flat member list of read/write tuples published by that owner. Space credentials, application access configuration, and membership authority all flow through the owner.

The current proposal makes an unnecessary choice about authority — one that forecloses the governance solution space before it has been explored. The ask is not to build any particular governance system into atproto. It is to ensure the protocol's authority primitives are expressive enough that the application layer is not foreclosed before it begins. Capability Trees is that foundation.

The permission space concept is the right level of abstraction. The IETF ATP working group was just formally constituted. Permissioned data is being designed now. The authority model baked into that design will shape what governance structures are possible for every application built on atproto, for a long time.

Is versus has

In Holmgren's design, authority is an identity property. The space owner is the authority. This is encoded structurally: the member list is published by the owner, space credentials are issued through the owner, application allow/deny configuration is held by the owner and invisible to members. Every path through the system leads back to one DID.

Capability Trees makes authority a possession instead. A DID has authority because it holds a valid, unrevoked capability that grants it. That capability came from somewhere, is scoped to specific actions, is legible in the delegation chain, and can be revoked by the issuer without coordination.

This is not a minor implementation difference. It is a different theory of what a space is. "Is" authority encodes a person or entity as the source of legitimacy. "Has" authority encodes a structure as the source of legitimacy — one that can be audited, constrained, and held accountable independent of whether you trust any individual within it.

Capability Trees is the right kind of complex. The complexity lives in the terrain — authority relationships are real, and making them legible is the point. A flat ACL is simpler to implement, but its simplicity is borrowed against governance debt that accrues at the application layer, invisibly, until it becomes load-bearing.

The irreducible protocol requirements are satisfied either way. The protocol must be able to answer whether a given DID is a member of a space, and it must know that some entity has authority to determine membership. In Capability Trees, fact of membership is readable from the capability chain: either it resolves or it does not. Authority is encoded in the chain's root. The protocol verifies both without knowing anything about the governance process that produced them. The mechanism — how authority is constituted, exercised, transferred, or constrained — is left entirely to the application layer. This is the correct separation.

Constitutions with teeth

Consider what it would take to build a community space where governance authority is genuinely distributed — where the circle's authority is bounded by a charter, where moderator roles are delegated rather than informally assumed, where members have meaningful recourse if the space acts against its own constitution.

In Holmgren's model this is possible only as social convention. The charter is a document sitting beside the protocol, not expressed in it. The space owner DID has total authority and the protocol faithfully executes whatever it instructs, regardless of whether that instruction is consistent with the charter. Governance by convention holds only as long as everyone acts in good faith.

In Capability Trees, the charter can have teeth. The circle's DID can only issue capabilities it itself holds. If founding members delegate to the circle and explicitly withhold capabilities the circle is not permitted to exercise, those constraints are cryptographically enforced. A membership constitution becomes an entry covenant: to participate, you delegate these specific capabilities to this circle. That delegation is voluntary, explicit, and revocable.

This is not a proposal to build sociocracy into atproto. It is an existence proof: sophisticated consent-based governance — circles with bounded authority, double-linked representation, member-constituted legitimacy — is buildable from delegation primitives at the application layer, without the protocol knowing anything about sociocracy. The protocol just needs to get the primitives right.

Member agency and failure recovery

In Holmgren's model, a member's only lever is exit. Participation is binary — you are in or you are out — and leaving means abandoning the space identity entirely, with no continuity mechanism.

The aforementioned entry covenant changes this in two ways. First, it makes the floor of membership legible. The covenant specifies the minimum delegations required to participate. Everything a member delegates beyond that minimum is their own choice, revocable independently. A member can withdraw a delegation to a specific role, or revoke access granted to a particular application, without triggering the membership question at all. Consent is ongoing and granular, not one-time and binary. This is closer to what consent of the governed actually means in practice.

Second, it changes what compromise means. In Holmgren's model, a compromised owner key is a captured community — the member list, the credentials, the configuration, everything held by whoever controls the key. Members have no recourse except to leave, losing the space identity in the process.

In Capability Trees, the circle's legitimacy was never the key. It was the member delegations. A compromised circle key is serious but it does not capture the community, because the community's consent was always the actual source of authority. In the common case, governance is restored through whatever recovery mechanism the DID method supports. In the extreme case, members reconstitute: a new circle DID, the same covenant, existing membership grandfathered in. The space DID remains stable throughout. The attacker holds a key to an empty room.

Reopening the infrastructure question

Holmgren's diary three works through the colocated versus partitioned question carefully and reaches the right conclusion for the wrong reason. The problems with colocated buckets — resource burden, moderation exposure, operational dependency, trust gaps — are real. But they are not inherent to colocation. They are inherent to admin-as-enforcement-point. Colocation was tempting precisely because having an admin meant needing somewhere for the admin to sit. The owner's PDS was the natural place, and the problems cascaded from there. The colocation question was a symptom. The authority model was the disease.

Capability Trees removes the premise. Without an admin, enforcement is distributed — membership is verifiable anywhere a capability chain can be resolved. The trust objection to colocation dissolves: a dedicated community PDS is not an untrusted stranger intermediary, it is just infrastructure whose authority derives from verifiable capability chains rather than administrative position.

This opens a cleaner picture than either colocation or partition alone. Community participation involves two distinct categories of data. There are things a member authors and retains sovereignty over — their posts, their reactions, their voice — which belong on their personal PDS and leave with them if they go. And there are things the community owns collectively — the covenant, role assignments, moderation records, shared configuration — which belong on a community PDS and persist regardless of any individual member's departure. Partitioned and community PDS are not competing options. They are complementary, each addressing what the other cannot.

The cleanest expression of this architecture is a single migratable community identity — a space that can move governance without forking its own address. That requires identity migration support in atproto, which the protocol does not currently provide. In its absence, separating the space DID from the circle DID is a reasonable workaround: the space DID becomes a stable inert marker, and the circle DID is the replaceable governance authority. But this separation is a workaround, not the destination. Identity migration is load-bearing for genuine community sovereignty and belongs on the roadmap.

The right kind of complexity

Capability Trees is more complex than a flat ACL. Delegation chains must be constructed, resolved, and verified. The governance structures built on top of them require thought and care. None of this is free.

But atproto has already done the hardest work. Signed records, public keys in DID documents, PDS sovereignty and deletion, record addressing — the infrastructure that makes capability chains possible is ambient. It is already there. The additional implementation surface is a capability record lexicon and a verification service. That is a small price for what it buys: governance structures that are legible and auditable, member agency that is granular and ongoing, infrastructure options that match the actual shape of community life.

A flat ACL is simpler to reach for. But its simplicity forecloses options that communities will eventually need — and by the time that becomes clear, the ecosystem will have built around it. The complexity of capabilities is the right kind: it lives in the terrain, it earns its keep, and it leaves the application layer free to build what communities actually require.

This is not purely theoretical. Members of the atproto community are already planning to build sociocratic and consent-based governance systems on the protocol. The primitives to support them should be in place before permissioned data ships, not retrofitted after. The window to get this right is now.