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:
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.
Let forum admins enable ActivityPub (outgoing) on a per-category basis or keep it default-on? (I believe @Falco had some thoughts here)
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.
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).
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?
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.
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)…
Local users would create categories on their instance, as long as the instance staff approve their category creations.
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:
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)
とにかく、