Standardizing on ActivityPub Groups

There is a distinction in that if you don’t join a public group, you can still fetch it and browse its collection, but not post in it.

Regarding Mastodon, I have decided to restrict it to public groups (at least for the initial implementation) for the following reasons:

  • several existing server administrators understandably pointed out they do not want to be hosting hate speech groups are illegal groups and have no way to know. Admittedly, the same issue exists with private posts and direct messages, but I think the scale of the issue would be different with fully-fledged groups. Mainstream media platforms “solve” this issue with automatic content detection in private groups, but that has different issues and is not something we can realistically do anyway.
  • the Group feature in Mastodon is part of a NLnet grant, and that grant expires real soon. I must have something to show (including federation code) really soon if I want to receive any payment for my work on it, so I need to keep the scope reasonably small to hope to manage that

I do not think private and public groups are that conceptually different, and I do have private groups in mind when developing support for public groups. That’s one of the reasons why I want an unambiguous way to signal that a group’s posts are to be public: to leave the door open for private groups. I do not think implementing public groups first makes implementing private groups any more complicated later on, even though we will have to devise a way to efficiently fetch and/or authenticate the distributed group posts (current proposals include LD-Signing the group posts, or having the group issue limited-time tokens to group members).

I’ve been thinking about it, @Claire, and to me the “public groups” you’re describing are more of a different audience scope. Is it something you have thought about? I can see how the wider notion of “groups” is relevant, especially when it comes to users roles as group moderators (especially with the remote functionality).

Still, with regard to private groups, not only ‘posts’ must be authenticated, but also access to the member list, etc. In any case, I think you’re on the way to wrapping up the NGI0 Discovery grant and you should focus on that. Once this first step is implemented, the discussion can go on with the standardization of “groups” in a wider perspective.

My 2cts about Follow/Join, and an alternative proposal for (private) Groups + Amplifiers

Personally I see no difference between Follow and Join in the case of a public group, and still have doubts about the usefulness of making such distinction in the case of private groups, since there’s no reason why one would have access to a group’s postings if they are not part of it. Having a public actor – an amplifier – relaying private group activity to the public might provide a simpler mean to distribute otherwise private contents to a wider audience. Amplifier might be a sort of as:Service that changes the scope of an audience to as:Public. This way, you would keep the concept of groups as simple as possible, only requiring flags for who can post, whether membership is automatically granted or moderated (and by whom), and who has privileges in this group.

Right, but what about following the group actor? I thought non-members will be able to Follow() the group actor and receive group’s posts in their inboxes.
Without this ability, group would behave like a group chat, which is a nice feature but other protocols (matrix/xmpp) can already do that. In my view, one of the primary use cases for “groups” in social network is aggregation and amplification of signals. Do you plan to support this use case, perhaps at a later stage?

Has anyone implemented private ActivityPub groups before? If so, what implementation would you suggest as a standard?

Yes, I’ve implemented private groups for a number of ActivityPub projects, and that work from any ActivityPub capable service (as well as a couple of other protocols) without modification. I’ve also managed to provide compatibility with (iirc) 10 of the current 12-15 completely different groups implementations.

I don’t suggest anything as a standard. I’d be willing to support all 12-15 implementations like we did with quoteUrl - except some of them conflict with other implementations and a couple aren’t documented.


I am not sure what you mean by this.

Sure, posts is just the most important part of it.

I am working on it and focusing on it, with something based on my earlier proposal. I’m just trying to get the conversation going in the hope we come up with something that avoids ambiguity and leaves the door open to other use cases by the time the implementation is merged.

This is not something I’m currently planning to do, but overall that seems fine to me as long as there is no ambiguity that Join and Follow do not mean the same thing (which there currently very much is from the looks of this thread).

This is a bold claim that I’m afraid hides a significant number of hacks and tradeoffs. I might misremember or misunderstand, but last time I checked, private group posts were sent in direct messages to the group, then re-published by the post as its own (with metadata pointing to the intended author but not authenticating them). To be fair, I fail to see how you can do much more in a way “that works from any ActivityPub capable service” but the inability to authenticate messages is an important tradeoff worth mentioning, and the overall UX is a mess (at least from the barely “ActivityPub capable services”).

Supporting 12-15 completely different implementations is not something we are interested in, especially when those implementations have widely different UX expectations and the result ends up being unpredictable and incomprehensible.

On a side note, I’d be interested in knowing where to find documentation on the protocol extensions added or supported by your ActivityPub projects, because I did spend some time searching for how groups (including private ones) worked in them and only found a few incomplete scattered descriptions (I am not blaming you, Mastodon isn’t exactly an example of how to do this either).


I’d be interested in knowing where to find documentation on the protocol extensions added or supported by your ActivityPub projects,

Yes my implementation has some ugly hacks to work with other projects. Because sometimes we have to work with the fediverse we have today.

1 Like

Oh and we do authenticate relayed messages using LD-Signatures, but some projects refuse to support those and therefore can’t authenticate authors of relayed posts. I believe Mastodon can and does.

Thanks, it’s one of the documents I was referencing. It’s a bit incomplete and vague, but it’s a start.

I’m not denying that trying to bring new features to fediverse implementations that don’t have explicit support for them is going to involve hacks. But I think at some point we have to stop adding to the pile of hacks and go with something that has clear semantics.

Mastodon does verify LD-Signatures for some purposes, and it does issue them, but only when:

  • the document being sent is not intended to be public (so it wouldn’t LD-Sign a DM to a group actor), and
  • the AUTHORIZED_FETCH env variable is not set

@Claire Speaking of LD signatures, is there any chance that Mastodon will support other JSON canonicalization algorithms? LD signatures standard doesn’t exist anymore and has been replaced with Data Integrity spec. It is difficult to find an RDF library, and I think this is one of the reasons why embedded signatures are not widely used in Fediverse, despite the benefits they provide.
I mentioned this in related Mastodon issue, but haven’t got any answer yet.

But I think at some point we have to stop adding to the pile of hacks and go with something that has clear semantics.

That’s why we’re all here. But while we’re trying to come to agreement on something that has clear semantics, the people I support have public and private groups – and they federate across multiple projects and protocols. I don’t like the method any more than you do. But sometimes we have to work around vague and incomplete protocols and hostile/condescending developers on other projects - and just get on with it.

FEP-400e is a step in the right direction. We support it today and can use that for the top-level post and avoid the DM hack once it’s supported by a few more projects - especially the ones with large userbases. Until they do, DMs are compatible with private groups and most every platform supports them. Mentions are not compatible with private groups and FEP-400e is currently only supported by a small handful of projects.

We also have working object-level relay signatures on the Nomad side (using salmon over json), but it will probably be a while before the rest of the fediverse moves towards object level signatures. Then we’ll have 3rd party relayed content that’s verifiable and the signature encapsulated in the object itself rather than an artifact of transmission or restricted only to full activities. That critical infrastructure component remains a real mess and if we started fixing it today, it will still be a mess for at least a year or three before it gets better.

I’ve also seen some preliminary drafts for expressing permissions and rights, so there’s hope that others in the fediverse will one day support rich granular permissions (as we do) because that reduces spam and harassment for everybody in the network. Then we can get rid of a few more hacks.

It’s a work in progress. But we always start by making it work. In case, I’m not building consumer products and I’m not selling anything. So please open a separate forum topic for bashing developers and software you don’t like for some reason.

1 Like

Sorry, I have missed that. I can’t give you a definitive answer at this time, but if we’re going to continue providing embedded signatures (which we may reconsider, because the way it currently works means you can’t easily revoke them), it would make sense moving away from what appears to be an outdated draft, yes.

1 Like

I’m not trying to sell anything either (though I do have a monetary incentive in having something done soon, with the NGI0 Discovery Fund), and I do not consider Mastodon users to be consumers, but people who deserve to have a decent a consistent user experience.

Sorry if my earlier messages came across as bashing other developers or software. That was not the intention, and while the current state is a mess, I’m not blaming anyone for that, and Mastodon is certainly no stranger to making the protocol more of a mess in general.

In order to continue going forward, I’d like to sum up my goals and concerns with the Mastodon implementation, as well as how the current proposals support them (or fail to do so):

  1. we want groups as separate places/collections/timelines in which group members can post, and moderated by group moderators (who can reject or delete posts, kick or ban members, and accept/reject new members)
  2. we are interested in compatibility with other Fediverse implementations that support groups
  3. but we are not interested in providing any kind of compatibility with projects that cannot natively support that feature (such as current and past Mastodon versions).
    This is because we believe this provides a wildly inconsistent and confusing user experience, which we want to avoid as much as possible.
    Another reason is that “ActivityPub capable services” that would operate without specific knowledge of groups would face a massive challenge when switching to native groups with clearer semantics: what do you do of your old “compatibility” view of groups on which you had different assumptions?
  4. we are not currently interested in private groups. Indeed, in addition to the additional technical complexities, private groups come with additional moderation challenges and clashing expectations of privacy and ability to moderate.
    Talking fediverse users, server administrators, and fediverse software developers, it is clear that a lot of people are extremely distraught with the idea of potentially hosting private groups they have no way of inspecting, while there is also a lot of people considering that a server administrator looking into private groups they are not a member of would be an unacceptable violation of privacy.
    I happen to agree with both these concerns, and so the most logical conclusion seems to not support such private groups.
    Of course, a server administrator who considers it acceptable to screen private group posts could make that a clear upfront policy, but in the context of federated groups, the policies of all members’ servers must align.
    That being said, while I’m only considering groups with public posts for now, I understand there is a use case for private groups, and I do not want to close the door to them in Mastodon, nor make it any harder for other projects that want to support them to do so.
    This means that we need a way to make sure a group we join does not expect any of its messages to be private, so that we don’t risk leaking any of them nor fail to display some that users would expect to see.

This means, at least from my perspective, we need (I may be forgetting something):

  1. a way to join and leave groups : Join and Leave seem fine for that. Follow and Undo Follow may also work but we’ve seen in this thread that these are sometimes given multiple interpretations
  2. a way to submit posts to the group: this is covered by (at least what I understand of) FEP-400e
  3. a way for the group to distribute those posts: the group actor Adds submitted posts to its wall, though private groups do need another mechanism (object signatures, fetch tokens, …)
  4. a way for a group actor to reject posts: covered by FEP-400e
  5. a way for a group actor to delete posts: not explicitly covered, but it would make sense for them to Remove it
  6. a way to signal whether the group posts are expected to be public
  7. this is more specific to our requirements, but a way for even public group posts to not be compatible with group-unaware services such as Mastodon

This is mostly covered by your proposal at Standardizing on ActivityPub Groups - #48 by macgirvin except 6 or 7. In addition, other well-established projects use Group actors to represent a group of people as one entity, not a group that people can join and post into, so that may be a problem. If I remember correctly, that is the case of PeerTube.

1 Like

My apologies. And we can work with that.

1 Like

You should keep in mind that FEP-400e is nothing more than documentation of how group federation works in one specific project (Smithereen). According to this comment, there was no consensus achieved with any other project when the FEP was finalized, and it seems that no other project has implemented the FEP so far. You can also see for yourself in the socialhub thread that there were many open discussions both before and after finalization was requested, which were never resolved.

On the other hand, Im curious what you think about Lemmys implementation of group federation. Its quite simple, persons send activities with the group in cc, which then announces it to all followers. This means that its already compatible with many other projects (including Mastodon), unlike FEP-400e which would probably require changes in all involved projects to support it. Its also worth noting that Lemmy is the largest Activitypub project with group support, and the implementation is already proven to work in production without problems.

1 Like

PixelFed is also working on groups support based on FEP-400e although I’m not quite sure whether they have a workable implementation yet or not.

I do think Lemmy’s implementation is simpler, however:

  • as I outlined earlier, aiming for compatibility with ActivityPub implementations that do not have a specific concept of groups is a double-edged sword: this means it’s hard to distinguish a provide a consistent UX for groups (e.g. people complaining about everything from a group being boosted in their timeline) especially with other projects (such as Peertube) using Group actors to mean a different thing
  • this is an extension of the previous point that is more of a Mastodon-specific issue, but the accounts UX relies heavily on @-mentions and webfinger, a condition we are able to lift for groups thanks to us considering them as a totally different thing
  • it does not ensure a post and its related interactions only exists within the context of a group
1 Like

I talked with Dansup about group implementation in Pixelfed last November, but didnt hear anything new since then. Based on that, there doesnt seem to be much progress (though I might have missed things as I dont follow the development actively).

as I outlined earlier, aiming for compatibility with ActivityPub implementations that do not have a specific concept of groups is a double-edged sword: this means it’s hard to distinguish a provide a consistent UX for groups (e.g. people complaining about everything from a group being boosted in their timeline) especially with other projects (such as Peertube) using Group actors to mean a different thing

I am actually considering to specify the group in as:audience field in the future, as discussed in [this thread}(Unresolved issues surrounding Follow activities - #20 by nutomic). This seems much cleaner as it doesnt rely on extracting the group from cc field. It should also solve your first and third point (not sure about the second).

I’ve talked with Dansup over the past few weeks, and what he was describing and advocating for was based on FEP-400e, though I’m not sure that he has released code for that yet, and I have in any case not tried yet.

This is also the way I’m doing thing in my work-in-progress code, although there’s still a bunch of unresolved stuff.

If this completely replaces to/cc for posts, it could work, as current Mastodon versions do not look at as:audience. It wouldn’t really allow us to make a distinction on the actor level itself though.

I agree, I do have multiple issues with this FEP (I’d say it’s insufficient clear in many respects, and the thing about inlining an abbreviated form of the collection object can be at odds with JSON-LD), but they do not matter very much in practice. I missed the fact that target was not a valid property for non-activity objects (and would clash with the meaning of target in activities). This is not a practical issue for this specific use case either, but that’s not great.

Nevertheless, I think the initial Mastodon implementation will be based on this, considering it is almost done, and the NLNet fund deadline is mere days away…


Another thing I’m interested in (but will probably have to address after the initial implementation) is being able to report group posts to group admins specifically. Indeed, while one can report content to the instance admin, I think that should be a distinct action, as:

  • rules for a group may be stricter/more specific than those of the instance hosting it, in which case it does not make sense to report to the instance admins
  • someone may want to report a group to the hosting instance without the group admins knowing about it (e.g. group that is abusive, with the group admins’ blessing)

In Mastodon, we currently report content by sending a Flag activity to the reported user’s inbox (because there is no mechanism to represent what actor is responsible for moderating an activity), without any other explicit addressing, and with the offending actors/posts in the object attribute.

For reporting to group admins, I think we can simply deliver a similar activity to the group actor’s inbox, with an explicit to addressing to the group. I don’t think that would cause any ambiguity, but it is something I want discussed before going ahead, to avoid the possibility reports intended for the group admins accidentally going to the instance admins instead.

An update on Mastodon’s implementation of groups

Just to update on Mastodon’s implementation: it’s not final, and may change before (or even after) it gets merged, but the initial Mastodon implementation is now ready for review: Add groups support by ClearlyClaire · Pull Request #19059 · mastodon/mastodon · GitHub

The details are described in this PR, but essentially, it would be compatible with Smithereen if not for the PublicGroup ( actor type and the fact the group posts must have only the group’s member collections in their to addressing.

Both of those changes are deliberate in order to prevent current Mastodon versions from interpreting groups and group posts in a way that would break the group expectations and make migrations a headache.