In ActivityPub Support: Phase 1 RFC I outlined an ideation exercise to evaluate the business case for having ActivityPub support in Discourse, and think beyond a MVP as-if Discourse was built from the ground up with federation in mind:
So hereby I will kick off the ideation with some brainstorming and without taking technical practicalities into account given current codebase. I realize there are many ins and outs and edge cases to all of this. This is a vision of what native federation support might look like. Here goes..
Community has no boundary
(Photo by Pixabay from Pexels)
We all share one planet 
intermingling in complex social structures. Why is a Discourse community restricted to a single forum?
I am admin of Humane Tech Community (HTC) and we cover a broad range of tech-related subject areas, having (sub)categories of “Freedom > Privacy”, “Alignment > Ethics”, “Alignment > Standards”. Too broad maybe, and many other Discourse forums exist that specialize on these categories, and in that field do a better job than we do. But for people interested in getting an overview of the entire field of humane technology the broad positioning makes sense.
Federating categories
What if I could federate our “Privacy” subcategory with e.g. the “Blog Posts” subcategory of the PrivacyTools forum? Maybe to only synchronise topics in one direction - as HTC’s privacy subcategory is broader in scope - where topics created at PrivacyTools appear on the HTC forum, and our members can interact with them. Topic posts on HTC forum are then transferred back to the topic at PrivacyTools and vice versa. The topics on both forums are kept in sync. Maybe I even want to one-way synchronize multiple PrivacyTools subcategories to “Privacy” at HTC. And why not sync with different privacy-related communities in a similar way.
Another example. Both the Feneas and SocialHub share a top-level “ActivityPub” category. There’s overlap in these, duplication, members from one community unaware of what is happening in the other community. This is an opportunity where “ActivityPub” is candidate for bidirectional synchronisation, where each forum then contains the same topic lists.
Federating tags and individual topics
Same can apply for tags, where a particular tag is configured to be federated. This might be e.g. set up such that any topic with #specification tag in SocialHub is federated to “Alignment > Standards” subcategory on HTC.
Topics may also be federated on a case-by-case basis, triggered by a toolbar command, where you specify the target forum to federate to, and maybe also select the remote category that the topic should appear under (i.e. the forum Category list is also federated for remote browsing).
Member mentions and profile views
When a topic is federated to another forum, any mentions within need to be adapted to reflect where the member resides. My @aschrijver handle at HTC might appear as @aschrijver@humanetech on the SocialHub forum after synching.
Since I am also a user on SocialHub in my profile settings I might connect the accounts, and after a verification this means that in the synched topics my local account handle can be shown.
When clicking a remote handle or member avatar the profile card of the remote forum is displayed. When clicking again to see the profile summary, it may show only the activity metrics on the local forum that resulted from synched topics interaction. Alternatively, and more interrestingly, it would show summaries from all known forums that are part of the federation config. E.g. I would then be able to find out that the response came from a very active, expert member on the other forum.
Direct messages and notifications
DM’s would be possible across all federated forums, not just locally, by tagging/mentioning the remote member in the DM. Other than that there would be no difference in the way that DM communnication takes place. It works the same as current local-only DM’s.
From all the federation stuff described above arises the need to also federate notifications. If I respond to a remote member’s post, like their post, or mention them in a synched topic thread, a UI notification may appear in the remote forum to notify the member. Email notifications are handle by the remote forum as well. However, if the member has linked accounts on both forums the notifications might be coming from the local forum where the interaction first took place.
Single sign-on
Note that in all the functionality described thus far, there’s no need to have SSO. A remote member does not have automatic privileged access to another federated forum. So what if they are mentioned in a one-way synchronised topic thread? In that case they will receive a UI notification and email coming from their own forum instance, and when clicking that are directed to the other forum (maybe in a new browser tab) where they can just view the topic. If they want to respond they have to first sign up and link accounts, to be able to respond.
Note that SSO is a tricky thing on the Fediverse, that has no good solution yet. But for Discourse-to-Discourse federation the SSO facility may be much easier to implement. If there were SSO integration, then clicking the notification might open the topic in-context within the current forum (as a ‘remote view’), and allow the member to interact with it seamlessly.
Federation management and complexity
This whole use case is described as-if Discourse was built from the ground up with federation support built-in. If all this is implemented it touches nearly all features of the product. Unlike the use case that started this thread - for FB-like personalized feeds - the federation here is carefully managed by forum staff, not on the whim of individual members.
Much of federation config is admin-only stuff. It should be done strategically and with a good plan, so as to keep the community organization and content intuitive and logical. The federation set up is built gradually over time as part of community-building workflow, not something that is casually added.
Interoperability
Of course this vision of ActivityPub support need not be restricted to Discourse. Any compatible software project could become part of the distributed community fabric. For instance forem’s open-source community building software and loomio collaborative decision-making platform, both of whom I just pointed in the direction of this post. But Discourse has the opportunity to take the lead in all this.
Fediverse integration
All of the federation support so far was limited to the forum/community business domain, but with ActivityPub integration interoperability can now expand to embrace the broader Fediverse, enabling numerous exciting business cases. Just to list some that randomly pop up with me now:
- Announce forum posts fediverse-wide with toots on the Mastodon / Pleroma microblogging platforms.
- Embedded images are auto-uploaded to PixelFed and served from there (nice for e.g. Blender communities).
- Date/time toolbar allows setting up a full Mobilizon Event facing the fediverse, with full RSVP features.
- Integration is 2-way enabled, where Mobilizon Discussions on the event are actually Discourse topics.
- Create PeerTube topics with special video features, where the posts are the comment thread at PeerTube.
- Your published topic automatically becomes a Writefreely blog post plus comment thread.
- Embed parts of your forum into Nextcloud as an app via its ActivityPub support.
- Integrate podcast features via Funkwhale (see recent video about podcasting support).
- Obtain profile info from Flockingbird, professional social network under development (LinkedIn-like rolodex).
And look at the ever growing number of apps on the ActivityPub Watchlist and let your fantasy guide you 
Consequences
Forget for a moment all the technical hurdles and obstacles and consider what having this means for Discourse as a product. Or rather as Discourse no longer being ‘just-a-product’: Discourse has become a distributed community fabric.
Forum staff are no longer just that. They’ll adopt a much broader perspective to community-building. Both the community and community content exists all across the Discourse fabric. Staff will be actively looking at other Discourse instances, approaching their staff to forge partnerships and create interesting federation designs to slice and dice their community organization and content to be most interesting for the community member base.
The community members themself are also much better served. More interesting content will flow to their forum ‘portal’ and the forum will be more active than if it were just a local thing. Community members will be able to discover and interact with members of other forum instances all across the fabric. In fact the community boundary has been removed: Community has no boundary.
