TLDR: I’m proposing a working group to develop shared interoperable standards for community infrastructure within ATProto. Many teams are independently making foundational design decisions about group/community membership, governance, and infrastructure. Without coordination, a de facto standard will calcify from momentum rather than deliberate evaluation of the ranges of community needs. I provide initial questions and principles to start discussion.
Many people, apps and projects in development are tackling the question of group/communities in ATProto:
- Bluesky’s protocol team has been designing a permissioned data spec that will establish the foundational infrastructure for access-controlled community spaces.
- Blacksky has demonstrated what full community and infrastructure autonomy looks like in the protocol by building and operating a stack prioritizing community safety and self-governance.
- Northsky / @evelyn.northsky.team is developing its “Stratos” implementation for creating protocol-native spaces for safety-critical communities operating under a single trusted operator (details from Atmosphereconf)
- @erlend.sh , @meri.garden , and @zicklag.dev are working on Roomy, a group chat service. It aims to address architectural gaps for community communication through its underlying infrastructure Leaf, which acts as a “multi-player PDS” where community-owned streams are the core data structure.
- @brittanyellich.com has developed a framework for opensocial.community, which provides app-agnostic APIs and infrastructure for creating and managing communities across ATproto social experiences (Related discussions on this forum thread.)
- @ngerakines.me has proposed a concrete implementation model where communities are represented by repos managed by a service using a combination of service-auth, membership attestations, and content wrappers records.
- @bnewbold.net has written extensively about both general principles for atmospheric community design, and specific motifs for the shape communities could take in ATProto.
- @moja.blue has written about community infrastructure as a gradient, from permissionless, tag-based commons to credentialed, access controlled spaces; and what supporting the full range could look like at the protocol level.
- @laurenshof.online has analyzed the structural dynamics of the ATProto ecosystem at scale to surface gaps and pressures that shape how communities form, or don’t, in the protocol.
- Frontpage’s team has explored how communities emerge organically from topical engagement in a link-aggregation context, and how recurring participation and shared interests shape community boundaries without formal initiation.
- @meri.garden has surveyed and compared different approaches to how communities can manage shared data on and off atproto.
- Yours truly (@baldemo.to) is in the process of publishing Composable Trust, which aims to enhance resilience of large communities by decoupling communities from their stewards and separating different kinds of governance roles and permissioned spaces.
And there are almost certainly even more good contributions, proposals think pieces, discussions, and projects I’ve missed here. I encourage people to post anything I’ve missed below.
It’s quite striking to me how wide the breadth is for each of these works. Each implementation, discussion, and think piece, by necessity, makes design decisions about what a community is, how membership and gating works, where authority lives, and how governance operates. Many (though not all) are working toward interoperability between apps and social experiences. But, interoperability can only be maximized if there exist shared foundations…
This means more than just schemas. It also includes shared approaches to membership, governance, social spaces, and the surfaces that apps need to mediate community experiences consistently.
As of now, each project focuses on good design for their particular use case. While appropriate for app-level design, this does carry risk at the protocol level. If and when an approach optimized for a use case “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 problem space is wider than any single effort can see, and no one workstream can fully evaluate its decisions against the full range:
-
Protocol designers see the technical affordances at the protocol level, what the primitives can support, and where the constraints fall.
-
Community builders and maintainers bring experience with the modalities, use cases, and governance considerations for communities independent of any one implementation.
-
Safety-focused projects focus on the failure modes at the privacy/permissioning and safety level — how they occur, how they’re prevented, and how they can be addressed when prevention fails.
-
Application developers see how community structures and decisions become user-facing realities, including how presentation could shape behavior and vice versa.
Each perspective is necessary, yet no perspective is sufficient for creating a robust standard.
Right now, each is working in parallel, producing good work, but without a venue to surface how decisions might integrate, synergize, or conflict. If we create such a venue, we have a better opportunity to build communities in the social web that are genuinely portable, interoperable, and resilient across the fullest spectrum of community models and social experiences.
For these reasons, I propose a working group to develop shared standards for community infrastructure in the AT Protocol.
Areas to Address
I’ve spent some time trying to map out the breadth of this problem. The following are areas I think the group would have to work through, framed here as questions for discussion, in no particular order and not necessarily exhaustive:
Community Identity and Discovery
- What is a “community” at the protocol level? What is “membership” “social context”, “social space”, and “governance”? Under what kind of ontology are we operating?
- How are communities represented, discovered, and presented as a coherent entity?
- How do communities bind their infrastructure and services (e.g. feeds, labelers, moderation tools, social spaces) into a legible structure with a coherent entry point for new members?
Membership
- How is membership issued, verified, revoked, and carried across services?
- How does membership remain verifiable across issuer failure, infrastructure failure, and stewardship transitions?
- What are the requirements for communities where membership itself is sensitive information?
Data and Social Spaces
- How is public and permissioned community level data stored, indexed, permissioned, and addressed?
- How are social contexts within communities created, addressed and routed — from public, permissionless coordination to private, access controlled spaces?
- How do spaces relate to apps, to each other, and to the community’s membership boundary?
- How can sensitive group/community data be handled for safety-critical communities?
Governance and Authority
- How is governance authority represented, scoped, delegated, and transferred without prescribing any single governance model?
- Should and how are governance decisions made legible and auditable?
- How do communities survive stewardship transitions, such as failure, succession, and constructive forks?
App Mediation/UX
- What does the protocol provide to applications so they can render community experiences consistent with community intent?
- How do communities control which apps access their data, across the full range from permissionless to single-app only?
- How can members observe and evaluate app behavior with respect to community governance?
Topology and Composability
- How do communities relate to each other — including nesting, federation, and shared infrastructure?
- How do communities subdivide, and evolve their structure over time without requiring or precluding top-down coordination?
Proposed WG Organization, Structure, & Phasing
This is a much broader and more cross-cutting problem space than most working group topics, as it touches identity, data, governance, safety, and application behavior simultaneously. Moreover, decisions in one area may constrain decisions in every other. The cross-cutting nature of the problem space itself means this WG can’t scope tightly around a single concern like other WGs. This is precisely why a working group is needed. Multiple people with different kinds of expertise for different concerns is paramount to creating a robust set of deliverables.
Because of this cross-cutting, the WG would likely need more deliberate structure than a typical working group to avoid scope creep and decision paralysis. I think one of the group’s first conversations needs to be about how to keep the work focused — i.e. what to address directly, what to defer, and how to ensure longer-horizon areas inform, but don’t stall, near-term progress. Perhaps this could be done through both a charter and some kind of phasing, such as:
- Phase 1: Shared ontology and community archetypes (i.e the “what are we even talking about” phase, ontology semifluid pending future work)
- Phase 2: Membership and identity primitives (or the narrowest, most concrete interoperability surface)
- Phase 3: Governance, spaces, and composability (the harder, higher-level work)
Domain representation
Domain representation could address the cross-cutting nature of the problem space while limiting the breadth and commitment required from individual WG members. The WG could identify key domains within the problem space and recruit trusted domain leads to act as representatives for each. These representatives would evaluate proposals and deliverables through the lens of their domain’s specific needs and failure modes. This would let the WG work on concrete deliverables without requiring every participant to hold every concern in mind at all times, while still ensuring no concern is overlooked.
Proposed Principles & Methodology
A few things I think should guide the works, which I propose as starting points for conversation:
Potential guiding principles:
- Enable, don’t prescribe. The WG should define infrastructure for community models. It should not prescribe models or governance itself.
- Safety is a first class constraint. Communities where membership or participation creates real-world safety risks should be accounted for in every deliverable.
- Resilience is a first class constraint. Irrecoverable community failure due to a single point of failure should be treated as an unacceptable outcome unless no other alternatives exist.
- Assume adversarial conditions. Community primitives should be evaluated against coordinated abuse across layers as an expected condition.
Potential design approaches:
- Minimum viable standardization. The WG should identify and atomize the smallest shared foundation that enables portability, resilience, and cross-app legibility. Implementation-specific extensions should occur above that layer.
- Support community evolution. Deliverables should account for community evolution over time: composition, subdivision, forking, and governance changes.
- Identify irreconcilable fractures. Where design tensions across community models are irreconcilable within a single primitive, distinct design regimes may be warranted, even if they break clean interoperability.
- Protocol enables behavior, while apps guide it. The protocol layer should maximize affordances for group behavior. The app layer should guide towards positive behavior.
Potential Methodology:
- Evaluate against concrete archetypes. The WG should define a small, representative set of community test cases to benchmark against. e.g. — large, open interest communities, private support groups where membership is sensitive, professional credentialing bodies, geographic neighborhood groups, creator-audience communities, etc..
- Time-box the first milestones. A first deliverable within a few months (even if just a shared ontology and problem statement) would establish momentum, surface disagreements early, and produce artifacts the ecosystem can build and define against.
This WG is not a call to pause what anyone is building of course. After all, products produce real-world evidence of community needs and dynamics the WG deliverables should be evaluated against. This WG would merely exist to encourage convergence on shared foundations rather than diverging into several incompatible ones.
Conversely, I would encourage anyone with a stake in the shape communities take on the protocol — whether that be building community tools, running on or off-protocol communities, designing governance systems, developing apps, or even just thinking about these problems — to participate. You don’t need to be implementing anything; in fact, I think some of the most important input will come from people who understand community dynamics and governance independent of the AT Protocol or any specific implementation.
Depending on interest, we can organize a facilitator/organizing committee to schedule discussions/agendas/etc. If you’re interested in helping out with this, let me know!
