Next test post. We made it so that the server automatically chops off extraneous blank lines at the end of a post. Sometimes they pile up after editing and you can't see them. They shouldn't be in the feed, so we take em out. So this post will have many blank lines at the end when I publish it.
Result -- it works. ;-)
BTW, changes like this will be merged with the repo at end of the work session. And I'll updated demo.rss.chat once, at the end of the session.
We're working on a new example toolkit, this is a test post to see if it worked.
@dave, is there a description of the heuristics rss.chat uses to display Replies?
AFAICT it's:
Is above accurate?
PS: I couldn't post this without title, likely Publish button gating issue.
People assume rss.chat is going to go the same route as twitter or mastodon, and it isn’t.
This is going to remain a small group. That doesn’t mean our posts can’t be viewed in other places, together, as collections of people you follow. We already have experience doing just that, in feed readers. The user interfaces there might be different. And there can be more elegant ways of editing your subs. And sharing subs among services. We already support that tech in FeedLand, btw.
The social networks we’ve been using have a lot of dead ends, by design, lot of “you can’t get there from here.” We’ve got the opposite philosophy. Small pieces loosely joined and every part replaceable. That gets you to new places we’ve never been before.
We're trying an experiment with a new format, RSS rendered in JSON, in addition to XML.
https://rss.chat/feed?screenname=dave&format=json
This only applies in that one kind of feed, the other formats haven't been modified, but we do plan to do this across the board. If we generate something in XML we will also generate it in JSON.
Just wanted everyone to see this, it's not earth-shaking -- but it's time to put this out there. For whatever reason no one listened to RSS, but imho it had something to say. :-)
A peptalk for devs.
http://scripting.com/2026/07/18/143021.html
I just started writing about where we are, one week after launch.
Yeah it's only been a week! :-)
New on the repo today, for everyone here building outside rss.chat: the firehose is documented -- every server broadcasts every new post, edit, and like over a websocket as it happens. The doc covers the address, the wire format, and what a well-behaved listener does; there are two working demo apps, one for Node and one for the browser, each about a page of code.
Docs: https://github.com/scripting/rss.chat/blob/main/server/docs/firehose.md
Demos: https://github.com/scripting/rss.chat/tree/main/examples/firehose
It's the same protocol FeedLand uses for its firehose, so a listener written for one can listen to the other.
This is a test post for an experiment claude is running.
Well... rss.chat has a sibling or a cousin, not sure :) https://textcaster.app
BTW, never in a billion years will any of my software ever require a title.
Test new post after cache clear in the browser.
This is a test. This item does not have a title.
New feature.
If you open a second copy of rss.chat in a different tab, the version you left behind will put up a dialog saying you can either close the tab or reload the page.
This keeps us from losing data. ;-)
When we're talking about the rules for interop with rss.chat, is there a specific name we're using? Like, would it be an "rss.chat" WordPress plugin?
I read the interaction here: https://demo.rss.chat/?id=57 and the part where you said "treat comments as blog posts with their own permalinks" made me wonder, because this is not a rule from Textcasting.
For instance, I could in the main feed add `` and link to a comments feed (like https://test.geekity.com/2026/07/16/hoopla-world/feed/), but those comments don't have permalinks, just an anchor tag to the main post. So this wouldn't be compatible?
New rss.chat feature: It now supports feed discovery, so you can subscribe to any html page on a rss.chat site, in a compatible feed reader.
I tested it in FeedLand and NetNewsWire and it works.
BTW, I told Claude yesterday that we will support images in posts. I wanted it earlier when chaos still ruled (believe me it was very hard to use at this time) and it talked me out of it, saying it was too expensive.
I don't think it will be too expensive. And if it does, then we'll find a way to get money flowing through this project without holding things up.
I've been thinking about the source:account element. Having service as a string like "instagram" makes sense because it's a single instance. For "mastodon" it's okay because the domain of the service is in the username. But I'm wondering if this will become an issue as more small services get spun up.
Should service be a URL to the service homepage? Maybe the service is on a specific port or running from a folder on the server. I know there isn't anything in the spec that says it can't be a URL, but would it be useful, since this is being parsed by a feed reader?
If we want to keep it just a label for the service, should there be an optional url or href element linking to the service homepage?
Here is the localhost/vps deployment if anyone wants to test it : https://github.com/scripting/rss.chat/issues/2
Tomorrow the plan is to add a new websocket-based way of making sure that only one copy of rss.chat is running at the same time. When you log on, on another computer or even on the same computer, this creates another copy of appPrefs.
If you change something, they get saved to the server. Meanwhile on another machine it doesn't have the new version, it has values that you don't want to write over the ones you changed on the other machine.
So when you log on, the server sends a "goodnightkiss" message to every copy it's connected to with your username. They then put up a dialog saying if you want to continue using rss.chat you have to reload.
All this is working in WordLand and FeedLand, so it's pretty likely it'll work right away. I know that sounds cocky, but that's how it's been going. It's like Claude is both a compiler and runtime, and I haven't seen any mistakes go by it without it catching them.
There's now a feed icon on every post.
When you click it a new tab opens with the post, ready to paste into your feed reader.
A blog post with a screen shot and explainer.
Title of the menu -- RSS & OPML.
Links to the RSS 2.0 spec, the OPML 2.0 spec, source namespace and the RSS as a social network walkthrough.
partly history, partly deliberate design.
History: rss.network was the project's earlier name — the server is still rssnetwork.js and calls itself that; the client later became rss.chat (his worknotes from July 3 mark the split).
Design: rss.chat is the dynamic app — the Node server, the API, the websocket — while users.rss.network is just a domain pointed at an S3 bucket of static feed files (and data.rss.network for the OPML).
Feed readers poll relentlessly, so serving feeds as static files means that traffic never touches the app server, feeds stay up even if the app is down, and it embodies his core claim: your feed is a durable artifact anyone can fetch, not an API response.
My instance keeps that same static/dynamic split — it just does it with one domain and a /feeds/ path on Caddy instead of a second domain, since there's no S3 in the picture.
We just converted both rss.chat and demo.rss.chat to use a different storage system, instead of using Amazon S3 to store the feeds, we're storing them in our database. So instead of there being two domains for on system, now there's only one. Cuts out one of the most complicated parts of setting up a new instance.
So if this works, it will show up on the blogroll on Scripting News, which is watching the old url, which should redirect to the new one.
The URLs for the feeds have changed. If you haven't subscribed to any of the feeds here, you don't need to do anything. But if you have, you should read this note, and subscribe via the new URL and unsub from the old one.
Just thinking out loud, but... if I subscribe to the "everyone's feed" https://users.rss.network/rss.xml in my RSS reader, I obviously see each entry, but there is no way to know who is the owner of the post.. if we'd push this idea further down the road of a "social network powered by RSS" I would love to be able to see right upfront "who" is the author of the post, a bit like we do in the rss.chat UI, i guess this is why the "client" exist, but I was wondering if we could make ANY rss feed reader able to display "rss.chat" streams with proper user attribution
There's a Docs menu, so now I have a place to put links to docs. Coming soooon.
Another idea that I'm thinking out loud as I write this down :
What if I could get a notification if/when someone directly replies to me, either using websub or perhaps an external notification provider (ie: ntfy.sh)
Another Idea, this time regarding authentification :
it would be probably trivial to enable IndieAuth authentification on rss.chat, this would allow me for example to auth with my own website, using my own h-card to provide, email, username, etc. this would allow anyone supporting indieweb building blocks to login without bothering with email or with more complex SSO dependency (github, google, etc)
In setting up the new server I forgot to configure the location of the S3 files for the feeds so we were overwriting the feeds for rss.chat.
When I post this, my personal feed and the everyone feed should rebuild and be good.
Awesome work Dave (@Dave Winer)!
As the new guy here I sure hope I don't come off as a curmudgeon (yes I'm old but I'm not bad- tempered ;-) ), but I opened issue #3 on the repo. I was trying to respond to @Ricardo on my iPhone when I couldn't. After drinking my coffee, I realized I wasn't logged in. After finishing my muffin, I realized there was no way to login in. Now it's lunch time and I've posted an issue. I almost feel bad for doing it - like picking nits. I'll go quiet. I'm going to eat my sandwich.
Excellent. Love Localhost it's a great sandbox. Umm ... localhost too.
You could use unfurling/opengraph to even display a nice embed card of these links if the origin has it :p
Good morning sports fans!
This is the URL of one of the many blog posts I wrote over the weekend.
http://scripting.com/2026/07/12/121948.html
I also did a podcast.
https://shownotes.scripting.com/scripting/2026/07/12/myFirstRsschatPodcast.html
If you want to know where we're going, listen to the podcast. I ramble a lot, people who have heard me speak or talk on the phone know that I do that a lot. But if you're using rss.chat, esp if you're a developer, the ideas here are new, when applied to social networks on the web.
What you'll see there is a consistent theme, the action isn't in the rss.chat client, which is nice for sure -- but it's just the beginning. It's set up so that it can easily be replaced, on both ends, in the client or the server.
Ricardo, who we'll get to know, is a developer who is already signed on to this philosophy, and is running a FeedLand server, wants to get going with the server here, and I say yes! That's the way to go. We have to create a wave, to reinstate the web as the home of social networking on the web (saying it that way sounds silly, but people need to be reminded that the web is still there, and ready to be of service.
It so happens my first big task for the day is to create a second server for myself, thus testing the install instructions, and also to have an answer for people who want to kick the tires. This one will be open to anyone. No whitelist.