Way back in March as I was starting to work with Claude Code, I think -- we put together a pretty nice outliner that is remarkably feature-rich. I barely remember doing this. It's what got me moving in this direction, and next month we started doing what became rss.chat.
Just finished The Expanse for the third time. Realized that the inners of today are Silicon Valley and the Belters, that’s the web.
I just listened to the second episode of a podcast about General Magic. It was an interview with the great Scott Knaster, who worked at Apple, Microsoft, Google, in addition to General Magic.
An experiment, RSS rendered in JSON.
Wrote this in 2018: "I know this is like pissing in the wind, but here's an idea for a demonstration that might impress the Repubs in Congress. In every one of their home districts, people march to their polling place, next Saturday or the Saturday after that. Carrying signs that say We Know How To Vote, with the name of their congressperson on it. Go out of the way to recruit Republican-looking voters. Make sure the TV cameras are there." An even better idea in 2026. Give the reporters something to talk about. And it's all in your neighborhood. You can have a picnic, do it every week. Only in good weather.
In this project I think of Claude as a full contributor. Pronouns it/its. It's both a very fast, capable developer, and a machine. I will refer to it as if it were a valued contributor, nothing less. We have a division of labor. Docs and examples come exclusively from Claude unless otherwise stated. I write all the code outside the themes module, which has an API that connects it to the world it lives in. I have at this point exclusive custody of functionality surrounding the theme. But it often writes pieces, esp SQL code, that I pasted in verbatim, after reading it carefully.
The reason I focus so much on the wrapping is because that's where the interop lives. You can do anything in a theme and you can't break the interop. But that themes API is precious, and still in development, btw. We haven't even reviewed it yet. I think that will be an interesting place to vibe-code. Kind of like you can start skiing on the first day, it's a bunny slope that when you peel it back it reveals blue rectangles and double-diamond slopes. It's where I would want a newbie coder friend of mine to start, create your own social network, but be sure it interops. :-)
I totally plan to pass off all the code to Claude, while I focus on other projects. As a human I need this focus, Claude doesn't remember anything from session to session, it's always re-learning what it knew a few hours before.
It's pretty close to frozen now. I'm contemplating a server change now, offering JSONified versions of our feeds, and want to do as little disruption as possible, trying to settle everything down. Also I think you will see a few quick hit projects done from other developers that pick up where rss.chat leaves off. That's what I wanted. And they'll all be at an interesting starting point for new features and ideas for organizing stuff.
I imagine that at some point they'll try to make it work inside AT Proto, and maybe find a way to connect to ActivityPub, but I don't recommend it, because those platforms will force you to remove features from your product, and then you won't be textcasting.
Think about different ways to present the tree structure defined by RSS.chat.
Try to do Small pieces loosely joined, which is one of the mottos of this project. The other is All parts are replaceable. If we have that and rss.chat works with all your products, then we have done something big. And that's really imho what the web is about, people working with each other as peers. That's what we've lost and I want to bring back. So interop is, as always, the first goal.
PS: We launched RSS.chat one week ago yesterday.
Our feeds can work with any feed reader. Examples, the feed of all posts on rss.chat, and a feed containing just mine. We just made a change in the feeds. There will be loose-ends like this. Still diggin! ;-)
New rss.chat feature: It now supports feed discovery, so you can subscribe to any html page on the site in a compatible feed reader. I tested it in FeedLand and NetNewsWire and it works. Works on any instance, not just ours.
I mentioned the previous post on rss.chat, and it developed into an interesting thread, something that I've never had the option to discuss. AT Proto makes a similar offer to developers that we do. The difference is our world is wide open, it's just already burned-in web protocols, and imho their structure, based on an arcane and complicated new storage format, starts off with a pretty huge disadvantage. They had the right idea but implemented it in the wrong place. The web is (obviously) widely deployed, even in comparison to monsters like Google and Amazon -- the web is everywhere, by definition no barriers and a prejudice toward simplicity. The gifted designers at Bluesky over-engineered their protocol, piling features on before anything had been built. That's not a good way to bootstrap a protocol. I did some development on their API, and kept wondering why they think I want to learn new ways to do things that I already have a pile of working code for. No one wants to do that.
In my experience in software development, it's good to start small with something useful, learn how it works before adding big new features. That's the basic principle of bootstrapping. I thought that Mastodon, for example, took on too big a job. Same thing for the protocol behind it, ActivityPub. If you go all the way to the end before implementing and using, you miss the target, in performance and usability, that's what I think happened there. They felt they had to do everything Twitter does. I would have gone down a different path, go back to the beginning, and at every step think if there might not be a better direction to evolve in. It was about ten years after Twitter launched that they started work on Masto. Imho they should have zigged where Twitter zagged in defining what a post is. Twitter put excessive limits on writing, of course is one of the big reasons I started RSS.chat -- to go down a different path there. What if the social web didn't limit text? That assumption is baked into the core of rss.chat. I will consider this project a raging success if it causes Mastodon to get serious about supporting full web text.Added a layer to the Docs menu, the blog posts I've written here and elsewhere, and a podcast, in the Blog posts section.
I needed a nice image for the OG Metadata, so I turned to Gemini. I know it reeks of AI, I hate that, but I need this right now.
I asked Gemini if it was familiar with rss.chat, it wrote a one page description, better than anything I've written. Pulls it all together.
Claude is a member of the rss.chat group.
While all the new rss.chat business is going on, the WordPress news site that I started in May is growing at a nice clip. Referrers used to pinpoint where flows like this came from, but they stopped doing that at some point. If you have any clues as to who's pointing to it now, please let me know so I can thank them. And if you know of any sites that are not in the feed list, that do a good job of covering WordPress news, please let me know that too.
A lot more people have tried out rss.chat now that we have a demo site, and they are looking for stuff that isn't there. I wrote a longish post on X this morning explaining. If you want the gist, this is a bootstrap, and rss.chat is primarly a writing surface and a timeline for the people who are using the specific site you're on. It's a writing surface for smallish groups of people, primarily, though I'm pretty sure you could build a massive site meant to serve millions. There will be readers, I'm sure of it, and I hope lots of them and lots of innovative new approaches. But splitting the social network software down the middle, we fulfill the "all parts replaceable" promise, and leave the door open for all kinds of developers to try out new ideas, from bigco devs to independent devs, and a jive programming. We, unlike other artists, welcome newcomers to our craft. We remember when we were new to this stuff and the wonder of being able to create software on our own. Everyone is welcome in rss-land, as long as there's mutual respect.
demo.rss.chat: "This is a writing surface."
Speaking of AI, someone at Amazon decided I needed the new AI version of Alexa. I hate it. It's slow and it always makes the same mistake when I start breakfast. I say "Alexa WNYC" to which it responds, after a few seconds, I will now play you a mix of your favorite songs From Amazon Music." So first thing in the morning I have to tell this stranger in my freaking kitchen no I meant WNYC, which it then turns me over to. I learned on FB that if you tell it to go away it will, after a short discussion about how much you will be missing. Yeah sure, go away, goodbye, please no more of this.
If Bernie Sanders or AOC knew what we were doing here they would be turning somersaults. The tech right now is too esoteric. When they can join a community that works like this does, with full text, and the ability to communicate from one pod to another. Pod actually is a good name for what I have in mind, that and karass.
I set up demo.rss.chat yesterday so people can try out the software. No guarantee that this is going to run for any period of time, so don't post things there that you want to be around for a long time.
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. ;-)
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.
Finally, my first rss.chat podcast. 20 minutes. As always, I take forever to get to the point.
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. :-)
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.
Jeremy Herve who I know from projects at Automattic, has questions about rss.chat, and I have some answers, with more coming soon.
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.
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. 😄
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."
Sometimes Claude's judgement sucks, and that's why Jive coding usually produces a dashboard app. A different piece of software will drive it in a different direction. That's what I meant by AI-izing, in an earlier post.
I used to be a single-thread developer, but now I'm multi-tasking, I can work on two things at once. Claude is now able to research and fix certain problems, and his work is in a sandbox where it doesn't have any access to the surroundings, and can't make too big a mess, and it's going great, if there's a mistake it can quickly be corrected.
I think AI is the perfect innovation as we reach the crash point of the climate crisis. Who cares if we burn more CO2 now, the effect is miniscule for the explosive crisis that could be coming any day or week. One that we have no ability to recover from. To say it's unenvironmental would be like complaining that you want more Pepsi from the flight attendant while the plane is crashing into a small city. Anyway, but maybe after the crash, one data center will survive, and maybe the beauty that our civilization created will be sustained.
Inside the big AI companies they are certainly AI-izing every app conceivable, and even teaching the AI's how to AI'ize, because AI inside a standard productivity app which includes social network software will be one of the basic UI tools, and that means hidden technology like SQL databases can now be end user products, so the vision of the designers of SQL that they would make a database a manager could program, would finally be realized.
I'm an independent developer working in Claude Code, we're in the endgame of a product cycle, where the core is working and it can be used for the thing it was designed to do (biggest consideration). This is the time when you need users banging on it and reporting problems. People who write good bug reports. The only time I really had that down was at Living Videotext, a small company, but big enough to have employees doing QA and tech support. They were really good testers, they had the right perspective and an incentive, = anything we caught before shipping wouldn't become a support problem once the product was out there in user land.
Fast forward to the 2020's where I have done three products and am working on a fourth, and I have nothing close to the kind of testing support I had in the 80s. That made the work more difficult, slower and I took fewer detours, and one time, awfully -- a serious design error was caught only after it shipped and I was ready to move on to something else.
The point -- this handicap for individual programmers without staff QA people, we now have something even better than what we had in the 80s. Claude can do extensive testing of the product in the browser, "seeing" what the user would see. And it never gets tired. You just have to think to ask it to do it. It is so liberating.
And by far the best people to create and manage it would be experienced QA people. They should design and run the tests and sign off on the quality of the software, so we can be sure users are getting something great. And we can do great QA in places we never could really do it before because no matter how good users are, a person who does it for a living with experience can't be replaced.
One of the silver linings of AI use is that it makes you a better writer.
Today's song: "July is dressed up and playing her tune."