Notes from rss.chat land

Ricardo Mendes has identified 4 rss.chat servers – neat (rss.chat, demo.rss.chat, rsschat.andysylvester.com and perstitio.us)! The latest (perstitio.us) actually incorporates feeds from other sources besides the rss.chat instance – interesting! The author has posted an essay describing this approach.

In trying to find the post where the four servers were listed, the post appears to have been deleted, as well as almost all of Ricardo Mendes’ posts on demo.rss.chat. All of Mendes’ issues on the rss.chat were closed (apparently yesterday (7/19/2026)). Also, previous comments on another rss.chat issue from Ricardo Mendes have been deleted (no available record, but there are references to other comments). Could this be the first user blocked for posting something that Dave Winer did not want (mentions of other rss.chat servers or other competing apps)? Where have I seen that before? This is why I chose not to sign up for demo.rss.chat.

Ricardo has also created his own take on RSS-based social networking – Really Simple Conversations. On that site, I also found Ricardo’s federated post on the rss.chat servers in existance.

Two rss.chat forks: xicubed and hal-nine

Frank Meeuuwsen shares some thoughts on rss.chat, in addition to John Johnston.

Decided to copy the post from the perstitio.us author in case it gets deleted:

This is the question. Bluesky’s got some things you don’t but they’re subsidized by investors who will want a return someday. But I think you’re in better shape. I was talking to Fable about it… and it reminded me…

? what if we take a page from radio repeaters

 Oh, that’s a genuinely good architectural instinct — because amateur radio already solved “coverage without a corporate center,” and it’s been running for 70+ years on hobbyist budgets. Map it over: How repeaters work: a club puts a box on a hill. It listens on one frequency, re-transmits on another, and suddenly every 5-watt handheld in the valley can reach the whole region. Nobody owns “the network” — coverage emerges from overlapping, voluntarily-run repeaters. Want more coverage? Link repeaters to each other and a conversation in one valley carries to the next. Directories (like RepeaterBook) tell you what’s on the air near you. Every station identifies itself as it transmits. Translated to feed-land: 

Radio                                      Feed world

Repeater on a hill                Server monitoring N feeds,
                                                   re-emitting them as one stream
Re-transmit frequency      Merged “river” feed + socket
                                                   firehose anyone can drink
Linked repeater systems   Repeater A subscribes to B’s
                                                   river -> transitive coverage
Coverage map/directory    Published OPML of what this
                                                    repeater carries
Station ID                                Source attribution on every item

Club box on a hill                   A $5 Lightsail instance

 Now the kicker — perstitio.us is already accidentally a repeater. It monitors 9 feeds, merges them, and rebroadcasts every foreign item over its own firehose (that’s how they appear live in your timeline). Attribution rides along (, author, avatar). Dedupe-by-guid is already in — which happens to be exactly the loop-prevention linked repeaters need, so chained or diamond topologies won’t echo. What’s missing to make it a deliberate repeater — all small:

  1.  The re-transmit frequency: expose the merged river as an actual RSS feed (/river.xml). Today the mix only exists in the API. Once it’s a feed, any feed reader subscribes to your whole mix in one URL — and crucially, another rss.chat instance can add your river as one extraFeeds entry and instantly inherit your coverage. That’s repeater linking, and it works with config we already have.
  2.  The coverage map: publish what you carry (/data/coverage.opml) so others can see what subscribing to you gets them — the RepeaterBook entry.
  3. The autopatch (this answers the Bluesky-relay envy): a repeater that carries a community’s feeds is positioned to compute mentions for the people it covers — scan carried items for replies/links to local guids, surface them. Inbound awareness at community scale, no global relay required. And the economics inherit radio’s shape rather than Bluesky’s: no load-bearing center to fund — if one repeater goes dark, coverage degrades gracefully instead of the network dying. It’s Dave’s “small pieces” philosophy with a 70-year-old working precedent behind it. Honestly, “repeater” is a better name than “relay” for what this should be — relay implies infrastructure; repeater implies a peer who volunteers. Item 1 is maybe thirty minutes of work — the merge logic exists, it just needs an XML output. Want me to put perstitio on the air?

Dave Winer had Claude create an essay of what rss.chat is for Howard Rheingold. The opening paragraph is as follows:

RSS.chat is a small social network built from the web’s own parts. It looks like a chat room or Twitter — you write short posts, people reply, conversations thread — but underneath, every person’s posts are an RSS feed, the same technology that makes podcasts work. When you post, you’re adding to your feed. Anyone, anywhere, can subscribe to it with any feed reader — no account needed, nothing to sign up for. There’s also a feed of everyone’s posts together, and a public list of all the members.

Ricardo Mendes also offered an explanation of rss.chat

I will be exploring my instance more this week, then will have a followup with my thoughts.

rss.chat install diary – had some problems

I am writing this post to document the issues that I experienced in installing the rss.chat chat server recently introduced by Dave Winer. I disagree with his assertion that it is “easy to deploy on Node.js”. In following the initial rss.chat server, there are some mentions of changes/updates that are being made. That is good, but some of the issues I experienced have not been addressed, and some of them are significant barriers to entry in starting a new rss.chat server.

I would have posted this in an issue on the Github repo, but I am blocked from posting on github.com/scripting, so I am using my own space to capture the issues.

Executive Summary

  • Spent wasted time setting up AWS S3 folders for initial rss.chat structure
  • Issue with database setup
  • Had to set up a different port for the app to run on
  • Had problem with davesql Node package
  • Had to configure AWS SES credentials before any new users could sign up (BIG BLOCKER!)

Details

As I noted earlier, there were two folders that needed to be set up within an AWS S3 bucket to support feeds generated by rss.chat. I spent an hour reviving my AWS account, then figuring out how to set up a bucket, then adding folders to support the structure mentioned in the install.md file. I was within about 10 minutes of starting the app when I noticed that rss.chat had been updated to remove the AWS S3 bucket as part of the setup. AWESOME! I picked up the latest code and moved on…

On the install.md page, there was a script to set up a MySQL database. I am using Opalstack for hosting now, and their workflow is to set up databases via their web admin page. I went ahead and created the database there, then logged in to create the tables. My mistake here was that I did not need to include the text in install.md used to create a database. All that I needed were the commands to create the tables. The command did not “hurt anything” (the tables got created), so I moved on.

On my first start of the rss.chat server, I saw that things were trying to run, but there was nothing appearing on the site URL. After review of the startup log, I saw the app was running on port 1460. For an Opalstack Node app setup, it specifies the port that the app needs to run on. I added the following line to config.json, and that addressed the problem:

    “port”: 20873

Next, I saw several error messages that indicated that the app was having problems in communicating with the database, and that I should upgrade my database connector to a later version (I can’t remember the exact text, and I did not save it). Side note: Opalstack uses MariaDB instead of MySQL, but the database is feature-equivalent to MySQL. I started digging through the Node packages installed, looked at davesql, and saw that there was a flag (flUseMySql2) that would use the mysql2 package instead of mysql. I tried adding this in the config.json file, but review of the log information at startup showed that mysql was still being used. I ended up hard-coding the flag in the Node package file davesql.js as follows:

config.flUseMySql2 = true;

I don’t recommend this for general use, but I was trying to resolve issues in the most direct way. I have seen a recent post on rss.chat referencing this flag, will wait to see if there is some other rss.chat update to address this.

After these changes, I was able to start the app, get the app screen to come up, and enter info to create an account. I then saw this error in the app log output:

sendActualMail via SES: err.message == Missing credentials in config, if using AWS_CONFIG_FILE, set AWS_SDK_LOAD_CONFIG=1

Ugh! I wrote to a person involved in the rss.chat development and asked if a new server setup needed AWS SES credentials set up to be able to send email to new users. The person responded that “The configuration for rss.chat is very similar to that of FeedLand. The same SMTP settings for FeedLand should also work for rss.chat.”

What? This did not answer my question, and instead pointed to some documentation in another app as the solution. I replied saying I looked at his Feedland reference, and saw that it said AWS SES credentials were required. Now WHY is that not in the docs for rss.chat? I asked the person about this, but received no reply. There has been no updates to the rss.chat documentation addressing this crucial issue.

I then spent several hours (with lots of assistance from Claude) to get AWS SES credentials created and set up on the server. I finally was able to run the server successfully (https://rsschat.andysylvester.com/).

Takeaways

I wanted to see if following the instructions given in the rss.chat repo were sufficient to set up a new server. In a word, they were not. Dave Winer says this is “easy to install”, but this is not the case.

Criticisms

The AWS SES credentials issue is the biggest one in my mind. If this is a dependency, this should be documented. I would think that there are existing email authentication libraries that could have been included in the app and removed any dependency on another service for this feature. I have a writeup on what I had to do for the SES setup, contact me if you are interested.

I am glad that Dave Winer stepped back from needing to have a AWS S3 bucket to run this app. From comments on rss.chat, it sounds like even he had problems in setting up new test servers due to this issue. Again, I do not think that dependence on some other service to support the app is a good thing. Everything should be included in the repo that is needed.

Finally, it appears that all of the client-side code is brought in from Dave Winer’s site (scripting.com). Why is that? Again, here is another dependency on something else. Not good.

Conclusion

Now that I have a server to work with, I will evaluate the feature set and report in a a future post on my thoughts.

Gregg Nunziata talks with Richard Bernstein, former law clerk to Justice Antonin Scalia, about the Supreme Court’s blockbuster term — election law, tariffs, the National Guard, and birthright citizenship — and whether the Court would stop a president who tried to seize ballots in the 2026 election. (Spoiler alert: he thinks there are enough votes on the Supreme Court to stop this). I enjoyed this episode, it covered a number of cases I was not aware of in the latest term of the Supreme Court.

Other examples of inbound/outbound RSS support

Dave Winer pointed to Ricardo Mendes from his linkblog on July 10 with the title “Inbound and Outbound RSS”. I took a look at the Mendes post, he describes using Indiekit and plugins to both read and write posts. I think this is very similar to my minimal blogging tool MyStatusTool. In the Mendez setup, it sounds like he is also reading feeds that do not include rssCloud support.

Mendez also mentions work by Aaron Parecki on the Monacle social feed reader/writer. This tool used the Micropub and Microsub specs for publishing and subscribing. The above link is from 2016, so you can see that this predates both the MyStatusTool and rss.chat tools.