ActivityPub Support: Phase 1 RFC

Continuing from Federation support for Discourse, Tools to "aggregate" many Discourse forums? and ActivityPub Implementation for Discourse,

Why?

A common problem that many Discourse users face is the inability to show an aggregation of all the interest groups that they are subscribed to. There’s no easy way to consume content from multiple Discourse instances in the form of a central and social user feed. Centralised platforms like Reddit get around this by having a single login for all communities and an aggregate feed of all the communities shown in a single stream on the reddit.com landing page. This latter feature is what we’d like to replicate in Discourse by means of the ActivityPub protocol.

For example, Person A frequents multiple Discourse instances: one for politics, two for hobbies, one for their local neighborhood forum but has no way to consume all relevant content in one single feed. In comparison, if you have joined multiple Facebook groups or Reddit subs, the most relevant posts already show up in your feed.

Spec (v1)

We could prototype an MVP by enabling the following features through a Discourse plugin:

  1. Generate an ActivityPub feed on demand (for every page that already has an RSS feed)

    • Similar to adding .rss to the url, this will allow the fetching of content using the AP protocol on requesting the right endpoint.

    • We may even be able to enable this for private content by appending user api keys to the url.

  1. Let forum admins enable ActivityPub (outgoing) on a per-category basis or keep it default-on?
    (I believe @Falco had some thoughts here)

  2. Figure out a way to consume this content on a Discourse forum / Mastodon feed (incoming)

Next Steps

We definitely need to start small so at first, we need to decide on a small, feasible set of features that will go into the first iteration. I’ve been going through the ActivityPub protocol but I’m not too familiar with the inner workings of it yet. Therefore, I’m inviting others who have shown a lot of interest in this to the discussion (@Falco, @hellekin, @merefield) to help us build a feasible spec for the first iteration and recommend changes for the spec above.

Resources

https://www.w3.org/TR/activitypub/
https://activitypub.rocks/

12 Likes

Here are a couple of highlights from the older topics :arrow_down:

Agreed, I think this is exactly how @Falco proposed that v1 could work.

1 Like

Excellent initiative, thanks.

I would start by saying: shouldn’t we focus on the what not the how, initially? Tech arch comes later? The reason I say that is it might limit the functionality if chosen too early?

I would love to see for Version 1. a ‘Discovery of Discovery’ lists, starting with:

  • ‘Latest’ list which showed a preview of each recent topic from the included sources (simple union of Latest from all sources)
  • ‘Watched’ list, which showed a preview of each Topic that has activity you have selected to be notified about. (this takes its precedent from the existing mobile app - its exploding the notifications of new activity on watched Topics to the underlying Topic previews themselves).
4 Likes

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 discourse.joinmastodon.org could be federated to socialhub.activitypub.rocks 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?

1 Like

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!

5 Likes

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.