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.

Now it's easy to find an author's feed on rss.chat.

Click the feed icon to see the feed on rss.chat. You can then give this URL to any feed reader.

Now each post is visibly connected to the author's feed.

This is how we're building out. Our job is to make it easy to write feeds for groups of users as small as one and as big as you can imagine. And be open about it so we get lots of competition that interops with us and everything we interop with. This is the step that makes it the web.

We will keep beating the drum, showing users of today's readers how they can hook in, right now, nothing to wait for. And as time goes by, if it works, the reader developers will be interested in how they can use the extra features.

This is how I think every social network work, start moving out of their silo, with determination. By offering this option, we put the idea out there that there can be a single social network on the web. We can work together make it happen. The social web of the web. ;-)

Please come along on this journey.

There's going to be lots of new tech coming online.

I want everyone to be a part of it.

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.

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.

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?

• Every user has an RSS feed with all their posts.
• The whole community has an RSS feed.
• There is an OPML file that lists all the users.

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.

• The source namespace docs, to read about a couple of new elements, source:inReplyTo and source:comments.
• A full page of docs on RSS as a social network, explains how the pieces fit together.
• A GitHub thread where you can ask questions.

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

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.