Moderator teams

swicg/activitypub-trust-and-safety#24 is looking at defining moderation teams for cleartext Flag delivery. That can also be useful for E2EE groups, but in our case mod team members also need to be MLS-capable with KeyPackages that can be added as group member(s) and decrypt messages.

https://github.com/swicg/groups/issues/28 may also be relavant as regular AP groups also need mod teams.

A moderation team can be useful in two E2EE contexts: as a team that can be added to E2EE groups as members (see https://github.com/swicg/activitypub-e2ee/issues/88), and as a team to whom encrypted content can be forwarded in reports (see https://github.com/swicg/activitypub-e2ee/issues/87).

Approaches to defining moderation teams

Question 1: How do individual mods participate without sharing passwords?

Option 1A: Single shared actor with multiple devices

One AP actor represents the whole mod team (e.g. modteam@server.example). The server authorizes multiple real mod accounts to control it — no shared password, server-side authorization. Each authorized mod has their own MLS "device" on this actor (their own leaf node and KeyPackages).

• Simpler group membership: one actor added, all mods receive messages
• Server must support multi-user actor authorization
• Pseudonymity still possible: the shared actor has a mod-team identity separate from any mod's real account

Option 1B: Individual actors

Each mod actor has its own MLS KeyPackages; the mod's client holds the private key. The mod team collection lists these pseudonymous actors.

• No shared credentials; each mod's key stays on their own device
• Group membership grows with team size (one Welcome per mod actor)

Each mod can optionally have a pseudonymous AP actor (e.g. mod1@server.example) linked to their regular account (internally on the server) so they don't need separate credentials (at least for servers that support this, like Bonfire). So each mod's real identity is hidden.

Question 2: If using individual actors (option 1B), how are mod team members defined?

Option 2A: approaches from https://github.com/swicg/activitypub-trust-and-safety/issues/24

A moderators property on a host/service actor (as proposed by @trwnh and @ThisIsMissEm), or Webfinger-based discovery (FEP-d556).

• Specific implementation for moderation
• No consent model for inclusion
• Not yet agreed upon

Option 2B: FeaturedCollection (mastodon/featured_collections)

The mod team could be a FeaturedCollection of pseudonymous mod actors, each with a consent stamp (featureAuthorization). Membership changes propagate via Add/Remove. The collection could carry a semantic tag marking it as a moderation team (e.g. purpose: "moderation").

• Interoperable with any featured_collections implementation
• Consent-based inclusion; each mod authorizes their pseudonymous actor to be listed
• Federable membership changes

Question 3: How do mod team changes propagate to existing groups?

When a mod is added to or removed from the team, all existing E2EE groups the mod team is a member of need to be updated with MLS Commits.

If using a shared actor (option 1A):

Adding or removing a mod is equivalent to adding or removing a device on the shared actor, so the same co-device onboarding and decommission flows implemented for regular users apply. The server controls the shared actor and can automatically trigger the change across all affected groups; remaining mod devices (already group members) commit it. Largely automatable server-side.

An important security property falls out of the previously proposed device onboarding flow: adding a new mod device to the shared actor would require an existing mod device to approve it (after emoji key verification), exactly as any co-device onboarding. The server cannot unilaterally add a new mod without an existing mod's cryptographic approval.

If using individual actors (option 1B):

A new mod actor added to the FeaturedCollection is not automatically in existing groups. Adding them to existing groups requires existing group members to issue Commits individually per group. Removing a departing mod requires Remove Proposals + Commits across all groups. This either requires clients to watch FeaturedCollection changes and proactively update each group, or mod team changes only take effect for new groups (leaving existing groups stale until someone acts).

Summary and recommendation for defining moderation teams

	Option 1A: shared actor	Option 1B: individual actors
Credential sharing	None if server-side authorization allows	None: each mod uses own login
Pseudonymity	Guaranteed with shared mod-team identity	Optional per-mod pseudonymous actors
Team change propagation	Automatic via co-device mechanism	Manual fan-out; clients must watch FeaturedCollection
Member discoverability	Shared actor URI directly	Q2 applies: https://github.com/swicg/activitypub-trust-and-safety/issues/24 or FeaturedCollection
Single point of key material	Yes (shared actor's keys on server)	No (each mod holds own keys)

Recommendation: Option 1A for the near term, as it can reuse the multiple device support and verification, team changes propagate automatically, and pseudonymity is preserved via the shared actor identity. The tradeoff is that key material for the shared actor lives on the server (or is distributed among mod devices if the server delegates key generation).

How does a server declare its designated mod team?

A server-level mod team could be discoverable via the server's AP Service/instance actor: a property (e.g. moderationTeam or aligned with whatever https://github.com/swicg/activitypub-trust-and-safety/issues/24 settles on) pointing to the mod team actor or collection. Clients and reporters fall back to this when a group has no group-specific mod team declared.

Start by reading the linked ActivityPub trust-and-safety issue, groups issue, and E2EE issues 65, 87, and 88 to understand the proposed moderation and device flows. Done means reaching an agreed design for declaring moderation teams, representing members, and propagating membership changes across existing encrypted groups.