Standardizing on ActivityPub Groups

Hello everyone!

We are adding federated Group support to Pixelfed! Going to be reaching out to a few projects to see if we can make our implementations compatible.

Advice and feedback is greatly appreciated!


Some input scraped from this forum…

@Sebastian in the past has created a ‘group topic’ :wink: that groups prior group discussions: How to use Groups

The ongoing groups implementation discussion was recently picked up by @macgirvin for implementation in #software:zap based on @grishka’s FEP draft. See Groups implementation - #70 by macgirvin

Unburdened by lotsa AP expertise I am broaching the subject of Standardizing on a common Community domain as AP extension? Community is something I need in the future, also based on groups, and imho valuable for fedi as a whole. I haven’t deep-dived the subject yet, nor analysed all existing group implementations.

In my - most possibly naive - view I consider a community network to consist of “Groups that maintain a Collection of Relationships to other Actors”.

  • A Group (the Community) maintains a collection of Relationships to other Actors.
  • The relationship property describes the nature of the relationship to the Community.
  • There can be multiple relationships to the same actor. Some types can be standardized, others custom / app-specific. An example of a standardized relationship vocabulary is PURL’s, but there are more.

In my review of issue trackers in the fedi groups comee up pretty often so I think users will be pleased to see it in any form.

It would be pretty interesting to see some kind of multisignature scheme used to delegate or share group administration, but even having instance-local groups (where that wouldn’t be necessary) would provide a ton of value.


If you need more details about how Friendica is doing it, just reach out to me. In Friendica the group account just is performing an announce to the group members for all content that is directed to the group.


Well, this is then a relay like in

while the Conf session and these posts are more about group based communication
[as in Arnolds graph too, the Group would probably have some more collections like an Inbox (for public group posts)]


1 Like

And btw, relays come with pitfalls, for example if a group can follow other groups, extra care is needed:

If a relay follows a poorly-written relay and is announcing a message, the poorly-written relay announces it back to its members including the other relay which is doing it again and vice-versa and again and …
Although which reminds me of a fellow student at HGB Leipzig who did his diploma in Medienkunst by demonstrating live how to take the Uni Leipzigs mailserver down by infinite bouncing.
He got the best grade you can get :slight_smile:

The huge UX problem with relays, whether built into AP servers or just Mastodon bots like this one, is that you still have to post to your followers first. You can’t post straight to the group without polluting your followers’ feeds. That’s what my FEP aims to solve first and foremost.


In Friendica we solve this with addressing the group via ! instead of @. This means that only the group is targetted but the post is still public.

Okay, I looked at how it’s done in Friendica (here). It’s basically the same as what I do in terms of not addressing to followers, except Announce instead of Add and it’s not possible to reliably tell that this post is to the group wall when you only have the post.

(also, you can easily see when something is written in PHP because you get \/ instead of / in JSON lol)

doesn’t simply not including the followers collection (and explicitly targeting the group’s followers, I assume?) indicate that this is a group post?

No. I tried this approach myself some time ago. Didn’t like this whole idea of guessing where the post belongs by its addressing, hence the FEP and the target field to specify it explicitly.

Besides, when you start taking into account more complex interactions like adding photos to albums in a group, or adding posts to topics, this gets insanely more confusing than just specifying the exact collection (together with its owner so it’s easier to look up on the receiving side).

An interesting little tidbit came up yesterday in a conversation with a Pleroma dev who is considering using ‘audience’ specifically for group targeting, as this was in fact an example shown in the ActivityStreams vocabulary document; albeit one that preceded ActivityPub and some if its unique requirements.

As an unpopular person here who was previously driven away from this forum because of my posts on this very issue: I will stay out of any decision making on this subject. I will only mention that if the solution doesn’t support post authors that restrict comments to their own followers, as well as private groups, and allows distributed moderation, and works across both conversational as well as microblog platforms; I’ll probably provide support for your mechanism but I’m still going to keep what we have now because it works today and meets all of those requirements.

I would highly encourage folks to consider supporting ‘replyTo’ (which works exactly like reply-to in email) to solve a number of “conversation vs. microblog” issues which came up during development of this feature over ActivityPub; and mention that the details of our current implementation are provided in the zap (dev) document. The copy in the release branch is a month or two out of date and we’ve made significant progress on cross-platform compatibility during that time.

I have nothing more to say on the subject.

1 Like

Since there are a number of people interested now in aligning on Group impls, maybe this is the time to collectively start work on a design doc, before we have yet another 50+ comment inconclusive thread. And then - later on - possibly turn it into a FEP. There’s already a bunch of Requirements to be listed, and some design choices already made.

This may start with a wiki post here, or a HedgeDoc in, or directly with a FEP markdown + open issues.


Full ack.
I am proposing to start with a meeting, preferably in 2 days SAT or next FRI to kick it off.

About a collaborative doc: I organised a nextcloud running directly at -
maybe we should eat our own food and use it for collaboration which can federate …

Since the waiting list of topics for Social CG is so huge now, it would be nice if we also write a
“Best practice for Client to Server” and talk about the supernice guides

I don’t see a signup button :thinking:

Yeah what I said yesterday:
Except we can’t really make a group until we’ve agreed upon and implemented at least a minimally compatible federation protocol… So meta, much wow.

The problem here is that this leaves us with two issues:

  • How does a group exercise its authority? How does it reject a post from a user that’s blocked in it? How does moderation work?
  • How does a group disseminate new posts to followers? Announce{Note} is a Mastodon-compatible way many use, there’s also Add{Note} which I’m pushing for as a universal “I hereby accept this object into my collection” activity. Replying to a group (or a photo album, or a collection) doesn’t provide an obvious, semantically sensible solution for this. Forwarding of LD-signed activities is nice but it’s best-effort kind of thing because of how hard LD-signatures are to implement correctly.

From a cryptographic standpoint, it should be possible to store membership in an accumulator, a fixed-length value that can track membership of any number of public keys (an implementation). To verify that you’re not dealing with an old state, there could be a revocation mechanism where admins of a group build a key revocation as they sign a new membership state.

How do you test this currently?

No, let’s not involve any additional cryptography here. It’s merely a problem of state synchronization, where the instance that the group is on contains the authoritative state. Remember: treat ActivityPub like an API, this makes reasoning about it a whole lot easier. Your Create{Note} is an API call where you ask the group to add a post to its wall, group’s Add{Note} is its API call to its followers to update their cached states.

Well, there’s a spec… And I have some test cases from Mastodon. Here’s a topic of mine where I discuss LD-signatures in detail:

Fact check: Unless something changed recently Pleroma does not use LD-Signatures. This was the whole reason for the litepub ActivityPub fork. LD signatures are tedious to implement but not necessarily difficult. The real problem with LD signatures is they rely on availability and consistency of centralised external resources in order to validate; and also apply to the entire activity, making it impossible to encapsulate signed objects within other signed objects.


Concerning the “centralised external resources”: To not depend on this we store the basic ones locally:

Ditto. I’m mentioning it because then you need to stay on top of updates that you will have forgotten were a dependency five years from now. We’'re currently caching them with a TTL of a week and falling back if the fetch failed. Then the only thing we need to concern ourselves with is malicious edits or unintentional deletions upstream. There was an attempt to provide versioning of the main AS schema to solve the problem for that particular resource but I couldn’t get the versioned schema to validate at all. I think it was an upstream server configuration; which only underscores the problem instead of solving it.