Moderator teams

[mayel]

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.

swicg/groups#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 #88), and as a team to whom encrypted content can be forwarded in reports (see #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 swicg/activitypub-trust-and-safety#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: swicg/activitypub-trust-and-safety#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 swicg/activitypub-trust-and-safety#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.

[trwnh]

mod team members also need to be MLS-capable with KeyPackages that can be added as group member(s) and decrypt messages.

An option to avoid this is message franking, no? Unless you mean mods at the internal application layer as opposed to the external activity layer?

[mayel]

IIRC message franking would be to verify the authenticity of an encrypted message, whereas the need for them to be MLS-capable would be to enable forwarding encrypted messages to mods without exposing them to the server

[trwnh]

Isn't that the same thing? Either:

• The mods are part of the group, and can see internal data already
• The mods are not part of the group, and you need to disclose some internal data

I don't see the value in disclosing the data but rewrapping it in another MLS envelope, unless you (for some reason) trust your mods but not your server.

[ThisIsMissEm]

On Option 2A: We (in the AP T&S taskforce) are explicitly not publishing individual moderation actors, but instead the moderation group actor, which is similar to the instance actor. Publishing individual moderation actors allows identifying weaknesses in moderation teams and targeting of those team members.

[trwnh]

I think the host can choose whether to refer to individual mods or to proxy actor(s) (with the caveat that they probably want to proxy the exact identity of their mods for the reasons you cited).

(There's a separate issue about abusive hosts/users/posts falsely declaring mods that aren't actually associated with them, directly or indirectly... but that's out of scope here)

[mayel]

Publishing individual moderation actors allows identifying weaknesses in moderation teams and targeting of those team members.

Yeah that's why I included affordances for pseudonyms or hidden actors in every option.

On Option 2A: We (in the AP T&S taskforce) are explicitly not publishing individual moderation actors, but instead the moderation group actor, which is similar to the instance actor.

Ah I see, so a group actor that doesn't reveal its members? In this case that's not quite enough, as we still need keyPackages for each mod's devices, which is why not only does it need to be either pseudonymous actors or such a group actor with hidden membership but also mods need to be able to switch in the client between two MLS identities, one for their own messaging purposes and a separate one for moderation activities, so that people can't uncover their identity by comparing keyPackages...

[mayel]

I don't see the value in disclosing the data but rewrapping it in another MLS envelope, unless you (for some reason) trust your mods but not your server.

Yes, there are good reasons why that can be the case.

Edit: also this proposal allows for selecting mod team(s) for the group, which can be the same as the group creator's server mods but can also be a different team entirely, enabling more modular moderation...

[ThisIsMissEm]

Ah I see, so a group actor that doesn't reveal its members? In this case that's not quite enough, as we still need keyPackages for each mod's devices, which is why not only does it need to be either pseudonymous actors or such a group actor with hidden membership but also mods need to be able to switch in the client between two MLS identities, one for their own messaging purposes and a separate one for moderation activities, so that people can't uncover their identity by comparing keyPackages...

@mayel correct, for safety reasons, we explicitly do not ever expose who the moderators are of an activitypub server, nor how many moderators may be active or not for a given server.