# Federation support for Discourse
**URL:** https://meta.discourse.org/t/federation-support-for-discourse/90921
**Category:** Feature
**Tags:** completed
**Created:** [June 28, 2018, 5:32am UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921 "2018-06-28T05:32:10Z")
**Posts on this page:** 20
**Page:** 3
### Author:  [@sunjam](https://meta.discourse.org/u/sunjam)
#### Post date: [June 3, 2021, 12:51am UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/42 "2021-06-03T00:51:01Z")
It has nothing to actually do with Discourse so you’ll want to ask the feed2toot project. Good luck.
[https://gitlab.com/chaica/feed2toot/-/issues](https://gitlab.com/chaica/feed2toot/-/issues)
---
### Author:  [@kdmilelr45](https://meta.discourse.org/u/kdmilelr45)
#### Post date: [June 10, 2021, 9:07pm UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/43 "2021-06-10T21:07:09Z")
Thanks James for the information
Keith
---
### Author:  [@sunjam](https://meta.discourse.org/u/sunjam)
#### Post date: [July 3, 2021, 1:17am UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/46 "2021-07-03T01:17:46Z")
Matrix commenting might be interest, since it is able to federate / “bridge” with other chat systems. Not ActivityPub based, but it is both decentralized and currently supported to x-post to Matrix via [Chat Integration](https://meta.discourse.org/t/chatroom-integration-plugin-discourse-chat-integration/66522) plugin.
> [@Cactus.chat - Matrix-based Comments](https://meta.discourse.org/t/cactus-chat-matrix-based-comments/182336):
>
> Not currently integrated, it would be interesting to allow Matrix federated commenting at least on particular topics or categories. These comments are treated as a chat room within Matrix. Currently one-way #chat-integration is available for Matrix so perhaps there is room for adopting this two-way approach in the future. Could also serve as an alternative to [Babble](https://meta.discourse.org/t/babble-a-chat-plugin/87297). Placing here as an fyi. Cheers.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [February 12, 2022, 6:06pm UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/47 "2022-02-12T18:06:37Z")
“Why federated protocols don’t work”
> **[Reflections: The ecosystem is moving](https://signal.org/blog/the-ecosystem-is-moving/)**
>
> At Open Whisper Systems, we’ve been developing open source “consumer-facing” software for the past four years. We want to share some of the things we’ve learned while doing it. As a software developer, I envy writers, musicians, and filmmakers....
---
### Author:  [@mcnesium](https://meta.discourse.org/u/mcnesium)
#### Post date: [February 13, 2022, 6:42pm UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/48 "2022-02-13T18:42:09Z")
“the value of freedom”
> **[On Privacy versus Freedom](https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom/)**
>
> Matrix, the open protocol for secure decentralised communications
---
### Author:  [@mattdm](https://meta.discourse.org/u/mattdm)
#### Post date: [March 3, 2022, 5:02pm UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/49 "2022-03-03T17:02:59Z")
> [@codinghorror](#):
>
> “Why federated protocols don’t work”
I’m not finding this very convincing. It comes down to:
1. XMPP is a mess
2. Federation doesn’t solve privacy concerns around metadata
3. The assertion “The device’s address book is now the social network”.
The first can be true without being general, and the article doesn’t really even try to make a general argument, beyond “look at GitHub issue templates”, which… seems more like a gripe about how that’s implemented than a meaningful point.
The second seems perfectly true, but also not the only reason for federation, and to me doesn’t seem like a _blocker_ — perfect as enemy of good, etc.
And the third thing… I don’t think that’s true except for in a narrow sense, and in that sense, it’s not really what I want. Yes, I can have 20+ messaging apps in a folder on my phone and they mostly share an address book… but that’s not “problem solved!” to me!
---
### Author:  [@sunjam](https://meta.discourse.org/u/sunjam)
#### Post date: [March 14, 2022, 1:07pm UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/50 "2022-03-14T13:07:55Z")
[from the end of Matthew’s (Matrix) response to Moxie (Signal)](https://meta.discourse.org/t/federation-support-for-discourse/90921/48)
It’s true that if you’re writing a messaging app optimised for privacy at any cost, Moxie’s approach is one way to do it. However, this ends up being a perversely closed world - a closed network, where unofficial clients are banned, with no platform to build on, no open standards, and you end up thoroughly putting all your eggs in one basket, trusting past, present & future Signal to retain its values, stay up and somehow dodge compromise & censorship… despite probably being the single highest value attack target on the ‘net.
Quite simply, that isn’t a world I want to live in.
We owe the entire success of the Internet (let alone the Web) to openness, interoperability and decentralisation. To declare that openness, interoperability and decentralisation is ‘too hard’ and not worth the effort when building a messaging solution is to throw away _all_ the potential of the vibrancy, creativity and innovation that comes from an open network. Sure, you may end up with a super-private messaging app - but one that starts to smell alarmingly like a walled garden like Facebook’s [Internet.org](http://Internet.org) initiative, or an AOL keyword, or Google’s AMP.
So, we continue to gladly take up Moxie’s challenge to prove him wrong - to show that it’s both possible and imperative to create an open decentralised messaging platform which (if you use reputable apps and servers) can be as secure and metadata-protecting as Signal… and indeed more so, given you can run your server off the grid, and don’t need to register with a phone number, and in future may not even need a server at all.
---
### Author:  [@hellekin](https://meta.discourse.org/u/hellekin)
#### Post date: [March 16, 2022, 9:15am UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/51 "2022-03-16T09:15:32Z")
Moreover, Moxie’s post is from 2016, only two years after the Matrix protocol was introduced, and two years before ActivityPub was released.
> So while it’s nice that I’m able to host my own email, that’s also the reason why my email isn’t end-to-end encrypted, and probably never will be.
Since then [Delta.chat](https://delta.chat) appeared, building on email protocols and [Autocrypt](https://autocrypt.org), which makes this statement undoubtedly wrong: email _is_ E2EE–and it was before, with OpenPGP, but indeed, Autocrypt makes it much easier for people to use end-to-end encryption.
It would be totally feasible for Discourse to implement Autocrypt and would certainly help achieve the best of both worlds—centralized and federated. But of course, **if Discourse would adopt _staged users as an entry point to federation among Discourse instances_** in the first place, it would make a lot more sense to discuss federation. Moxie’s interests back then was to justify why he would not let people deploy their own Signal servers. And yes, there are many protocols in the works to address all kinds of issues, including upgrading clients.
---
### Author:  [@osioke](https://meta.discourse.org/u/osioke)
#### Post date: [March 16, 2022, 9:22am UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/52 "2022-03-16T09:22:25Z")
> [@hellekin](#):
>
> **if Discourse would adopt _staged users as an entry point to federation among Discourse instances_** in the first place, it would make a lot more sense to discuss federation.
This reads like a separate feature request 😉 would you mind creating another topic detailing this or is there one on this?
---
### Author:  [@hellekin](https://meta.discourse.org/u/hellekin)
#### Post date: [March 16, 2022, 9:32am UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/53 "2022-03-16T09:32:34Z")
I think I proposed this already some time ago in a similar discussion. Let me find it…
- [ActivityPub Support: Phase 1 RFC - #7 by hellekin](https://meta.discourse.org/t/activitypub-support-phase-1-rfc/132624/7)
- [ActivityPub Support: Phase 1 RFC - #45 by hellekin](https://meta.discourse.org/t/activitypub-support-phase-1-rfc/132624/45)
Feel free to consolidate the proposal into a new feature topic.
---
### Author:  [@chrisc](https://meta.discourse.org/u/chrisc)
#### Post date: [March 16, 2022, 7:53pm UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/54 "2022-03-16T19:53:14Z")
We need to reinvent [USENET](https://en.wikipedia.org/wiki/Usenet)…
---
### Author:  [@mcnesium](https://meta.discourse.org/u/mcnesium)
#### Post date: [March 16, 2022, 9:33pm UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/55 "2022-03-16T21:33:47Z")
[Here is another article by Mathew about Matrix](https://matrix.org/blog/2021/05/17/the-matrix-space-beta), a federated platform. Money quote:
> It’s like USENET had a baby with the Web!
😄
---
### Author:  [@sunjam](https://meta.discourse.org/u/sunjam)
#### Post date: [March 26, 2022, 4:20pm UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/56 "2022-03-26T16:20:25Z")
Talking about e2e in a federation discussion makes no sense at all. Can someone move those replies to a new topic please.
---
### Author:  [@Pink2DS](https://meta.discourse.org/u/Pink2DS)
#### Post date: [April 14, 2022, 2:18pm UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/57 "2022-04-14T14:18:33Z")
Maybe the [Lemmy Protocol](https://join-lemmy.org/docs/en/federation/lemmy_protocol.html) is a good start.
You already have the mailing list mode, and it works similarly (except it’s over Fedi).
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [April 27, 2022, 4:44pm UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/58 "2022-04-27T16:44:49Z")
There’s [a Zoom event](https://us02web.zoom.us/webinar/register/WN_2jhG2yOvSCalJyyV7btp6w?mc_cid=5f786dc67a&mc_eid=8c6dec5073) 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](https://blueskyweb.org/), 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/](https://matrix.org/). Matrix is an open network for secure, decentralized communication with more than 40 M users.
>
> > Andre Staltz is Creator of [Manyverse](https://www.manyver.se/), 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](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](https://metro.org/code-of-conduct)
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [May 9, 2022, 1:47am UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/59 "2022-05-09T01:47:06Z")
> [@riking](#):
>
> I think publishing of Discourse topics for remote follow is what should be aimed for.
**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.
---
### Author:  [@sunjam](https://meta.discourse.org/u/sunjam)
#### Post date: [May 9, 2022, 4:22pm UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/60 "2022-05-09T16:22:03Z")
Found [this discussion on activitypub Rails implementations](https://socialhub.activitypub.rocks/t/any-tools-and-tutorials-on-rails-and-activitypub/449/12). Might be worth continuing the discussion there. 🤷
---
### Author:  [@Mr.X\_Mr.X](https://meta.discourse.org/u/Mr.X_Mr.X)
#### Post date: [June 6, 2022, 3:59pm UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/61 "2022-06-06T15:59:48Z")
Any suggestion how I could federate 4 forums? They are pretty big (100k, 20k, 50k, 20k members). Total 200k.
---
### Author:  [@sunjam](https://meta.discourse.org/u/sunjam)
#### Post date: [June 6, 2022, 10:59pm UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/62 "2022-06-06T22:59:03Z")
You cannot federate. You could setup custom SSO or LDAP authentication, which all users can share for accessing each forum from common credentials.
---
### Author:  [@not-ethan](https://meta.discourse.org/u/not-ethan)
#### Post date: [June 7, 2022, 12:03am UTC](https://meta.discourse.org/t/federation-support-for-discourse/90921/63 "2022-06-07T00:03:47Z")
You can also try and make a plugin to integrate them together.
[Previous page](https://meta.discourse.org/t/federation-support-for-discourse/90921.md?page=2)
[Next page](https://meta.discourse.org/t/federation-support-for-discourse/90921.md?page=4)