Federation support for Discourse

Here is another article by Mathew about Matrix, a federated platform. Money quote:

It’s like USENET had a baby with the Web!


1 Like

Talking about e2e in a federation discussion makes no sense at all. Can someone move those replies to a new topic please.

1 Like

Maybe the Lemmy Protocol is a good start.

You already have the mailing list mode, and it works similarly (except it’s over Fedi).

There’s a Zoom event 2022-04-28T20:00:00Z

In today’s social media world, we’ve seen platforms go awry when faced with the scourges of misinformation and trolling. In authoritarian regimes, entire platforms are easily blocked. And yes, a billionaire can buy a platform and change the rules.

Would decentralized (or P-2-P) social media, where there is no central controlling entity, be better? How do you take down damaging posts when there is no central command center? The founders of some of the top decentralized social media networks, from Matrix to Manyverse to the new Bluesky initiative, walk you through the possibilities. With demonstrations of how to use these peer-to-peer alternatives to Facebook, Slack and Twitter.

About Our Speakers:

Jay Graber is CEO of Bluesky, the initiative funded by Jack Dorsey and Twitter, “to develop and drive large-scale adoption of technologies for open and decentralized public conversation.”

Matthew Hodgson is Co-Founder of https://matrix.org/. Matrix is an open network for secure, decentralized communication with more than 40 M users.

Andre Staltz is Creator of Manyverse, a free, open source “social network without the bad stuff,” built on the peer-to-peer SSB protocol.

This event is part of a series of workshops presented by Metropolitan New York Library Council, Internet Archive, DWeb, and Library Futures. Learn more here: https://metro.org/decentralizedweb

Please review our Code of Conduct, our Statement on Viewpoints, and details on Interpreter Services here: https://metro.org/code-of-conduct


This. Possibly also integrating remote “Like” actions.

I have noticed that the Fediverse has become noticeably more active and more populous since Elon Musk started his Twitter takeover bid.

On the Discourse instances I run (three of them at the moment) I’d love to be able to use Mastodon (in my case) to be able to follow and “boost” them to a wider audience, to make the information on my instances more accessible and visible to a crowd of others who might care. All of my instances are for expanding the scope of public knowledge on various topics, and rich sharing support through ActivityPub integration would be helpful to achieve that goal.

Converting RSS to ActivityPub wouldn’t help much.

If this were my project, it would be in phases and start simple:

  1. Publish-only: Categories as Actors, including reply posts on topics properly threaded with inReplyTo. These are sent to followers on a per-post basis at the same time that, for example, posts are forwarded to chat integrations. This would require publishing (at least some) categories as Actors and storing Followers for each Actor. These category Actors would not follow or like. No authenticated access would be used. It would honor Like, Block, and Undo Activities. Perhaps also an Actor for the whole server, to easily follow all activity on the server.
  2. Minimal bidirectional: Optionally, accept remote Like actions.
  3. More bidirectional: Interact with Announce actions (i.e. sharing, reposting, boosting), either adding them as likes or displaying them separately.
  4. User interaction: Optionally, webfinger support for users, to enable following the users as Actors to see all their posts. Further optionally, limited by group (I might want to limit it to TL2, for instance), the ability to engage in PMs with external ActivityPub Actors. This could possibly implement the user’s collection of liked posts (at least public ones) in the liked collection.
  5. Textually bidirectional: Optionally, non-member responses via ActivityPub accepted as comments — but this one is tricky because it would naively reflect it back out as a new post, so followers would see it twice. Probably it would require posts marked with their external reference and not posted to followers’ inboxes.

I would explicitly not want to support “following” ActivityPub Actors from within Discourse; making Discourse into a (e.g.) Mastodon clone seems like quite a waste all around. In the language of the ActivityPub spec, it would not be a “ActivityPub conformant Federated Server” and that’s OK. Also the client portion of the protocol just has no place in this plan.


Found this discussion on activitypub Rails implementations. Might be worth continuing the discussion there. :person_shrugging:


Any suggestion how I could federate 4 forums? They are pretty big (100k, 20k, 50k, 20k members). Total 200k.

You cannot federate. You could setup custom SSO or LDAP authentication, which all users can share for accessing each forum from common credentials.

You can also try and make a plugin to integrate them together.

Yes but that would be a extensive and expensive plugin.

1 Like

With SSO or LDAP can I allow login back and forth without having to move everyone to one domain login only?.

For example I have forum A, B, C. I’d like members of forum A to be able to login and post with its forum A credentials to forum B and C. Same to happen to registered members of B and C.

I think this post and the following ones should go to their own topic since they concern a subset of the features discussed here.

1 Like

DiscourseConnect - Official Single-Sign-On for Discourse (sso) - Docs - Discourse Meta may be of help to you :slight_smile:

1 Like

In theory, I suppose that another possibility besides making a Discourse plugin that functions as an ActivityPub Federation Protocol server would be to set up accounts on a separate ActivityPub server that honors the client Social API protocol, and have a Discourse plugin speak the client protocol to that server, rather than be an ActivityPub server. This could have a benefit to closer integration into existing ActivityPub nodes. But I don’t think it’s easier to implement than the server protocol, and it would be a lot more manual setup work for the forum operator than being a federation protocol server.

In my idea for what to implement, to allow the possibility of user interaction, there would have to be a way to distinguish discourse-user-actors from discourse-system-actors (e.g. categories). I could imagine that @#slug@discourse.example.org would be a category actor, leaving room for the later addition of @username@discourse.example.org user actors. But given the prevalence of hashtags that might simply not work in practice.

It would be simpler to just focus on points 1-3 on the theory that 4-5 are getting close to trying to turn Discourse into a general purpose ActivityPub server, which definitely isn’t the point.

1 Like

Mastodon uses the following regular expressions for validation:

  USERNAME_RE   = /[a-z0-9_]+([a-z0-9_\.-]+[a-z0-9_]+)?/i
  MENTION_RE    = /(?<=^|[^\/[:word:]])@((#{USERNAME_RE})(?:@[[:word:]\.\-]+[[:word:]]+)?)/i

As far as I can tell, that USERNAME_RE is applied to remote users, so it’s not clear to me how to have Discourse users and categories in separate namespaces like that. It also rules out normal subcategory slugs. @parentcategory:subcategory@discourse.example.org won’t work with that RE either.

I guess there could be an optional subdomain @username@users.discourse.example.org but that would take more SSL and DNS setup and probably be misconfigured a lot. It’s maybe just not worth going there.

Maybe it makes sense not to create a federation with other platforms, but to create a federation between all instances of discourse, since the number of instances of discourse is very large

There is huge potential here, for sure. The possibilities and feasibilities warrant thorough and sober consideration.

This might be Xanadu territory… (Read Jeff’s post above and follow the link in it.)   Such broad integration is also probably undesirable to most admin/operators of Discourse instances. A formal survey of admins & operators is in order (as opposed to “survey by traffic level” in discussion forums).

This looks like an invitation to security hacks since it dangles the “keys to the kingdom” of anyone who can hack the user credentials of any one of the federated sites. At the very least these features would have to be turned off by default or explicitly loaded as plugins–with most security features enabled and locked down. Zoom taught us this lesson by rightfully leaving their platform open and easy to use (to quickly gain and cultivate users on ramp-up) but then had to quickly lock down once the ruffians found the front door unlocked.

Nevertheless, a micro-federation of sites would be a boost to Discourse implementation. If I could create a circle of sites for my municipality that unites the same pool of users (county/city citizens for example), this would put people in communication and could enable some positive outcomes in local governance and community life. This same principle also applies to any business large enough to justify the overhead of administering multiple Discourse instances so that each division can have its own Discourse container with easy navigations to other divisions. THAT would be the embodiment of meta.discourse.

Jeff, Sam, and Co. [@codinghorror @sam] and/or their Steering Committee would first need to decide, however, whether Discourse is a social platform or an enterprise platform. My vote is for enterprise because I see the most potential there for both sides of this split. Enterprise will produce the greatest financial reward and immediate social benefit by improving businesses’ ability to support employees (take good care of the business and the business can take good care of you). Some of those commercial funds could probably then support a social.discourse.org foundation. It’s also very likely that features useful to an enterprise will carry over well to the social domain. These two factors make for an overall win-win.

The two domains need to be distinct, though, because they’re so different. And nice-to-have features will necessarily need to favor whichever version is the primary use case.

Happily, the benefits flow both ways since anyone interested in social.discourse.org gets their reward from the social aspects of community building and being able to pursue community-related activities, so will work–and often work hard–for these non-financial rewards. This social.discourse.org work will inevitably lead to development and features that are useful in the enterprise context and thereby return value to Enterprise Discourse Incorporated in exchange for non-profit support of the Social Discourse Foundation. Even more win-win.

Notice that there isn’t a single exclamation point above. These are just plain facts and statements of likely outcomes. Very pragmatic.

I’ve been looking for a suitable GroupWare platform for my businesses for several years now. Slack briefly inspired high hopes since it was developed for internal business use (and has a very interesting origin story) but didn’t even make it through first-round screening. I’m very impressed with Discourse and optimistic about it.

1 Like

That’s the whole point of this topic, i.e. between Discourse instances.

It is stated in the OP:


Right, and


a micro-federation of sites would be a boost

All on-topic, no? :smiley:

Not necessarily a prerequisite. There is the plugin ecosystem to be considered.

Significantly large features are often developed as plugins or even Theme Components (where possible) that do not involve such an administrative overhead nor centralised planning.

That’s part of the beauty of the Discourse ecosystem.

Pavilion, for example, created Locations, Topic List Previews, Multilingual, Follow, Layouts, Custom Wizard (to name but a few) all without consultation with CDCK. Hence, in part, our involvement in this discussion.