Design work on "atmospheric groups" has been coming together in the past few months, with discussion centered in the community discourse forums. These build on the atproto spaces protocol functionality to enable online groups that are self-governed and work across app modalities.
When I came back from leave over the summer, I stuggled to understand how the hosting infrastructure for group accounts would work. Do they have separate PDS hosting and space hosting? How do individual members or app services act on behalf of the group account? And in particular, what does it look like to create a new group account? There were hints of a solution spread across multiple proposals and discussions, but no clear explanation.
It all comes together if we introduce a new network role: the "Group Host". A Group Host is a specialized account host (PDS) specifically for atmospheric group accounts. It manages network identity, public repo hosting, acts as a space host, and implements the group management APIs (currently named opensocial.community, though likely to change). They would only host group accounts, not individual user accounts. Similar to a PDS, they would offer handles for one or more domain suffixes.
Group hosts would be generic network infrastructure, and would work with many app modalities. But they are likely to be operated by service providers (or at least have an explicit relationship with them). This would be similar to the pattern of major atmosphere apps partnering with a hosting provider (or running their own PDS), so that they can guarantee a smooth onboarding experience for folks who don't already have an atmosphere account.
Group Management
One of the primary purposes of a Group Host would be manage collective access and management to the group's account resources. In other words, group authentication and authorization.
Group accounts would not have an email address or password associated with them. Instead, members of the group could log in to the group host using atproto OAuth (authentication-only), and take whatever administrative actions they are individually authorized for.
Permissions would be implemented according to the interoperable groups roles-and-permissions system. This would even include identity management (adding PLC recovery keys), and migration of the entire group account to a new group host. Custom governance behaviors (eg, notice periods, audit logs, or N-of-M authorization) could be part of specialized group host implementations.
The group host web interface could support membership and role management, moderation, and basic space and record management. Though in many cases authorized apps would provide the same functionality in a more integrated user experience. The group host interface could allow individuals to manage multiple group accounts that they have membership of, and potentially to create new group accounts from scratch (possibly limited by invite code).
App Authorization Flow
A common situation would be wanting to authorize a new app to have access to group spaces and resources. Basic invites, membership management, space creation, and writing group-level data records (both public broadcast and space records) can be implemented directly in apps, instead of needing to bounce over to the group host web interface. But the app service would need to be authorized to take these actions.
The proposed flow for this is for the app to obtain an OAuth session for the group account itself. An authorized member of the group (a "steward") would start the OAuth flow from the app, which would direct them to the group host. The group host would then have the steward authenticate themselves using OAuth from their individual account. This would be "nested", "two-sided", or "turduken" OAuth. The group host would compare the scopes requested by the app service against the permissions the steward is authorized for based on their role, and only allow the steward to approve the session if they have the authority to do so. If all goes well, the app ends up with a persistent OAuth session for the group account.
The app needs to re-implement the group roles and permission logic internally to ensure that members can only take appropriate authorized actions on group resources. The overall permissions granted to the app can be constrained by the OAuth session scopes: the app does not necessarily have full management control over the group account.
In-App Group Creation Flow
I think group account creation needs to be very low-friction. In some situations a leader might be creating a group account for an existing community, or have ambitions for a large and carefully governed group. But a very common case is that folks start something very casually or impulsively, and it only grows in to a serious group later down the line.
Low-friction means it needs to be possible for apps to allow folks to create new groups without bouncing over to a group host web interface. But we can't expect group hosts to allow just anybody to generate an unlimited number of group accounts, or the network will be flooded with spam and abuse.
I think the way to resolve this is for app operators to have a relationship with a group host, or to operate their own. The app service would have access to an authenticated "create group" API endpoint on the group host. This API could create the group account, setup the atmospheric group spaces with an initial steward, and return an active OAuth session, all in one go.
From that moment on the steward can log in to the group host if needed, but in many situations they wouldn't need to. That does mean that they might not know how, and that the first time they end up in the group host web interface it could be a bit unfamiliar and jarring. Apps could help smooth that over with an in-app "Advanged Group Management" link with a modal describing what to expect.
It is important that all apps implement the OAuth authorization flow described above, and to support existing groups from any group host. Just like it is important for apps to support individual accounts from any PDS host. The in-app creation flow describe here would be a special alternative flow, not the baseline.
What Else?
A big thing I like about this pattern is that it keeps the protocol and PDS simple. No new auth scopes, no new remote authentication mechanism, and PDS doesn't need to implement any atmospheric group functionality (only space repos and "simplespace"). I suspect that large active atmospheric groups will have higher operational burdens, certainly more than individual accounts, and having that load on a separate piece of infrastructure is nice. It would introduce a new concept and jargon, which is unfortunate, but I think is easier to reason about than the "space host" abstraction.
Could you implement Group Host functionality as part of a PDS implementation? Folks like Tranquil are already experimenting with similar functionality. I think that is fine, but it shouldn't be an expectation or part of the (to be clarified) PDS standard interface.
Would this supplant hypothetical "sub-account" functionality in the PDS? I think they are pretty separate, and it would still be nice to have a way to manage alts and bot accounts as individual sub-accounts on the same PDS. The big difference is that there is for sub-accounts there is only one managing account, while for group accounts there can be multiple stewards and flexible governance structures.
Does a group host need to include a complete PDS implementation internally? One implementation pattern would be to have a group host wrap one or more PDS instances, similar to how an "entryway" service wraps around one or more PDS instance.
Would Bluesky develop and maintain a group host reference implementation? We are interested in this pattern, might implement it for our service needs, and if we did so could make the source available. But we are already feeling some tension maintaining network services both for our own use and for self-hosters (PDS, relay, Ozone, etc), and are hesitant to commit to another packaged distribution.