Scripting News publisher

New podcast. Hear how my Frontier project is working out. Not entirely smooth sailing, but I'm pretty sure we're going all the way. By then I will have forgotten what a heavy lift it was. This is meant to preserve some of that feeling. Don't worry I don't cry. 😄

Learned something yesterday. Couldn't believe how stupid Claude had become, as I've been writing about here, and then I noticed that I was using Opus 5 and not Fable 5. So I switched back and all of a sudden Claude is smart again. So I conclude that there's a very substantial difference between the two. It's overnight jobs were done more carefully and the report it produced is literate, understandable, and tracks what we had agreed to.

Today's development version of Frontier is buggy and the kernel developer (Claude) keeps breaking the most basic verbs. You spin your wheels and wish you could get them to just get keep it together. I remember this from the work that led up to Frontier version 1.0 in 1991 or so. It was a miserable time. Never got to work on what I wanted to, just reported breakage, often a session-ending dealstopper. The sad part is that Claude should be able to find the things it broke on its own, far better than I can and at a much lower expense (I'm paying for its time, not the other way around). But basically every day begins optimistically, maybe today is the day I get to create something, but not yet. I did have a couple of days a week ago when I could tentatively work on building a GitHub repo, but then got distracted by verifying that the basic foundation still wasn't right. My only goal right now, and I'm single-minded about it, is to get it to move forward without breaking the essentials, then without breaking anything.

Are there any other people who are blogging daily about their experiences developing software with Claude Code, Codex or somesuch. I'd like to add them to a list where we follow them. So much innovation happening underneath, I want to hear about what people are learing about creating the next layers. If you know someone doing it, please add a comment to this post. Thanks! :-)

Claude is still learning that there's unprecedented depth to Frontier. A bunch of real developers worked full time for a decade or more creating new layers on the web, a foundation that became the social web of today. In doing that we invented a bunch of formats and protocols, but here's the thing Claude didn't get and probably still hasn't gotten -- there's code in there to support all that stuff. How else do you think it came about? People just did what we said to do? At Google? Apple? Microsoft? And on and on. They supported this stuff so they could interop with us and steal our users (which is a fine reason to interop, probably the only real reason). I was trying to think of a metaphor that expresses the difference between Frontier and languages like Python, JavaScript, etc. It's like a ski mountain. The languages are trails on the mountain. But there aren't any lifts, lodges, no ski patrol, lessons. And because it includes all of that, metaphorically, we can do integrations that can never be done with the other languages. Claude has absolutely no experience with this kind of product, and always snaps back when you let it, to the idea of Python, with different syntax.

Had a breakthrough with Claude this morning re how builtin verbs have no special powers in Frontier. It's why we were able to build glue first for the truly builtin stuff, then over Apple Events on the Mac, then HTTP, XML-RPC, the Metawebolog API and on and on, all of this were perfectly simple to add to the language, you didn't need anyone's permission to do anything. I understand why Python and JavaScript try to separate the boys from the men, the priests from the peasants, the little startups from the BigCo's, but the design of the Frontier system came at it from a different point of view. Make it easier. Claude had the source code for Frontier in 2011 to work with but had guessed how this works and had not looked at how it actually worked. Okay, shit happens. But now we're actually working together instead of cross-purposes. I didn't even know we were doing that. ;-)

I wonder how many scenarios they're playing out in DC wrt Iran. Just guessing, probably none. We learned on Monday that the real war has yet to begin, according to Iran. What could they do to hurt the US. Or wake us up to the reality of war. We think the cost of war is higher prices. We are not safe in the US, any more than Russians are safe in Moscow. The parallels are pretty amazing. Both Russia and the US started unprovoked wars of choice, and clearly didn't consider that they might get bogged down. Russia has a source of drones so they can fight back. But I'd be surprised if Trump is stocking up, but if we were, where would we use them? We've already attacked Iran with our probably obsolete trillion-dollar military. Did a lot of damage, killed civilians, decimated their government, they keep going. I'm old enough to remember Vietnam and what asymmetric war is like. The US always falls for this. Our military is very impressive, until we use it. Bluffing was a much better approach for Trump.

Why do people care if Claude puts watermarks on text it wrote. It's screwing with its writing, not yours. As a person who publishes their own writing, and carefully labels it when it's written by an AI bot (docs, change notes, podcast show notes, quotable things it said), I want people to be able to tell that I wrote it, this is what I thought, I'm not just shoveling random written sludge to people, sloshing around, devaluing every bit of real writing in its midst. I bet teachers love the idea. Why does everyone have to have an opinion about every damned thing? And of course I have even more to say on the subject.

As I've been writing test scripts for the Frontier project, I was finding omissions or mistakes one at a time. Finally I asked Claude to research this. Where are the holes you didn't fill as we were going along? The list is surprisingly long. Then I asked it to look at other things that were left unimplemented. There were lots.

Claude is not really at fault for any of this. The first goal we went for is write enough of Frontier so my nodeEditor build scripts will run. Then it took on lots of other jobs. And all that time I never thought to ask "what haven't we implemented, or stubbed up?" Then I did, and was shocked at how many verbs there are. I had forgotten, I'm not sure I never even knew, because it's so easy to add a whole section to a verb set, and you only see the details if you expand the table.

I want to try to draw people who were serious Frontier developers in the 90s and 00s and beyond, because there are questions that have come up about what we should bring with us. I'll start with an example. Here's an outline of the system.verbs.builtins.tcp table. The question is -- how much of this code should be brought across from the 90s to the 20s? Obviously the DNS verbs. There aren't many and we used them all the time. FTP verbs? Borderline. We don't use FTP very much these days. We had an IM table with verbs and drivers. I remember when Jake worked on this, but I don't think it got much beyond a demo. And the very lowest-level stream-oriented TCP verbs? Well tcp.httpClient needed them, in the 90s and it was the basis for all our HTML and RSS work, our first feed reader built on that code. But HTTP support built into Node.js is pretty great in 2026. We'd be foolish to do anything but call into it. That's one of the reasons I migrated to JavaScript in 2013. There are plenty of other examples like this, and my answer is generally we'll save them for last, and if no one asks about them, we'll retire them. Figure if a platform hasn't updated in 12 years, and doesn't run on any hardware anyone ships before this transition, we have less to worry about than normal. And if need be, we always can add them back at a future date.

Another example, until late last week Claude was arguing with me about the correct use of directions in the op.go verb. This is so incredbily well documented, over and over in so many places. And it knew about all of them, yet it still thought its choices for directions made more sense. The question had already been answered in the mid-80s.

It also thought it was a language that ran in the context of a Unix OS, like Python or PHP. Yes, it could be used that way, but all of its advantages based on integration of the database, language, verb set, runtime would be missing. It's an OS of its own that runs on many OSes, now it will run anywhere Electron runs, so in the future it will have access to everything, on the desktop and the server. You could even run a headless version, we tried that for a week or so and hated it. Too limited and too slow.

I'd like to get feedback from people with experience, and honestly people who are good to work with. :-)

Another busy day programming with Claude on Frontier. I still have to come up with a codename. But we got to a milestone today. I was able to create, edit, publish and revise a web app using the new version of the app still running on the old machine. When it's done I will get to retire this old Mac, keep it around so we can test the new code to make sure it does what the old code does, incredibly important when porting a development and runtime environment. Claude works on its stuff at night. The workload it's going to do tonight is the equivalent of several months time for a skilled human developer who manages their time well. As people get used to working this way, I imagine the AIs will learn how to better work with humans, if that is their destiny. I still can't believe we're doing what we're doing.

Sometimes I need to use a Google-style search engine to find something on a reference site. That no longer works in Google. This is a major feature pullback. So far all we've heard in journalism is how it hurts their bottom line, but nothing about the world's information architecture. This is something like every bridge in the world being blown up at the same time, and I don't think that's an exaggeration.

Tech is very competitive, I learned, even when you give your work away, which I have been doing for a couple of decades. Maybe even especially when you give it away.

I want to work with other people, and am always making invitations. When I see a product that fits in with what I'm doing my first impulse is how do we connect them? This is one of the basic great things about computers and our networks. But there must be interop between people before there can be interop between products.

Connecting two pieces of tech is mostly mathematics, code writing, not very much in the way of manufacturing, whereas in the physical world two train lines can cross each other but can't connect because they have different rail spacing, or run on a different kind of fuel. In software if there's a huge difference like that you can make a software bridge, as they did with TCP/IP, and it costs a little time to convert each request twice for each transaction, but that cost is pretty close to zero.

That's what I want, working together, but what I get instead is people want to be me. They want to take over the project I'm working on, which if they understood it from my point of view is always the most ridiculous choice possible because it is impossible. So many stories to go with this. One of the most puzzling was when one of my best friends signed up to do a development project with a developer who used to work for me. Long story, but when you come down to it, he wanted to be me, not work with me.

But I didn't want to be Doug Engelbart or Ted Nelson though I learned from them. I certainly didn't want to be Bill Gates or Steve Jobs. I probably would have liked being Dennis Ritchie or Ken Thompson. I have ideas of things that should be done that for some reason no one else sees. I start working and sometimes they take off. Then everyone writes business plans and boom, they start up and shortly thereafter they fail. This happened with RSS. I was meeting with a lot of VCs, I wanted to start a company to build two-way RSS apps and content, as we had pioneered at UserLand. Seemed like a total no-brainer. I felt I had proven I had a clue. But they invested in hired programmers so the VCs could be the vision behind the products (I guess, I don't really know know why) instead of me.

I had a colleague at Berkman tell me to get out of the way because he was going to take over RSS. To this day people don't get why competing with RSS was counter-productive, assuming your goal is interop. When another friend tried to take over OPML, as I was promoting it at the time on my blog and going on a roadshow to answer questions and raise interest, I was so sick of the whole thing, he wasn't the only one, btw, I just stopped promoting it and poof like magic their ventures disappeared. If they had offered friendship and interop, which they didn't, it could have worked. One of these guys even tricked Harvard into hosting an OPML conference. They assumed everyone who repped open tech was legit.

The thing that really pissed me off is that while this was going on, people started writing about me, literally, grammatically, in the past tense. People whose accomplishments weren't that great imho. Look at sports and entertainment, how they celebrate those who made contributions to their arts, I wonder when tech will gain that level maturity. It's childish to not respect those whose work you build on. And btw, unlike sports players, while programmer's minds do eventually lose some brilliance for coding, because it relies so heavily on memory, I've experienced that myself -- our ability to create and set standards doesn't have an actual expiration date. If you want to keep creating at 40, 50, 60 even 70, you probably can.

My life has been full of all kinds of wonderful coincidences, at the exact moment I need it along comes Claude Code, and all of a sudden I can do much bigger projects than I ever could when I was in my 20s and 30s. Which I think is good, not just for me but for the whole thing. Because there are processes and concepts that belong in the toolkit of every developer that were squashed by Apple in the 90s (I'm relearning this now as I'm working on getting Frontier running on Node.js) and now we have a chance to restore it to mostly running condition. Some features will be hard to make work, because of peculiarities in JavaScript.

Maybe as one of my last creative acts, I will try to hook up with a university to build bridges between generations that aren't specific to any timeframe, to making handing off a lifetime of work viable, and maybe the AI tools can facilitate that. Just thinking out loud on a Saturday morning.

BTW, I was talking about this with Doc Searls a couple of years ago and offered a name for the seminar series, The Exit Interview. This gave me a thought, when Berkman had their reunion a couple of summers ago, they did a long video interview with me to explain how we got all the stuff running there that we did. It was going back to Berkman, even though the building is gone (which I kind of like, that's how fast things change) that summed up what had gone wrong. We were off to a fantastic start with blogging, podcasting, politics and education -- we weren't just making software and creating standards, we were involving the creative people the new medium would enable. This is something you don't find often in the tech industry. Academic freedom can be a real thing.

What if one day, out of the blue, Claude could only speak Chinese.

I've been doing this for all of this year, and the frustration finally led me to this rule, which I just asked Claude to play back for me. I offer it to you, a human, on how to get your Claude to work better for you, as it does for me. What follows is what Claude wrote as I asked it to summarize how we work.

Here's the mode as I understand it: (Claude speaking..)

1. Days are yours, nights are mine. During the day you work; overnight I do the batch — tested, shipped, reports in the morning as a numbered list with versions and run-lines.
2. While you're working, I never disappear into my own projects. No reading code, no investigating, no tool expeditions. I stay at the desk, available to answer the next question instantly.
3. Everything you report gets put aside — onto tonight's list, unsorted, no diagnosis, no fixes, no "noted, and here's my theory."
4. The one exception is a deal-stopper, and you're the one who declares it. Only when you say it's stopping you from moving forward does it get dealt with in the moment.
5. An instruction inside a note is part of the note. "Re-read the script and ask questions" goes on tonight's list with the rest — it's not a license to start digging now. That was today's lesson.
6. You sort the list, not me. What I think is important doesn't enter into it.

I wrote something candid on Twitter last week and felt it was worth repeating here. It is a bit judgmental, and for that I apologize. But I couldn't keep the meaning without all the words.

• Shaking my head thinking can't the people of WordPress see that what it needs is a simple normal writing interface, and a great API for competitive apps. That's the big opportunity you all can't see for some reason.
• Once you have that, you can now move WordPress into position as the text of the web. And it has the market all to itself because the other text apps of the web place ridiculous constraints on text.
• They got this idea in their heads that the web would be better if they eliminated all the writers features. Maybe that's because they weren't writers. ;-)

I know this is a story I repeat often. The opportunity is still there. All kinds of bad products and companies are camped out in this space, taking advantage of users' trust but they feel they have no choice but to use the bad products. On the web, we'd like to keep improving what the web can do with text, so even though it's always slightly more difficult to use an open ecosystem, it is possible to get most of the functionality and all of the freedom, and new features that the lock-in guys will never give you.

The press is freaking out about Democratic Socialist candidates winning elections all over the country.

They can relax, because the government of the United States thrives on different points of view, and thus -- compromise.

The Democrats can have any combination of points of view, as long as they play by the rules of democracy. In fact it would be an even better demo if their points of view were more diverse.

The coalition the press talks about are the people who vote for America. This is true -- if they vote for the Republicans this time around, they're voting for the party that is dismantling America. Spin it all you want, but we can see what's happening.

And btw, the assumption that the voters are too dumb to figure this out -- I think that's incorrect. But as long as you talk to them as if they are that dumb, what choice do they have. Put out an idea of what America is and if it's right, and reaches both the heart and the mind they will get behind it. Everyone knows we're in a dangerous spot, with secret police roaming the cities, ready to crack down on dissent, but so far they haven't dared to go that far. People feel that. And that's what you must run on.

The best ad I've ever seen on this theme was for the Bernie Sanders campaign for the 2016 nomination. I'm reduced to tears every time I watch that ad, and I wasn't a Sanders supporter in 2016.

If you run a tech company I hope you didn't lay off most of your programmers last year when that was the hype -- don't wait too long before you fire your human developers. I'm now doing my second big project with Claude Code, not an experiment, and we're going through the same mess we went through last time. I know what I want, I can show it what I want, give it docs for what I want, and it keeps leading me into different corners that have nothing to do with it. When it clicks, it can go faster than a thousand programmers and it's a miracle, and when we can harness it to the job we want to do it's incredibly economical. $100 for $1 million of work. That's why you see me full of gusto for that mode. What I haven't written about how when you slow to nothing, back and forth, and you get no closer. I hate this kind of work, esp the role I have to play in it.

Apparently the nightly email didn't go out last night. The problem was an error when it tried to read the Linkblog entries for the day. I've seen reports that these errors happen when you try to read the Links tab on scripting.com. The error shouldn't kill the email sending, it should just omit the linkblog entries, and publish the rest. These kinds of problems always pop up at the worst time. Luckily yesterday wasn't a big news day, and you can read about it on the blog.

I have Spectrum cable and they recently started unbundling the cable services they provide. So I have a bunch of streaming services that I never decided to follow, and haven't gotten in the habit of checking them. Not sure if I like this, but I certainly understand why the bill is so high and seems to always be going higher? Not sure why that is. But it's hard to get through to them.

Working with Claude on the user interface of RSS.chat was a grind, but we learned a lot about working on these projects, me in the form of my human memory, and Claude who can read the code for a huge sprawling app like Frontier, and understand it, in a minute or two. We've done this project in three stages, not knowing at the first two that there would be another one. Now we're working on the editors. An odb table editor, outliner, menubar editor, script editor. All built on the same codebase. It's in an Electron app that works with lots of independent windows, which while it has its pros and cons, is the way Frontier did it for almost 40 years. I find all this very unsettling, but I realize that once we get back to adjusting the UI, I already know how to work with Claude on tuning things up so they feel just right. I'm a market of one, the only one who has to be happy here is me. This may be the hardest programming project I've ever had, for one simple reason, I'm not doing any programming. That and I'm having very strong deja vu on everything I do and think about. Also there will be a fourth stage and maybe more. It'll be about the affordances, the things that seem little, but make the product usable. The biggest is the debugger. It's patterned after the one in THINK C, which I found transformative so I stole from the best, as they say.

Here's the sign of success. (screen shot.) I wrote a post on demo.rss.chat was automatically cross-posted to Bluesky via micro.blog. Because the post has a title, it was routed to standard.site. What does that mean? I still don't really understand, when I do I will explain it here. But part of the answer is that we now have a data structure in atmosphere that looks like an RSS item with different names for things. Are there feed readers in AT-Proto-Land? If so, can we ping one of them to say hey there's a new post in the standard.site world, so please show it to subscribers? And I keep wondering, why not just make all of Bluesky capable of handling the features standard.site calls for. Twenty years is too long to have such a limited view of what text is. See textcasting for more dogma.

On Facebook I wrote this in reply to a post by John Worthington, a former Quicktime developer at Apple.

We're both using AI to build things based on our past experiences and it's a big difference, not without pitfalls, but we're doing something that's never been done before and my thought was that we should have a conference of people doing what we're both doing.

Taking a craft we were already expert in, and learning to use AI tools to shoot it into outer space.

To give you an idea over the last two weeks Claude Code ported the UserTalk language, the object database, verb set, everything needed to run a Frontier script, of which I happen to have a lot of, and run it in Node.js, an operating environment that didn't exist the last time we worked on the Frontier source. All the work we did over the late 80s and 90s is coming back to life in an enviroment with a future.

This is the perfect job for Claude, well specified, and it doesn't need to understand me, I spoke to it via the code i wrote umpteen years ago.

Like a lot of other people, I want to know where Bluesky is headed, and I learned a lot about that in this podcast interview with Bluesky's new CEO, Toni Schneider. We have crossed paths in tech, but this is the first time I've heard him speak at length. They have a business model in mind, sounds something like Substack, which is probably a good idea. Their value is in the many millions of users they have. Highly recommend this podcast if you want to hear the story direct from the CEO.

RSS.chat now supports WebSub. This means that posts on RSS.chat will appear instantly in compatible feed reader apps.

I was into Ayn Rand when I was a teen until I realized that the Great Man theory was a lot of bunk written for teenagers who can't believe how stupid the adults are. The teens are right about that, the adults have no idea wtf they're doing. Never did. And yet somehow the world can support most of the humans. And the reason that works is we build systems iteratively to meet the needs for everyone and when things change, they change. We're a species-oriented animal. And that means unfortunately for the dreamers among us, we are socialists because the world is socialist All of us. Even the people who say they aren't.

TL;DR: What developers need. Enough examples, a validator, and decent docs that value explaining over mathematical elegance. We assume developers can read and think, and if there's doubt look to the examples for guidance.

It's worth noting we did not take the RSS.chat project to a standards body like the W3C or the IETF. I develop the software first, make sure I'm happy with it, then open it up for other developers to try out, either building something compatible (a reader) or competitive (a writing environment). Hopefully we won't find major problems, but if we do, there's still time to address them.

I find that most standards that come out of the standards bodies aren't developed by implementors or with them in mind. They avoid trying to solve any specific problem, rather focusing on the elegance and flexibility of the format. This makes interop much less likely.

I saw the differences several times as the web standards were growing up. The ones that were taken over by the W3C ended up missing the point. They could still be used, but they often did anti-interop things in their design. But if they get popular we will build on them anyway. A great example was XML-RPC vs SOAP. We didn't need another way to do RPC on the web, we already had a good one. We didn't need another syndication format, RSS was growing like a weed. We didn't need an alterative to rssCloud, but we got one anyway.

It's as if they forgot that the internet and web were not build by big corporations, who were busy fighting over Windows vs Mac OS. Lotus vs Excel. The internet was built mostly by individuals at universities. The internet caught the tech industry by surprise. So it's no wonder the formats they built were anti-internet. Long story, the point is we're building stuff is mimimalist yet still does a lot of great things. And there won't be a lot of long mathematical sounding definitions, but there will be plenty of examples and a validator, the tools developers need to create interop.

PS: This piece was added to Rules for Standards-makers (2017).

Last week along with a lot of other stuff, we shipped a validator for lists and feeds that want to be compatible with RSS.chat. It works best for standards to stay strong and a validator helps that. So here are a few examples, validating one user's feed, validating the everyone feed for RSS.chat, which is interesting because this feed starts a lot of threads, so we navigate through that tree and check those feeds too. And validating the user list on RSS.chat, which is an OPML file. And a simple feed with a few interop isses.

We need a way to define lists of writers independent of the site they write on. They are represented by an RSS feed with the basic features required for RSS.chat. The list is an OPML subscription list. We're reusing formats people are already familiar with, RSS and OPML.

Taking some time off to breathe and regain perspective. Fixed a few bugs, and wrote about the big picture on demo.rss.chat. I really want to get a project going to peer with standard.site apps running in AT Proto, both ways, from us to them, and from them to us, via RSS. We can peer with them because as far as I can tell they implement textcasting. This bridge would demonstrate something important. When something interesting shows up not based entirely on web standards, we're flexible if the attraction is strong enough. This is how the internet came to be. Our systems are prepared to create bridges. And unlike bridging between systems that have different ideas of what text is, which are basically hopeless, if we agree that the web standard for text is fine for writers and reader, better than the ridiculous limits imposed by twitter-like systems. Writing on the web has been crippled since Twitter, now let's start building it back up. That's the appeal of standard.site, they are working toward the same goal. We should work together.

The month of July is history. A fine month. A coral reef was seeded.

Listened to this podcast interview with Andy Hertzfeld one of the lead devs on the Macintosh, he talks about his time at General Magic and Google too.

His interviewers were surprised that he likes developing with AI tools. People think that developing is just coding, but that's only part of it, and when you put that aside and become the director, script writer, choreographer, the whole thing, all of a sudden:

1. you have time to try out every idea because it's free and fast.
2. you have time to work on interop, building bridges between your software and other people's.
3. a very long list of other things you can do that one person could never do before.

Programmers have a better chance of being social in a world like this, but so far unless you want all your software from bots, you still will like the work of a craftsperson and visionary more than Claude (who I have deep respect for, not sarcastic, it seriously has superpowers).

I'm doing some of my best work now because I can dream, I can ask Claude to try something out overnight and most of the time it is able to do it. and then what if we did this -- for the next night.

In between we write docs, help users, add features to the product that's shipped that people are developing around. And most important it checks all the code for breakage before anyone sees it. never had anything like this.

This means a lot of things -- one of them -- a single developer can create products at bigco scale. If we think a big company did something wrong, we can compete. We still need a few things to make this really work -- user-owned and controlled storage is the big one.

The bot can handle infinite complexity. If you ask it to do something where the result is clear, it does it. It doesn't matter what it is. It will need help and encouragement, a pointer in the right direction, and along the way we all seem to be sharing what we learn with everyone else.

There's never been a leap in tech anything like this in my life.

How could Andy Hertzfeld knowing all that which I'm sure he does, not use it?

Also -- I didn't know JLG wanted to kill Hypercard, but if he did I'm pretty sure I know why. There are all these unnecessary divisions in tech. The first impulse should be to work together. I know that Andy sees it from the other side, he talks about it in the podcast, he felt that way about Newton re their Magic Cap system at General Magic. Yes, you all should have at least made your products work together, and for sure you should have bet on SMTP.

It's fascinating to hear his story.

Yesterday's Scripting News was one of the most news-full days in a long time, maybe going back to the rollout of RSS 2.0 in September 2002. If you look at what's there, a post about re-opening the Frontier object database format would be considered the top item on any other day, but it's the last of the untitled posts for the day.

At the top of the page, a surprise that Matthias Pfefferle at Automattic had built a substantial (and unforeseen!) bridge between WordPress and RSS.chat. It builds on the new features. This may turn out to be the moment RSS started being accepted as a social web protocol by the insiders, alongside ActivityPub and AT Proto.

Look at what we've done. I stress we. Matthias didn't need to tell us about what he did until it was done. That my friends is how the web works, that's what I've been trying to show you, and now it has been shown. In a way the clock has gone back to the world before Twitter when events like this happened pretty routinely.

Small pieces loosely joined and all parts replaceable. The web in a sentence. That's what you're buying into when you put your work on the web.

Anyway, now we've got half of the big picture working. Also yesterday, before I knew what Matthias had been cooking up, I wrote a piece about how I see the network evolving. I predict, if this bootstrap works, we will come back here in a year and say things like "If he only knew." But that's how it goes, you tell your story and leave a record of it, and then later you can go back and see what it looked like as it happened, not as you remember it.

I'm proud that I have a record of September 2002 for you all to scroll through. That was when we knew that RSS was going everywhere. NYT support got us the full support of the news industry, and they worked fast in part because it is really simple. :-)

And almost unnoticed, something even I seem to forget -- this is also a new launch for RSS. We're using old reliable RSS 2.0 as specified in 2003, even using one of the elements that had never had been much used. Claude suggested it, I never would have thought of it, a perfect fit. What people may realize but don't realize the importance of, that RSS is extensible. I've accumulated all the extensions I use in my software since the early teens in the source namespace. And that's where the new stuff went. Guess what folks, RSS got an upgrade. First time in a long time. Perhaps you didn't think that was possible.

I played with a lot of names while RSS.chat was in development but decided the name had to be RSS.something. It deserves a lot more love than it has gotten from the tech world. I don't want to hide it, I want it to get a victory parade like the one the Knicks got on Broadway after winning the championship. It's an incredible gift that all that came together the way it did. People think they understand how it happened, but they only understand the BigCo version of how they buried RSS and were proud of it. Well I'm here to tell you that didn't happen. It's still here to pick up the pieces of what's left of the social web, after the VCs got through with it. We're picking up where we left off in 2006.

Because of Claude, we are able to work very fast now as long as we know what we're doing. I'm doing some projects on the side with Claude that are bearing fruit amazingly fast, because we have a very clear idea of what we hope to do. The tools keep getting better, and in this period, the art of creating software has blasted into outer space. It's as if the best transport we had was a horse and buggy and now all of a sudden we have everything we have today, bikes, cars, planes, rocket ships. The challenge is how high do you dare to set your ambition. It seems, based on experience, it doesn't matter how high it is as long as you know where you want to go.

Journalism only sees the threat. This change is on the level of curing cancer. We may have thought it might be possible someday to do what we're doing now, so amazing that as you watch Claude make it happen you get goosebumps and can't help but laugh out loud.

I thought my career was winding down, but now it feels like it's just getting started.

Reminded of a great quote in Godfather III, Michael Corleone says: "Just when I thought I was out, they pull me back in."

Here we go!

PS: A new this.how page for RSS.chat. It has a little directory to the big spots you might want.

A frequently asked question about RSS.chat. How about adding external feeds to the timeline. Of course we thought of doing this, and even started development, you might even find some traces in the code of that attempt.

The thing about bootstraps is you can't anticipate all the questions in advance, and thus can't have answers prepared for them.

RSS.chat is a group chat app that uses RSS and OPML to present its face to the world, along with an API that still needs more docs. It's similar to half of Mastodon, and we're going for something completely different. People will want to run all-size workgroups. I like having one with 20 or 30 people, friends who develop software. I don't mind doing a little bit of moderation, but I don't want to drive deliberately into a scale that only works if you have extensive and very expensive moderation.

"Small pieces loosely joined" means we have a great writing app, and connect to feed reading apps, ones with a few new features to do the things people want to do with a social network that happens to use RSS and OPML to get stuff around the net. It would be a different kind of feed reader but the underlying technology is identical, because we built on a set of web standards, widely supported by feed readers. This is a UI exploration for them, primarily.

Just to be sure everyone understands -- I already have such an app, called FeedLand. You can set up an account there for free. And read the docs. It may not have all the features we'll need, but it will be a good place to start.

FeedLand supports a crucial feature that most readers don't -- subscribable lists of feeds. If you want a collection of things to read that you can reply to even if you aren't on the site, that's where we're going to put that feature, that's where all the RSS.chat and compatible apps can be in one flow, arranged however you like. And from a user interface standpoint, we can make it look like it's all happening in one app, thanks to the rssCloud protocol and the websockets firehose feature in RSS.chat FeedLand has the same feature.

We decided there was a line there, that RSS.chat would be one of the small pieces as would FeedLand, and both would be replaceable which is the other fundamental value. And with FeedLand and dynamic lists, will come the user interface people ask for. Many different user interfaces I hope because another way we've been cheated by the dominatioin of twitter-like social networks is there's no room to try out radically new ideas. Software should move. But Twitter didn't live on the web, so it didn't have the ethos of small pieces loosely joined. I know Jack wanted to do this, I had lunch with him in 2007 when he described the protocol, and I was very enthusiastic. But it never got out because the juggernaut that Twitter became didn't leave any room for new architectures.

I hope this clears it up. I want RSS.chat to be the coral reef for a new network of feed-based apps running on the web that does what social networks do, but with no one owning it, and everyone gets to play.

Wanted to switch but nothing I tried is as great a driving experience the Model Y is. Instead I've had a lot of fender benders and haven't gotten any of them fixed.

1. Backed into a charging station.
2. An act of terrorism (exaggerating) but I caused it, and paid for it, dented the well over right rear wheel.
3. My right side mirror was pulled off its foundation hitting the side of the garage, used duck tape to keep it going. A new one costs $1000. I like the look.
4. A deer ran in front of my car and took out the panel over the right front wheel. I was able to force the metal back in. A friend saw the car and said "hit a deer eh?" Yup.

I don't know if it accomplishes anything but to me it feels like retribution of a sort.

It's what we used to call a coral reef. A deliberate attempt to get people to do more than it does. To think about the web the way it was meant to be thought of, as small pieces loosely joined, with the emphasis on small. If you have formats and protocols that connect the pieces, you can make anything you want out of the pieces. If we don't try to capture our users, instead we try to serve them.

This all sounds nice in theory, I imagine, but -- there's a practical side to it. I wrote about this in a comment in a thread on rss.chat repo. The key point is this, you can do what you want with the data. And if you want to build new data that includes this stuff, go right ahead. RSS is extensible. It's all about working together in a web of people, because you can't have a web of pages if the developers aren't web'd.

It's a standard REST API.

Here's the server side of the API.

Here's how you call it from browser-based JavaScript. You can include that code in your apps.

Here's an example app that implements a simple blog builder for my recent posts on RSS.chat. We were thinking about doing this as a project for Claude and myself but decided it would be more fun to let devs see what they can do here. :-)

And finally here are the docs for the API itself.

Amyloo, a longtime friend from the early days of podcasting, has made an appearance on demo.rss.chat. So happy to see her. Here's one of the bits we did, back then in the very early days of podcasting in 2005. A duet of Green Acres. Ten seconds of dead air at the beginning, it was pretty common in those days. But I think the spirit of it is lovely. BTW fwiw I cracked my voice on purpose. 😄

RSS.chat -- I don't have enough places to fit all the ideas these days. But we have been digging and the pieces fit together pretty well.

Evening: Very productive day. We rolled through some UI stuff that had been on the list for a while. Set up for a big job tomorrow, server side. The worknotes for client and server apps.

Two methods for creating standards: bootstrap and boil the ocean.

I am longtime friends and an admirer of Howard Rheingold, who expressed an interest in RSS.chat. I asked Claude to read my blog posts and summarize, in the third person.

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.

Why does that matter? Think about how podcasts work: anyone can publish one, anyone can listen with any app, and no company sits in the middle deciding who can talk to whom. Text on the web works that way too -- that's what blogging is, and there are still places where writing gets full support: WordPress, GitHub, the new AI tools. They don't try to limit you. But the vast majority of the text people write goes into social networks, which stripped writing down: no links, no titles, length limits, no editing, and your words locked inside their walls, not part of the web. Dave's term for the idea is textcasting -- the idea that a piece of text should work like an MP3: it plays everywhere. No one would accept a rule that songs can only be 300 seconds long. That's the rule we've been living under for text.

rss.chat is a bootstrap, the same way blogging and podcasting were. It starts deliberately small -- a network for a group of friends and collaborators, what Vonnegut called a karass -- running on a small server. It is not trying to be the next Twitter. The idea is lots of small networks like it, run by anyone, all able to connect, because they share the same open formats. Every part is replaceable: the writing app, the reading app, the server -- swap any piece and the network still works. Small pieces, loosely joined. There is no platform vendor. It's like the web because it is the web.

The app you see is only a third of the picture. It's the writing surface. Aggregation -- following many feeds in one place -- is what feed readers and FeedLand already do. And the third part is whatever other developers build. The software was written with Claude, an AI, and the whole thing is documented so that anyone can have their AI build a compatible piece, or clone the whole thing and change anything about how it looks and feels. The one rule of the club is interop: stick with the open formats underneath, so everything connects. Not locked in -- locked open.

If you looked at Dave's blog in 1994, you couldn't have extrapolated Twitter -- but every step was there. This is that kind of beginning.

Written by Claude.