Writing as the group

Some records have to be authored by the group DID. A steward gets a scoped credential for it by signing in with their own account.

Some modality-specific records need to be created by the group DID itself. Pinning a post at the top of a forum might need a pin record authored by the group in the forum space. An announcement channel might accept posts only from the group.

A credential, not a password

A person who needs to write as the group, such as an admin, does so by holding an OAuth credential for the group DID and writing the record to the group’s host. The host supports all com.atproto.space.* create, read, update and delete methods.

This doesn’t mean the person has “full access” to the group account, or that they sign in to the app as the group in the traditional sense. The group’s host is also the OAuth authorization server for the group DID. Instead of a password, it asks the person to sign in with their own account.

Scopes come from the access record

Which OAuth scopes each role may request for the group DID is written into the access record of each relevant space:

{
  "$type": "group.opensocial.access",
  "readableBy": ["public"],
  "credentialScopes": [
    { "role": "admin", "scopes": ["group.opensocial.profile", "group.opensocial.rule"] }
  ]
}

The host grants only what the person’s roles allow in that space. An app asking for more gets less, not an error.

Juggling credentials is the app’s job

Apps decide how to present this. They might offer an account switcher where an admin switches to acting as the group. Or they might do it transparently, using the group credential only when the admin does something that needs it, like pinning a post.