Addressing all participants in a discussion


Suppose there’s a discussion about a ticket. The discussion is represented as a tree of Note objects, published using Create activities.

When I, as a client, post a comment in a such a discussion, I’d like to be able to address all the other people who have commented. How would I do that?

Before I describe my idea, let’s think about this for a moment like a mailing list: Suppose there’s an organization called Feneas, and this organization has a mailing list at, and an email address such as [email protected]. In ActivityPub terms, we can translate it to:

  • There’s an ActivityPub object representing Feneas, of type Organization or similar, that object’s ID URL could simply be, or suppose Feneas has some Fediverse account, it could be
  • That Feneas object has a list of people participating in the discussion about it. In mailing lists, you usually subscribe before you can get automatic email, while in our case here it’s typically open to everyone, anyone can comment on a ticket, and still get notified on new comments made afterwards. Either way, the point is that we have this list of people participating. In ActivityPub, we can represent it as a collection, say It doesn’t matter whether Feneas here is a user account or any other object; anything that can be a discussion topic can have a list of commenters.

So, my suggestion is like this: If there’s a project, and it has a ticket, and I’d like to make a comment on that ticket from my user account, it happens as follows:

  • Each ticket has a collection, suppose we call it “commenters”, which is a list of everyone who commented on the ticket. The server doesn’t have to literally keep a list; it could just generate the list from its database whenever it’s needed.
  • For our ticket, the collection would be
  • When I post my Create Note activity from an ActivityPub client application, I list that commenters collection URI in the “to” or “cc” fields.
  • My server forwards the activity to because the “to” (or “cc”) field lists a recipient hosted on the latter server
  • The server does inbox forwarding, it fetches/computes the list of commenters on the ticket and delivers the Create Note to them

There are questions and caveats and alternatives, but before I list those, I’m curious to hear how other people do such things :slight_smile:


At Friendica we are doing two different things:

  1. We are addressing all previous commenters of the thread in the “cc” header (except those who we are tagging or answering directly, these are addressed with “to”).
  2. The thread starter is relaying all incoming comments to the followers as well.

This should ensure that all commenters do receive all comments.


@heluecht, hmm but how does the client know who these previous commenters are? Does the client fetch the whole conversation tree etc. and collect all the commenters’ actor IDs? If yes, does it fetch the conversation from the home server? Or from the server where the conversation topic is hosted?

And in (2), do you mean the thread starter relays all comments to the thread starter’s followers? If yes, why, and what happens if it isn’t done? (I guess if you follow me and I comment on a topic and I get replies, you want to get those too in your inbox?)


Normally the commenting system should have a list of all commenting actors in that thread. Are you referring to C2S? Then I don’t know how this could be done, since there is no command for this. Question is, if in case of C2S the server should add this information.

Concerning the second question: I don’t understand your question completely.


Yeah I mean in C2S. The AP spec says addressing is up to the client. It does seem fediverse servers handle it on the server instead, and they don’t use C2S anyway, just custom API instead. So in Friendica the client fills in “to” and possibly the topic ID, and the server then fills in “cc” with the list of all commenters?

In the 2nd question I meant to ask: If Joe started the thread, then Joe’s server relays all the comments to Joe’s followers? So that people who follow Joe (regardless of that conversation) can see the replies he gets on his comments?


Currently Friendica doesn’t support C2S. I don’t know what the specs are saying in this case. At Friendica the system fetches the basic permissions from the starting post. Then it looks for the existing comments in the post and it looks for the mentions. When using our API, we only provide the number of the post we are commenting on - and we are taking the additional mentions from the body.

For the second question: You are right.


@heluecht, thank you for explaining :slight_smile:

Hmmm hoping to hear about other systems too ^ _ ^


If you think of the discussion as a Actor (i.e. inbox+outbox), explicit addressing should not be required:
A Client will add comments to the discussion by createing new Notes via the Actor’s inbox and they than will be federated to the Actor’s followers via the Actor’s home server.
(for “tree of Note objects”, see footnote*)

The concern whether and when to follow the “discussion”-Actor then is up to the client. I think a sane default would be to following it immediately. Or maybe any contribution automatically follows server-side, but not sure if that’s the AP way.
And it also opens-op the possibility to “unsubscribe”: Just unfollow.

With your pixelfed example a participant would Creates a new comment (as a Note) via inbox and then would federate the Note to #12’s followers.

With being a project repository, the server also could apply some custom logic like also sending the Note to a user “watching” (à la GitHub) the repository.

* If you really want a tree, think of the Note list on the outbox as an linearized tree. ^^


When I, as a client, post a comment in a such a discussion, I’d like to be able to address all the other people who have commented. How would I do that?

This is a problem solved in the C2S part of the spec.

I view C2S client addressing pretty literally from the spec: put “to” and “cc” properties on the Object, or whatever it is being federated around, too. Mastodon does this. Pleroma does this.

Figuring out who to reply-to is then a breeze as a conversation chain of Note or whatever other objects will already have carried forward the “to” and “cc” thread participants. So just roll them over to the new Object being created on the client side. Then any additional Client-side app-specific behavior on top of that using your special addressing collection (or whatever you decide) is just an added bonus.

And yes, whatever you decide for the “added bonus” (A special Collection that should be CC’d, a special tag, etc) won’t be universally enforceable for all C2S clients, but you can at least ensure your particular C will be able to handle it just fine. I don’t think it would be wise to try to enforce this server-side, because then it leads to a mismatch between what the C shows the user it is doing and what the S actually does, which is a gross violation of user expectations.