Standardizing on ActivityPub Groups

ActivityPub
60

Hi, I’m currently working on groups support for Mastodon.

The definition of what a group exactly is unfortunately differs from project to project, but what we have settled on is:

  • groups have a set of members and administrators/moderators (we’re assuming this is public information, but that may not be a hard requirement)
  • only group members can post in a group (this one isn’t set in stone)
  • posts and replies within a group all have the same audience, set by the group (group members, and potentially publicly-viewable as well): no per-post scopes like we currently have in Mastodon
  • similarly, mentioning non-members, if at all possible, should not extend the audience of a group post
  • a group post is bound to a specific group and cannot be cross-posted
  • posts are viewed in a per-group timeline and not on the home timeline
  • new members may or may not need to be approved (group-specific settings)
  • moderators can kick/ban group members and delete individual posts
  • ideally, users should be able to report group posts not only to server moderators but to group moderators as well, and have a choice in that (e.g. be able to chose not to report to group moderators in case they are wanting to report the group’s behavior as a whole to their server’s moderators)

For implementation complexity, UX and moderation reasons, I have decided on the following restrictions, at least for the initial implementation in Mastodon:

  • no Announce functionality whatsoever within or across groups
  • mentions of non-members won’t be processed at all. This is mostly an implementation detail, though it may have UX implications
  • only groups with publicly-viewable posts will be supported. While this may change in the long run, restricting ourselves to publicly-viewable posts for now avoids some potential technical difficulties and moderation issues.

I have not started writing the ActivityPub side of things, but what I have in mind is roughly:

  • group actors have Group type
  • Join is used to join a group, and Leave to leave it. It follows the same flow than Follow, with Accept or Reject being sent either automatically or after manual review
  • both top-level group posts and replies are sent only to the group, which is responsible for distributing them (they may be publicly dereferenceable, but distribution itself is handled by the group actor)
  • posting within a group (at least for top-level posts) uses FEP-400e or similar

This seems roughly consistent with what has been described here for Smithereen, lotide, and @macgirvin’s projects, so I’m hopeful we’ll manage to have something interoperable.

That being said, there are still quite a few open questions, even with the limitation I listed for Mastodon’s initial implementation:

  • How do we signal the audience of group posts?
  • If we use to/cc/audience for this, how do we ensure non-group-aware implementations do not interact with them?
  • If non-group-aware implementations do interact with them, what do we actually do? Drop the interactions? Handle out-of-group replies to group posts? This is something we would very much like to avoid in Mastodon for UX reasons.
  • Posting by sending to the group only, with the group deciding whether to allow the posts or not, seems reasonable. But what about other activities, like editing a post or deleting one? A group actor preventing someone from deleting their posts does not sound good, especially since the person deleting their post will have no way to know if the information is distributed to group members.
  • how should posts from someone who has left/been kicked out of a group be handled? should the author still be able to access them? how? what about replies?
  • How is group membership kept in sync? Are Join/Leave/Accept forwarded? Signed? Publicly dereferenceable? Is a collection regularly polled?

I also have other issues in mind, although they don’t apply to the reduced scope of Mastodon’s initial implementation:

  • how do we distribute private group posts? One proposal is Smithereen’s “actor tokens” (short-lived tokens issued by the group actor to its members), although I’m not sure how well it would scale
  • how do we handle federated moderation (having moderators from different servers)? This seems more like a vocabulary issue than a design one, but I haven’t given a lot of thought yet.
4 Likes