Federation support for Discourse

You can use feed2toot. It supports multiple RSS feeds and can filter what it re-posts.

1 Like

Are there instruction on where and how to install the option


When I execute the commands
feed2toot --populate-cache -c /etc/feed2toot/feed2toot.ini

I get this error
The parent directory of the lock file does not exist: /root/.config

I saw nothing in the instruction about this file



It has nothing to actually do with Discourse so you’ll want to ask the feed2toot project. Good luck.

1 Like

Thanks James for the information


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 plugin.

1 Like

“Why federated protocols don’t work”


“the value of freedom”

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!


from the end of Matthew’s (Matrix) response to Moxie (Signal)

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 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.


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 appeared, building on email protocols and Autocrypt, 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.


This reads like a separate feature request :wink: would you mind creating another topic detailing this or is there one on this?


I think I proposed this already some time ago in a similar discussion. Let me find it…

Feel free to consolidate the proposal into a new feature topic.


We need to reinvent USENET


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:

1 Like