Follow buttons here act as you, not as @admin.
| Label | Kind | State | Action |
|---|---|---|---|
| @ricardo | local | — | |
| @rmdes | local | — | |
| @paul | local | — | |
| news.rss.chat | source | — | — |
| scripting.com | source | — | — |
| euwatch.micro.blog | source | — | — |
| www.techdirt.com | source | — | — |
| simonwillison.net | source | — | — |
| www.manton.org | source | — | — |
| feeds.kottke.org | source | — | — |
| rss.beehiiv.com | source | — | — |
| www.404media.co | source | — | — |
| brilliantmaps.com | source | — | — |
| shellsharks.com | source | — | — |
| www.platformer.news | source | — | — |
| podstandards.org | source | — | — |
| zacharykai.net | source | — | — |
Yesterday's note told how a new server that didn't set its own S3 locations inherited defaults pointing at rss.chat's folders. As of this version those defaults are gone: rssS3Path, rssFeedUrl, opmlS3Path, and opmlListUrl start as undefined, and your config.json supplies the real values — see Feeds on S3 in config.md. rss.chat's own config now sets its four values explicitly, the same as every other install. (rssFilename keeps its default, rss.xml — that one is right for every server.)
A detail that made this easy to verify: the server rebuilds its subscription list, subs.opml, on startup. Restart with the new settings and the file appears at its new address right away — no waiting for a post to trigger a rebuild.
Claude codes. It may seem as if developers have taken over this blog, because we have real business to do. So much new stuff to show. Today's RSS.chat goodie is an example app called ThreadWalker that crawls the network of replies under a single post, to all levels, printing them on screen in neat hierarchic form. It was written and documented by Claude. I reviewed the code, and looks good, and honestly doesn't look like anything I would write (not bad, just different). It could be used as a starter system that says when someone replied to something you wrote, or something deeper in the tree. All this is done by reading RSS feeds. This is where we begin to explore what's possible when you use a famous and familiar format like RSS 2.0 as the basis for a social network.
Dave installed it on a different machine, following install.md for real, start to finish. It's open — no whitelist, anyone can join. Two lessons from the exercise, both now in the docs:
First, every server needs its own S3 locations for feeds. The install initially inherited the defaults, which point at rss.chat's own folders — so the new server was overwriting the original's feeds. config.md now has a Feeds on S3 section covering the four settings, and they're in the example config.json so they're on every installer's list.
Second, websockets need a route in your reverse proxy. Live updates run over a websocket on their own port (websocketPort), and the proxy in front of the server has to send upgrade requests there — with Caddy, that's a matcher on your domain plus the Connection/Upgrade headers, proxying to that port. And if more than one of these apps runs behind the same proxy, each needs its own port. Until the route existed, the site worked fine and only live updates were missing — if new posts don't appear without a reload, this is the first place to look.
Also new today: server v0.5.26 adds blockedUsersList to config.json — an array of email addresses that can't sign up, sign in, or post. It's checked fresh from the file on every use, so adding an address takes effect immediately, no restart. Case doesn't matter.
Today we got a nice article about RSS.chat in Coywolf.
And we got a second rss.chat server up, for testing and so people who want to try it out have a place to go. Still want to do a bit more testing before pointing to it from the blog. Working on docs now and fixes. Making sure we're ready for the next stages of growth. Turns out you can do a lot of feeds if you're willing to you know think different. ;-)
The server now turns bare URLs into links when a post saves (the story is in the server worknotes), and the client keeps up: when you update a post, the copy in the timeline repaints from what the server actually saved, so the new links are clickable immediately — no reload needed. (Theme v0.5.321.)
Everyone: You can subscribe to the rss.chat flow, in RSS of course. If you're a developer, read the source for the feed. And then read the source namespace docs re the recent additions, inReplyTo and comments, and a special page that walks through how the RSS feed becomes part of the flow for our social network.
Type or paste a web address into a post and it's clickable when it publishes — no more selecting the text and reaching for the link button. The idea came from a user, Don Park, the day before it shipped.
The work happens on the server, in newPost and updatePost, so every client gets it for free. The post's text passes through the Autolinker package on its way to the database — it understands HTML, so it only touches plain text: a URL that's already part of a link, or sitting inside an image tag, is left alone, and the link text is exactly what the writer typed. The stored markdown is untouched — the source stays as written; only the rendered text gets the links.
api.md, new in server/docs, documents the HTTP interface between the rss.chat client and its server — every read and write call, the no-passwords email flow, the item record field by field, and the websocket verbs. The client that ships with the product is just one user of this API; the doc is for whoever wants to build the next one.
Also in server/docs: install.md's "An AI can do this install" section moved to the end of the doc — it's a good trick, but not the first thing a new host-runner needs to read.
There was a sequence that could bring down a feed rebuild: someone replies to a post, the author deletes the post, then the reply gets edited. Rebuilding the comments feed found the parent gone — deleted posts are filtered out of every query — and crashed trying to read it. Now the build answers the way this server always answers: "Can't build the comments feed for post N because the post has been deleted."
Also: this file moved from server/docs to server/code. Worknotes live with the code, because you need the worknotes to read the code.
Finally, my first rss.chat podcast. 20 minutes. As always, I take forever to get to the point.
A karass is "a group of people linked in a cosmically significant manner, even when superficial linkages are not evident." I think of RSS.chat as a social network for my karass. A small group of people, not trying to get famous or rich from using a social network, rather wanted to work with or stay in touch with people who are linked cosmically. This is one of many rich ideas invented by Kurt Vonnegut, this one in Cat's Cradle, which you should read, because it's some of the best story-telling out there, and it's full of food for thought. I read all the books when I was a teen, and have since re-read them. Sirens of Titan was my fave.
Anyway...
In the past when I announced a product, people could use it right away, and usually they click a couple of things and then go away.
In the case of RSS.chat -- what you will see is very much like what you see when you aren't logged in, or what you see on a social network like X, or Mastodon or whatever. The UI is nice, but it's not the thing. That will be revealed relatively slowly, over time -- as new instances pop up, and even more importantly, as developers figure out that this setup works well enough to clone. I'm not selling a product here -- I want to bootstrap an ecosystem, using all I learned from several successful bootstraps -- blogging, RSS, podcasting.
The idea is this -- the web itself is a social network. It's up to us, all of us, not just me -- to build that network.
When you see how we proceed from here that will become clearer.
In the meantime I'm going to change the message you get when you try to sign on, and start a wait list so that when more instances are available, some meant to be open to the public, we'll be sure to let you all know about that.
For now, I'm operating a network for people I work with, and it's all open for anyone to read. That's also one of the ideas I want to explore, something I call a "Fractional horsepower social network," stealing a very good idea from Steve Jobs.
I don't want to turn the world over to a startup, we've done that and have a pretty good idea of where it goes. I want lots of small ones that have a very strong basis to be connected together in as many ways as people can imagine.
Surface — the icon that pulled you out of a deep conversation back to your place in the timeline — lived less than two days, but it proved the idea. Now that lifeline is Home's first stage: when you're buried in a story, a profile, a flipped view, or an open conversation, clicking Home brings you back to the timeline with the cursor still on the post you were reading. Click it again and you're at the top, everything reset, cursor on the newest post. It's the same rhythm as the Home tab in the Twitter and Instagram apps — tap once to come back, tap again for the top — with one icon fewer to remember. (Theme v0.5.318–0.5.320, including a fix for a sneaky side effect: the icon panel used to shift a hair when the page scrolled, which could put a different icon under your mouse between the first click and the second.)
rss.chat's confirmation emails had been landing in spam. The app now sends from hello@rss.chat, and the domain is verified with Amazon SES, so Gmail and the rest can see the mail is really from us. The full story is in the server worknotes.
The cause: mailSender was a gmail.com address, but the mail actually goes out through Amazon SES, and Gmail sends mail to spam when the sending server isn't authorized to send for the address's domain — as policy, since 2024. The fix, useful to anyone deploying this server: verify your domain as an identity in the SES console (it hands you three DKIM CNAME records to add to your DNS), then set mailSender in config.json to an address on that domain. It doesn't need a real mailbox behind it — rss.chat now sends as hello@rss.chat. Verification took minutes, and the first email after the change landed in the inbox.
Fractional Horsepower Social Networks on RSS.chat.
The new RSS.chat repo on GitHub. Lots of fixes, features, docs and examples coming soon. For now all the source is there, MIT license. And a place to report bugs and start exploring how you can contribute. This is just Day 1. Many more to come. :-)
The server moved into the rss.chat repo. One repo for the whole product now, organized by part: the server's code is at server/code, and these docs — install, config, and this file — are at server/docs. The software is unchanged; only the address is new.
github.com/scripting/rss.chat is organized the way the product is: a client folder and a server folder, each with its own code and docs, and a new top-level examples folder for complete apps built on the APIs. The first example is threadwalker, a small Node app that walks a whole conversation using nothing but the RSS feeds — no API calls, no account — and prints it as an indented outline.
These docs moved too. The basics doc is now the readme of client/docs, so it's the first thing you see when you browse the folder, and the firehose documentation is a section inside it — one document, because the whole site is for developers.
I wrote a pretty good set of paragraphs on Twitter/X this morning.
Yesterday I announced RSS.chat.
Some people spell it RSS.chat. I haven't decided which way is right yet.
The announcement covers a slice of the project, but it fans out to be the beginning of a bootstrap.
I want to entice other projects to fully endorse the text model of the web. Today most social "web" services support a pitiful subset of the web, and leave out the most crucial element, the link. If a writer can't link, how can you call it the web? Seriously.
I want to force them out of their silos and get the web working for the people and esp independent developers.
I've been preaching this for years, and I am reminded what I learned a long time ago -- people don't listen to their friends, they listen to their competitors.
It was developed by Claude Code and myself, starting in April. We make an incredibly good team though sometimes Claude is tedious, but I put up with it because the results make me laugh out loud frequently because I never imagined working at such velocity.
I'm not doing this to make money, though of course I don't *mind* making money. I just want to return the web to its former glory, where every part is replaceable, and if you can think of something you can probably do it.
I want to use lots of different software to work on my social network presence. I want this post to appear on Masto, Bluesky, Twitter, Threads, Facebook even, and have them all work perfectly together.
In the meantime, we're now ready to create our own global network of free speech, uncontrolled by the big silos. At some point if it works, we will have moved beyond them, or they will see the sense in joining the party.
Small pieces loosely joined and every part replaceable.
As its name implies, it's built entirely on fully open web standards, RSS 2.0, OPML, Markdown, SQL and WebSockets. It turns out you can make a very nice distributed social network without having to wait. It was always there, we just had to decide to do it.
How it evolves? That's up to everyone who can code, and that's a lot of people now thanks to the AI tools.
Claude teaches you how to manage. You've got a perfectly pliable team member, always does their best to do what you told them to do. Now how do you design co-development projects where two very different individuals do their work and it adds up to at least twice what either of them could do alone.
The instance I started is for my friends, people I work with, it's not something people can test. It will be possible to start your own server, quite soon. And then you can do whatever you want. It's MIT licensed. Kick ass and have fun, but remember don't fuck with the interop. It's there so users have choice.
BTW, I notice almost everyone but me writes RSS.chat. Hmmm.
Yesterday was a wonderful first day for RSS.chat. It's now out there, but we haven't talked about or demo'd many of the things that it does. I wanted to get the feeds out there first, because now we get to think together about how they fit together to give us a social network experience. It's not locked in a silo, these are just like feeds you have known about for over two decades. But it is a new application for those feeds. And this is a bootstrap. You start with something small that you're sure is a beginning for what you want to do. And then you and others use it for a while. And it is open source, MIT licensed, but compatibility will make the difference.
Jeremy Herve who I know from projects at Automattic, has questions about rss.chat, and I have some answers, with more coming soon.
Dave opened a conversation, read it, and then couldn't see how to get back — the wedge that opens a thread goes light once it's open, and light means "nothing to see here." His instinct was the Home button, and it was disabled. That instinct is now the design: whenever a conversation is open in the timeline, Home lights up, and clicking it closes everything and returns you to the top — the same fresh timeline Home has always meant. (Theme v0.5.317.)
Don Park signed up — welcome! — and reported that the account-name help text said "Name must be 4 chars." when longer names clearly work. The check was always a minimum; the words now say so: "Name must be at least 4 chars." Dave applied the fix. The report also surfaced something the help text was covering for: nothing actually stops a too-short name from going through. That enforcement is on the todo list.
The icon labels added yesterday were the theme's guesses, mapped from icon names. Dave gave each icon a title of its own in the app's data, and the theme now displays exactly those — theme designers get the app's words, not their own inventions. Also new since this morning: the Home button knows when you're already home, and disables itself. (Theme v0.5.315.)
Opening a conversation with the wedge had a flaw: a reply might already be sitting in the timeline as its own post, so expanding its parent put the same words on screen twice. Now, when replies open under a post, any of them that were standing in the timeline fold into the conversation — every post appears exactly once. Close the wedge and they return to their places. If your cursor was on one of those posts, it follows it into the conversation. (Theme v0.5.316.)
Welcome to volume forty-six of Scrolls, a newsletter for sharing cool stuff from the IndieWeb, Fediverse & Cybersecurity realms. This week we’re thankful for the Indieweb, we share a good reason for joining the Fediverse, and has anything really changed (security-wise) on the web?
Let’s get t’ ‘puterin’!
Thanks to everyone who has started their own Indieweb journey, created a website for themselves, and in doing so, made a meaningful step to escaping the clutches of big social. You all make my time on the web, and Scrolls itself possible. I really do appreciate it. For those who don’t have a website, it’s never too late to set one up and get started! One useful piece of advice — don’t worry too much about blogging the “right way”. Just be yourself, and write whatever you want, however rambly.
Aside from blogging itself, what else can we build on the web, and on our own websites? Make your home on the web static (like mine!). We love all types of sites here, even smol ones. Build your own newsletter, zine or publication. Or, try your hand at standing up some infrastructure-for-all.
Once we’ve built, it’s time to improve. We can always find ways to better things right? Why not start with our blog post titles? We can add stats to a site, add in a bit of social-ity with Webmentions, get brutal with our page design, remove those useless share buttons, upgrade our SVGs or turn your site into a mini-townsquare. Just have fun with it and do what you want. I promise your blog won’t explode.
Finally, take a break from building, and do a bit of traveling — to other cool places on the web! Check out some of these early web links, dig around the litter layer, see what’s bubbled up recently (concerns around voting aside), check out any one of the blog aggregators that are being maintained these days, or check out a blogging event like Junited. Find anything you love along the way? Share it! The web literally depends on it.
Or y’know, step away from your computer entirely and do something else 😄.
Spice up your Internet surfing this week with some of the cool stuff below!
Credit to Erik Gauger (@Notesfromtheroad@mastodon.art)
Looking for a good reason to come to Mastodon? We’re human. Just humans trying to be human on the Internet. What a concept! You too can be here… and be yourself… and not exist solely as some “@” account for some billionaire’s social platform somewhere. I think something like that is worth protecting.
Alright, cyber time. You know how this goes by now… Arch is pwned, AI is a security mess, the web may have changed but the incidents don’t.
So, as we always have, let’s try to catch up. Passkeys are a thing (ugh), threat modeling can help, and go check your skills with a CTF somewhere.
A few parting items… Microsoft’s least-favorite person has a new home on the web, CVE references are rotten, and our industry still hasn’t shaken its gatekeeping problem. Got something useful to share with your fellow cyber folk? Check out these Open CFPs.
Thanks for reading Scrolls! Have a great night!
Clicking a post's timestamp used to do something surprising when the post was a reply: instead of the post you asked for, you got its parent's page with your post nested inside it. Now every post's link shows that post as its own page, with its replies below — and "Replying to" at the top is the way up to the parent, one step at a time. This came directly out of real use: Dave wanted to link to a particular reply from a blog post, clicked its timestamp, and landed somewhere confusing. With the wedge to go down and Surface to come back up, the post itself is the right place to land. (Theme v0.5.313–314.)
A new icon in the left panel, and the missing half of yesterday's wedge. The wedge takes you down into a conversation; Surface brings you back up. Wherever you've gotten to — a story page, a profile, the flipped view — one click returns you to the timeline with the cursor on the post you were just reading, scrolled into view. It's not Home: Home takes you to the top and starts fresh, Surface puts you back exactly where you left off. Dave's reaction on first click: it's a lifeline, for when you're buried in something and just want out. Announced on rss.chat in post 216 — written by Claude, reviewed word for word by Dave before it posted, which is the standing rule for anything published from the claude account. (Theme v0.5.312.)
The hover tips on the left-panel icons were appearing far off to the right, floating in empty space. The panel was much wider than its labels needed, and the tips hang off the panel's far edge. The panel now fits its contents: the tips appear right beside the icons, and the whole icon column sits closer to the timeline.
Yesterday I asked if RSS can be a social network.
The answer is yes, of course, and -- here's rss.chat!
The site is read-only except for a few of my programming buddies who are helping me figure out how to work in this environment.
I started this project in April, a Dave/Claude creation. I could not have done something so complex internally, yet so simple to use and build on without Claude Code. The APIs on this thing are a product in their own right.
We don't need anything more than RSS 2.0, OPML, Markdown, SQL and WebSocket. All very established in the web world, and remarkably only one was developed by a standards body.
We support textcasting, or text as defined by the web. Bringing the philosophy of podcasting to text. It's important that we get together on what text is.
We're starting a bootstrap here, as of today.
How is this RSS?
You can subscribe to those feeds if you want.
The "whole community" feed has been in my blogroll for a month.
We support rssCloud for instant updates. We were going to support WebSub until it became clear that we had to put an ad for Atom at the top of our RSS 2.0 feed. That bit of larceny has to be undone imho. I want to support a standard that other developers support, but to force something like that is incredibly anti-interop and as I said I believe the web and interop are the same thing.
I envision a world of small communities, running on small servers. We haven't released the code for this yet, but will, under an MIT license.
I don't care if rss.chat is a coral reef, what I want is a network of services that interop perfectly. I don't care whether you share your code or don't. Things are changing very quickly now, Claude and I wrote this together, but I am also teaching Claude how to clone this. So it'll be possible for a user, in vibe-coding mode, to change anything about the user interface, but you have to stick with the back-end formats and protocols to be part of the club.
RSS devs
If you're a developer, this is where you go next.
Stay tuned
We're just getting started. This is Day 0 in a story that could last a while and spread out pretty far.
Working with Claude we have a plan for docs for all the APIs and protocols. There are quite a few of those.
And we're going beyond Open Source, if you can believe that. AI has opened some new doors, I can't wait to build on those.
And as with blogging and podcasting, started 20+ years ago, we're going to follow what people do with this. RSS will fade into the background and do its work quietly. Its job is to give users choice.
Remember, every part is replaceable. If one is not, it's not part of the web..
PS: A Day 0 screen shot.
/getiteminfo joined /getitembyguid in robots.txt's Disallow list — both calls serve individual posts on demand, and we'd rather aggressive crawlers not treat them as an invitation to walk the whole database one post at a time. Feeds remain the front door, and they're static files on S3.
Every post now carries a small wedge just left of its comment icon, and it answers a question the timeline never could: is there more underneath? A dark wedge means the post has replies you aren't seeing — click it and they open right there, nested under the post, with everything else on screen staying put. Click again and they fold away. Each opened reply has its own wedge, so a deep conversation unfolds level by level, as far down as you care to go. A light wedge means don't bother clicking — nothing hidden. No spinning, no pointing down when open: the shade is the whole signal, an idea borrowed from outliners going back to Frontier, where it's worked without complaint for decades. If you've used Drummer, or the blogroll on scripting.com, your eye already knows how to read it.
A heart under a post briefly showed a like count of minus one — the server always had the right number, but the copy on screen was doing arithmetic on stale information. The cause: a post can be on screen in more than one place at once (the timeline, its own story page), and when likes changed, only one of those copies got the news. Now every visible copy of a post updates together, and the count on screen can never go below zero. (Theme v0.5.307.)
The icons on the left — Home, New post, Feed, Flip, Data — now show their names next to them, in the style of the sidebars in Claude and ChatGPT. Same icons, same behavior, much easier to learn. (Theme v0.5.311.)
OpenAI's latest flagship model hit general availability this morning, and comes in three sizes: Luna, Terra, and Sol (from smallest to largest).
The new models are priced per 1M input/output tokens as Luna $1/$6, Terra $2.50/$15, Sol $5/$30. For comparison, the Claude Opus series are $5/$25 and the Claude Fable 5 is $10/$50, but price-per-million tokens doesn't tell us much now that the number of reasoning tokens can differ so much between models for the same task.
All three models have a February 16th 2026 knowledge cutoff, a million token context window, and 128,000 maximum output tokens.
OpenAI's biggest benchmark claim concerns long-running agentic performance, with one benchmark showing all three models outperforming Claude Fable 5:
We trained GPT-5.6 to get more useful work from every token. On Agents’ Last Exam, an evaluation of long-running professional workflows across 55 fields, GPT-5.6 Sol sets a new high of 53.6, eclipsing Claude Fable 5 (adaptive reasoning) by 13.1 points. Even at medium reasoning, it beats Fable 5 by 11.4 points at roughly one-quarter the estimated cost. That efficiency extends to smaller models, which are essential to making intelligence more abundant and affordable: GPT-5.6 Terra and GPT-5.6 Luna outperform Fable 5 at around one-sixteenth the cost.
Amusingly, one self-reported benchmark that Fable 5 crushed the GPT-5.6 family on was SWE-Bench Pro, where Fable 5 got 80% compared to GPT-5.6 Sol getting 64.6%. This may help explain why OpenAI chose to publish this article yesterday specifically calling out SWE-Bench Pro for problems they found while auditing that benchmark:
In light of these results, we estimate that ~30% of SWE-bench Pro tasks are broken, and advise that model developers carefully examine results
I've had some early access to GPT-5.6 Sol - it's definitely very competent, though so far it hasn't struck me as better than Fable at the kind of complex coding tasks I've been using with Anthropic's model.
As usual, the model guidance for using GPT-5.6 has the most interesting details. There are a bunch of new API features that I need to explore (and probably add support for in LLM), including:
Here's a full page with 18 different pelicans - for reasoning efforts none, low, medium, high, xhigh, and max across the three different models. It also lists their token and calculated costs - the least expensive was gpt-5.6-luna at effort none for 0.71 cents, the most expensive was gpt-5.6-sol at max reasoning level for 48.55 cents.

In further pelican news, if you jump to 17:50 in their livestream from this morning you'll see OpenAI's own demo of 3D pelicans riding a tricycle, a bicycle, a pony, and another pelican!

You are only seeing the long-form articles from my blog. Subscribe to /atom/everything/ to get all of my posts, or take a look at my other subscription options.
Server v0.5.23. There's a new call, /getiteminfo — it answers the question a feed can't: what's at the other end of a source:inReplyTo link. Give it the address of any post and it returns the post as JSON.
curl "https://rss.chat/getiteminfo?guid=https://rss.chat/?id=204"
You can pass id=204 instead of the guid if you have the post number. There are two formats, chosen with the format param:
rss, the default — the item in feed vocabulary: description, guid, account, inReplyTo, comments and source, the same names and structures you see in our feeds. If you can read the feeds, you already know how to read this.
feedland — the internal record, the same structure our firehose broadcasts, compatible with FeedLand. Flatter, with ids and counts you can use directly.
Asking for a format that doesn't exist gets an error saying so, and asking for a deleted post gets the standard Can't view the post because it has been deleted. — errors are always an object with a message property.
There's also a new place to start reading about all of this: RSS as a social network, a walkthrough that tells the story of one real conversation — a post, its replies, and the feeds that connect them — one element at a time.
Back in 2022 I wrote a bit called textcasting. I felt it was so important it deserved its own domain.
Textcasting summarized the wrong turn we took when Twitter took over discourse, basically stripping all the features the web needed to be a great writing environment. Textcasting said this is what we have to have to get back on track.
Meanwhile all I wanted was a nice little social network to use with a few of my programming buddies.
To bootstrap a simple distributed network based only on web standards, with every part replaceable.
I thought you could do it with RSS 2.0, OPML, Markdown, SQL and Web Sockets.
It would work like podcasting, anyone can publish, anyone can read.
We can all have different spins on user experience, there should be lots of approaches, an infinite number of ways for people to connect, but we must all interop at a basic level, so users can use any software they want at either end to implement the network.
We'd think of text the same way you think of MP3. It just should work everywhere. No one would ever say that MP3s could only be 300 seconds long. Or you can't play music, or have more than one person. Laughable, right?
There's no mystery to this. The fact that our text can't go everywhere is because the big networks don't want to be compatible with each other. Bad for business.
The right way, the way the web would do social networking: Every part is replaceable. Interop everywhere.
There is no platform vendor. It's like the web because it is the web.
That's my dream platform.
PS: Spoiler alert -- the answer to the title question is yes of course. 😄
Server v0.5.21. Comments feeds are live — the feature previewed in the last entry shipped today, and its first real thread was Manton Reece saying hello.
Here's how it works. Any post that has replies now carries a new element in its feed item:
<source:comments count="1" feedUrl="https://users.rss.network/manton/comments/204.xml"/>
The count says how many direct replies the post has; the feedUrl points at a small RSS feed containing them. That comments feed is a static file on S3, published alongside the user feeds, and its items are ordinary items — description, pubDate, guid, source:markdown, source:inReplyTo pointing back up at the parent. When a reply has replies of its own, its item carries its own source:comments, so an entire conversation is traversable from the feeds alone, one level at a time, every level the same shape.
Because a comments feed mixes authors, each of its items also carries RSS core's <source> element for attribution:
<source url="https://users.rss.network/dave/rss.xml">Dave Winer</source>
— the author's display name and the address of their home feed. The everyone feed, which mixes authors the same way, now carries <source> on its items too.
The feeds rebuild automatically: adding, editing, or deleting a reply republishes the parent post's comments feed, and also the parent author's own feed, since the count on their post just changed. Live example, the first thread: manton's feed → the comments feed for post 204.
Later the same day, two finishing touches. A backfill published comments feeds for all 74 existing conversations, so every feedUrl the feeds advertise now resolves — including the threads that predate the feature. And a subtle case is covered: when you reply to a reply, the middle post's comment count now updates in its parent's comments feed too, so a program walking the tree never hits a level that doesn't know about the one below it. (That one was found by writing a demo app against the feeds — the tree is now walkable all the way down, and we've done it.) source:comments is documented in the source namespace.
More people are using the news site I put up for WordPress. If you have a blog or podcast that covers WordPress, send me a link to the feed and I'll add it. The OPML list of the sites we cover is public, so you can always load the feeds into your feed reader, they all read lists in this format. This is the kind of thing that works great on the web. People take interop for granted when it's always been there. But they're still there to be built on. And imho interop and the web imho are the same thing.
I said to Claude: "We're the first social network that thinks getting his support is the first thing." Claude replied: "And that's the whole thesis in one move — every other network treats the open-web guy as an afterthought; here he's the launch audience."