ActivityPub Support: Phase 1 RFC

Thank you for starting this!

I must say the original proposal involving Facebook analogy gets past my understanding: I have no clue what Facebook does, and I do not understand how it relates to Discourse in any way.

My understanding of ActivityPub support for Discourse would be that it can help federate topics, or even share a category among Discourse instances. For example, one announcement topic on could be federated to in the related #software:mastodon category: there, local users could like, reply, quote, etc., as if it were a local topic, except the original topic would live on joinmastodon’s instance.

Another aspect of it is that if one has an account on both instances, there should be a way to link these accounts together, i.e., to use one specific Discourse instance as the main identity provider. I understand that this is not the focus of a first iteration, but it’s good to keep in mind, since we could end up having “sign in with [put your favorite ActivityPub implementation here]”.

What I understand from the proposals above is a replication of the Discourse app on Android, where you have a list of instances, and get notifications from all of them. It seems a bit dangerous to interleave unrelated responses from many sources, especially as they lose context.

Did I understand correctly, and would my understanding make a good second step for your vision of integrating ActivityPub with Discourse?


All the current ActivityPub implementations expect posts to be published by stable Actors, so you might need one of the following:

  • A system account that publishes all posts
  • One account per followable feed
  • One account per followable feed, which makes Announces of posts that are putatively authored by an account per Discourse user

The first is likely easiest to implement; the third does the best job of meshing the data models.

There’s also the choice of if we want to publish full topic content, topic first-posts only, or something like the StackExchange twitter feeds where distinct posts are made promoting posts from the /top page. Or that could just be how the “top posts” feed works, and the other feeds publish everything…

On a technical level, the URL should not need to change: all servers will send Accept: application/activity+json or its alternates.

A reader application that mixes feeds from different sources at different times in ActivityPub - recreating the “algorithmic timeline” as an opt-in thing - is something I’ve been wanting for a while, and doesn’t seem to be existent today.

@hellekin: I think that cross-domain authoring has a high chance of fatally circumventing a lot of the anti-spam protections that Discourse has. Reading is more important to implement: after all, Reading is Fundamental!


I don’t think so: remote users could still be staged, unless they link their remote account to a local one in which case antispam would apply to that account.

I only had a short look at the comments, I must confess. I would suggest that every category would be an own actor (with the type “Group”). Then people from outside can simply subscribe to specific categories. Posts in these categories can the be realized with having the “Group” account announced the user posts. So we do have both the category and the author. This is the way we are doing it with our own software. When using JSON-LD signatures, this would be safe for non public categories as well.

Question is what to do with comments from outside. I would suggest that the group accounts are defined as “manually-approve”. Then one could add some validation process to avoid random spam. These validated accounts should then be able to comment on these posts.

This would instantaneously allow people from (nearly) the whole fediverse to connect and interact with discourse systems.


I agree with @heluecht’s suggestion.

Additionally, I think it would be great that:

  1. Every category Group actor can have an owner who has power to manage the category: control posting permissions, ban or remove users, set visibility (public or private)…
  2. Local users would create categories on their instance, as long as the instance staff approve their category creations.
  3. If a category owner doesn’t fit their position, the site staff can change them.

That’s the way many centralized forums and communities work. What to improve is making it federating.

Nevertheless, there are still problems:

  1. Should actor ids be mutable? Discourse usernames can be set to modifiable in the site settings. However, I doubt whether other AP software can handle this. Is Object's `id` immutable? - ActivityPub - SocialHub
    (More to be mentioned)

Anyone from Discourse team coming to the SocialHub at OFFDEM next week? It would be a great moment to meet and match with other AP implementors.


Not to my knowledge, but thanks for asking!


Some quick points of reference:
Friendica and Hubzilla can turn RSS feeds into ActivityPub/Diaspora*/OStatus compatible federated accounts.

Also, see this Wordpress plugin that turns posts into ActivityPub posts.


Some more points of reference…


Congrats for the EU money!
Is there a roadmap?

Anyone from Discourse team coming to the ActivityPub Conf?
It would be a great moment to meet and match with other AP implementors.


I don’t think this actually moved forward for a variety of reasons – that was just the RFC proposal.

1 Like

Hopefully we’re going to discuss ActivityPub implemention in Discourse over the Birds of a Feather next Sunday during the APConf2020. See the dedicated topic over at the SocialHub:

@rishabh it would be great to have you around, at least in the topic if you cannot make it on Sunday. We don’t know the precise hour yet, but it’s on Sunday morning. I’ll update this post when I know.


Hey @hellekin,

Sorry I didn’t make it. I should inform you that we didn’t apply for the NGI0 funding and no one is currently working on this at the moment. I’m also not the best person to be driving this because I’m not familiar with the protocol but I’ll ping @Falco here just to see if he has any thoughts or interest in taking this forward.


Well, at the time, one of your team members did – even if he’s no more on board, and you were selected – so someone had to approve it, so I don’t know what “we” you’re referring to. :slight_smile: Anyway I’m looking forward to discussing with @Falco. Some kind of AP support would really be helpful for the ActivityPub community, especially since it would facilitate working across Discourse instances and integrate with the Fediverse better.

I’m conscious about the anti-spam issue, but I think it can be alleviated with staging Fediverse users like unregistered email users until they actually register a local account.

1 Like

Of course, it would be really nice to see that.

Yes, we did apply for the funding in the past but we spoke with the NLnet team earlier this year to close the project and free up the funding that was reserved for us. Even if we were selected then, the collaboration with NGI0 is cancelled for now. Of course, we are free to make proposals in the future.

I just remembered that @riking might be interested too :slight_smile:

1 Like


This project was funded through the NGI0 Discovery Fund, a fund established by NLnet with financial support from the European Commission’s Next Generation Internet programme, under the aegis of DG Communications Networks, Content and Technology under grant agreement No 825322.

So: Are they talking about another “Discourse”?
Just asking because of “Projects own website:” …

1 Like

Oh, I didn’t know that page existed. I’ll write an e-mail to our contact at NLnet, nudge them in case they forgot to remove it and post an update here.

EDIT: changes are live on NLnet; Discourse ActivityPub

1 Like

I see.
Pretty frustrating.

Friends changed do discourse because of upcoming ActivityPub.
Now they all trash discourse again …

Also the official forum for ActivityPub went to discourse and now we
need to debate what to do …

The developers behind Lemmy are doing great work on this front of adapting ActivityPub to be usable by community software:

However, they had to extend it, so there is no other software implementing their activities.

Our federation implementation is already feature complete, but so far we haven’t focused at all on complying with the ActivityPub spec. As such, Lemmy is likely not compatible with implementations which expect to send and receive valid activities.

I guess if Lemmy can get it to be compatible with Mastodon, we can go and implement the same API Lemmy uses, mapping

Discourse Lemmy ActivityPub
Category Community
Watching Follow
Topic Post
Post Comment
Like Like

In ActivityPub parlance this would be a Page then, which makes a lot of sense if you consider the Page publishing feature: first part would be announced as a Page, then any response would be a Note.

I’m unsure about Category -> Community. Since AP support and SSO make this more fluid. I tend to have more than one Discourse instance for a single community.