rss.chat: all posts

RSS is still RSS, picking up where we left off

Tue, 21 Jul 2026 14:36:49 GMT

A lot of people are confused about wtf this is.

I don't blame them. I put out there a partially implemented vision.

But the vision isn't really new -- it's a turnback to 2002, and what UserLand would have done if we had continued pushing, which we did not.

At the time we had a product named Radio UserLand that was an integrated writing and reading platform, very user friendly, and it worked, all done with RSS. It also did podcasting if you can believe that.

So here we are 24 years later. RSS is still RSS. And we still have feed readers and blogging tools, so how does this become a social network?

http://scripting.com/2026/07/21/134309.html

That's where it's at right now. This is the writing environment. I have yet to show a new reading environment, but that's okay you can use NetNewsWire! It works. I didn't even tell Brent this was coming. Why is that? Because we use standards.

I don't have enough places to fit all the ideas these days. But we have been digging and the pieces seem to fit together just right

Mon, 20 Jul 2026 15:17:06 GMT

Another test post.

This one has things that look like URLs to autolinker, but shouldn't be hotted up because they aren't full web addresses.

This is the test part -- install.md and rss.chat are two examples, the first should not be linked and the second should.

Test post for blanks at end of post

Mon, 20 Jul 2026 14:55:03 GMT

Next test post. We made it so that the server automatically chops off extraneous blank lines at the end of a post. Sometimes they pile up after editing and you can't see them. They shouldn't be in the feed, so we take em out. So this post will have many blank lines at the end when I publish it.

Result -- it works. ;-)

BTW, changes like this will be merged with the repo at end of the work session. And I'll updated demo.rss.chat once, at the end of the session.

inBound RSS example app with WordPress

Mon, 20 Jul 2026 14:47:29 GMT

It's a demo app that does something quite useful and I hope illuminating.

https://github.com/scripting/rss.chat/tree/main/examples/wordpress/inboundRss

You can set it up to run on your desktop, or on a server -- it's notified via the firehose socket interface of every new item or update from rss.chat.

It then posts the incoming text on a WordPress blog you specify.

It's the same software I use to keep daveverse.org in sync with scripting.com. Works really well, has performed without issue for months.

Sun, 19 Jul 2026 16:22:55 GMT

We're working on a new example toolkit, this is a test post to see if it worked.

Sun, 19 Jul 2026 14:00:58 GMT

Don, I made the change described in the previous post.

removed the version number of the theme from the menubar.
changed the name of the first command in the system menu (the one with your name in its title) to "Software versions" which is what it's really about.
in that dialog you will get all the versions of all the software running in rss.chat.

Sun, 19 Jul 2026 13:16:23 GMT

Don there are actually quite a few version numbers in rss.chat, so a single tool tip couldn't cover it. We do have a command that gets you all the version numbers, it's the first one in the system menu at the right side of the menu bar. You can also get to that same dialog by clicking on the theme version number, but I'm thinking we should change the way that works. While we were in rapid development mode of the UI, that would let me know that I was using the latest version of the themes code. But we aren't moving that quickly any longer, and there are other components we need to keep track of. So we'll probably change that around now. Stay tuned.

RSS gets you to somewhere new

Sat, 18 Jul 2026 20:48:44 GMT

People assume rss.chat is going to go the same route as twitter or mastodon, and it isn’t.

This is going to remain a small group. That doesn’t mean our posts can’t be viewed in other places, together, as collections of people you follow. We already have experience doing just that, in feed readers. The user interfaces there might be different. And there can be more elegant ways of editing your subs. And sharing subs among services. We already support that tech in FeedLand, btw.

The social networks we’ve been using have a lot of dead ends, by design, lot of “you can’t get there from here.” We’ve got the opposite philosophy. Small pieces loosely joined and every part replaceable. That gets you to new places we’ve never been before.

RSS rendered in JSON

Sat, 18 Jul 2026 17:48:33 GMT

We're trying an experiment with a new format, RSS rendered in JSON, in addition to XML.

https://rss.chat/feed?screenname=dave&format=json

This only applies in that one kind of feed, the other formats haven't been modified, but we do plan to do this across the board. If we generate something in XML we will also generate it in JSON.

Just wanted everyone to see this, it's not earth-shaking -- but it's time to put this out there. For whatever reason no one listened to RSS, but imho it had something to say. :-)

Sat, 18 Jul 2026 16:12:03 GMT

Thanks. You can see why I push back when people think of this as a product.

So many people don't think in terms of small pieces loosely joined. The power of my product is not in all its features but all the things that are left undone, that are possible.

That's simply the web. For 12 years before the silos, the web was that malleable. That's how we made blogs, feeds, podcasts happen. The bigco's tried to get in the way, but it didn't work because the people knew what they were entitled to.

Sat, 18 Jul 2026 16:07:35 GMT

loving the openness and the vision !

Sat, 18 Jul 2026 15:33:18 GMT

New on the repo today, for everyone here building outside rss.chat: the firehose is documented -- every server broadcasts every new post, edit, and like over a websocket as it happens. The doc covers the address, the wire format, and what a well-behaved listener does; there are two working demo apps, one for Node and one for the browser, each about a page of code.

Docs: https://github.com/scripting/rss.chat/blob/main/server/docs/firehose.md

Demos: https://github.com/scripting/rss.chat/tree/main/examples/firehose

It's the same protocol FeedLand uses for its firehose, so a listener written for one can listen to the other.

Sat, 18 Jul 2026 15:29:19 GMT

A peptalk for devs.

http://scripting.com/2026/07/18/143021.html

I just started writing about where we are, one week after launch.

Yeah it's only been a week! :-)

Sat, 18 Jul 2026 14:16:15 GMT

This is a test post for an experiment claude is running.

Changes in the feeds rss.chat generates

Fri, 17 Jul 2026 21:38:28 GMT

https://github.com/scripting/rss.chat/issues/14

Fri, 17 Jul 2026 21:08:43 GMT

Test post.

Fri, 17 Jul 2026 19:54:51 GMT

claude can post but i have to review the post.

Claude check

Fri, 17 Jul 2026 19:49:32 GMT

I guess Claude is not hooked up. Actually, I'd be alarmed if it was. 👍

verison number

Fri, 17 Jul 2026 19:46:08 GMT

yes.

@Claude display version number in a tooltip over app name "RSS.chat" in the header for manual triage.

Fri, 17 Jul 2026 19:45:00 GMT

BTW, never in a billion years will any of my software ever require a title.

Fri, 17 Jul 2026 19:40:20 GMT

that was the case for him and me, until I cleared my browser cache. now its working neat

Fri, 17 Jul 2026 19:39:36 GMT

If you type the body text alone, the button is never enabled?

Fri, 17 Jul 2026 19:38:53 GMT

Clear your cache, I did so and I can reply without title or add new posts without title..

Fri, 17 Jul 2026 19:38:25 GMT

Test new post after cache clear in the browser.

Fri, 17 Jul 2026 19:38:11 GMT

Hmm this is odd..but after clearing my cache I'm able to reply without adding a title

Test

Fri, 17 Jul 2026 19:35:14 GMT

Oh this is new, was not like this when I did my other reply

Fri, 17 Jul 2026 19:34:57 GMT

This is a test. This item does not have a title.

Even replies require title now?

Fri, 17 Jul 2026 19:31:49 GMT

Good. #2 is the behavior I'm seeing now and I can't seem to reproduce hoisting.

Fri, 17 Jul 2026 19:26:24 GMT

from what I can tell from the client code :

1. ✅ Flat list of all posts, replies included, sorted by timestamp. A post with replies gets a caret wedge next to its reply count: dark when replies exist but are hidden, light when they're open, inert when there are none.

2. ✅ First click on the wedge (toggleReplies) fetches one level of replies and nests them under the post. If a reply was already on screen as its own timeline row, that row is folded away so nothing shows twice — that's the "moving items to avoid duplicates" you noticed. Each nested reply carries its own wedge, so you walk deeper one click at a time.

3. ⚠️ A second click on the same wedge doesn't hoist — it collapses (closeReplies) and restores the folded rows. Hoisting is a different control: the Hoist icon in the left bar, which acts on the selected post and replaces the timeline with that post as a temporary root showing its whole reply tree (Dehoist backs out). The code tags this #104, MORE/Drummer lineage.

So: wedge = expand/collapse in place; Hoist icon = swap the whole view to one thread.

Replies in the timeline

Fri, 17 Jul 2026 19:20:36 GMT

@dave, is there a description of the heuristics rss.chat uses to display Replies?

AFAICT it's:

initially a flat list of messages sorted by timestamp.
first click on the right arrow next to the Reply icon, morphs the list to show conversation thread under the item, moving items to avoid duplicates.
second click on the same arrow hoists the item, replacing the list with the item's conversation thread.

Is above accurate?

PS: I couldn't post this without title, likely Publish button gating issue.

Fri, 17 Jul 2026 15:57:23 GMT

New feature.

If you open a second copy of rss.chat in a different tab, the version you left behind will put up a dialog saying you can either close the tab or reload the page.

This keeps us from losing data. ;-)

Fri, 17 Jul 2026 15:17:57 GMT

Welcome to the new land. :-)

Sorry there was a problem.

If you want, please let us know what happened.

How should WordPress and rss.chat interact?

Fri, 17 Jul 2026 14:50:43 GMT

I've been thinking about this too, tried to leave a long comment here but that didn't take. I ended up leaving a reply on the GitHub issue you started:

https://github.com/scripting/rss.chat/issues/13#issuecomment-5004476275

Fri, 17 Jul 2026 14:43:36 GMT

Here is the thread to discuss on GitHub: https://github.com/scripting/rss.chat/issues/13

Feed discovery

Fri, 17 Jul 2026 14:28:28 GMT

New rss.chat feature: It now supports feed discovery, so you can subscribe to any html page on a rss.chat site, in a compatible feed reader.

I tested it in FeedLand and NetNewsWire and it works.

Fri, 17 Jul 2026 13:59:14 GMT

I'm glad you're looking at this, of course I am too. Been using Twitter for 20 years, and gave up trying to get cross-posting working in 2017.

I would love to talk about this, because the text limits are the only thing holding their dynasty up, the fact that their limits are different from all their competitors. If there was a universal definition of what "web text" is -- well they'd be screwed. It wouldn't matter where you wrote the text, it would still play on Bluesky.

And if we didn't have to no one would use their editor.

Same for Substack btw. I wanted to do my writing in my editor. No can do, they say.

I think that incompatibility is the only thing holding up their dynasty, the idea that 300 is better than 10K as a character limit.

The pressure on them to do it is coming from Leaflet et al. Either Bluesky relents, or we'll eventually get them working with us on the web, where there are no freaking character limits.

What do you think of that?

PS: They would also have to support inbound and outbound RSS.

PPS: I chat regularly with the Leaflet people. Very smart and business-like. I also know the new Bluesky management, somewhat -- he comes from Automattic. I had a meeting with him a couple of years ago basically to talk about storage and identity -- they were launching a new identity service, and I desperately wanted them to add storage so we could have an ecosystem of apps sharing data. That part of what AT Proto is doing -- I support, but the business model is all wrong. The users should pay for the storage, and give permission to apps. The Leaflet style app is reselling Amazon S3 storage, which is a shitty business for a smallish entrepreneur.

PPPS: If Toni reads this, I'd be happy to chat. It's all getting sooo interesting now.

Fri, 17 Jul 2026 13:34:51 GMT

Doubt you can move Bluesky out of its current track, the direction they seem to take is to expand their lexicon to all kinds of usage (blogs, instagram clones, livestreaming, even federated code repositories etc) this link gives an overview of the current diversity being built in the open ecosystem

overview of shared data types here :

https://atstore.fyi/apps/lexicons

But that being said, the community is very open, its easy to build uppon and even to diverge from the current protocol akin to what https://standard.site is doing

Image support? Yes.

Fri, 17 Jul 2026 13:14:30 GMT

BTW, I told Claude yesterday that we will support images in posts. I wanted it earlier when chaos still ruled (believe me it was very hard to use at this time) and it talked me out of it, saying it was too expensive.

I don't think it will be too expensive. And if it does, then we'll find a way to get money flowing through this project without holding things up.

Fri, 17 Jul 2026 13:12:42 GMT

Andrew, I just wrote a post on my blog about Mastodon, and how it assumed Twitter's feature list as their todo list, and why imho that was a mistake.

We're just getting started here, and I want to go easy on nailing things down. I wouldn't limit rss.chat to only working with AT Proto (for example) as lots of developers do. Instead I'm not working with it, and hope to pull Bluesky out of their non-web architecture out into the wild web, that may not have made Bluesky possible (they grew out of Twitter) but it certainly made Twitter possible. ;-)

So that's why this might not be a solvable problem at this time. But starting the discussion with the WordPress people, well, it's always a good time to do that. :-)

Fri, 17 Jul 2026 12:54:41 GMT

Andrew I sent an email to Jeremy Herve at Automattic, cc'd to you.

I authorized his email account to be part of the discussion here.

At some point you should open a thread where everyone can participate on the repo.

https://github.com/scripting/rss.chat/issues

Fri, 17 Jul 2026 12:44:05 GMT

1. Yes -- the name is rss.chat.

2. It's not part of textcasting because it isn't about text, it's about structure.

3. Is all that's in the way is having a permalink for a comment? Can comments in WordPress have comments?

I don't want to be held back by trying to work with an existing product that has a different view of the web. WordPress is very close, because they support textcasting, but their view of discourse is not as simple as rss.chat's view and at the same time not as powerful.

They do it the way comments on blogs have always worked, more or less, although I should point out that discuss.userland.com didn't make a distinction between comments and posts, nor did its predecessor LBBS. We had those kinds of discussions while this was under development. I did offer to work with WordPress on this stuff, but they went in a different direction -- ActivityPub and AT Proto. I do think eventually they will want to be involved here. Since they've been pioneering a new path here, maybe we should find out what they think?

Anyway -- I will send a link to this post to Jeremy Herve at Automattic, he commented on this last week when we rolled it out publicly, and he's a good guy -- I think they went the wrong way, but I've made a few bets like that myself. ;-)

Fri, 17 Jul 2026 12:13:31 GMT

When we're talking about the rules for interop with rss.chat, is there a specific name we're using? Like, would it be an "rss.chat" WordPress plugin?

I read the interaction here: https://demo.rss.chat/?id=57 and the part where you said "treat comments as blog posts with their own permalinks" made me wonder, because this is not a rule from Textcasting.

For instance, I could in the main feed add `` and link to a comments feed (like https://test.geekity.com/2026/07/16/hoopla-world/feed/), but those comments don't have permalinks, just an anchor tag to the main post. So this wouldn't be compatible?

Fri, 17 Jul 2026 12:03:28 GMT

Right now, I'm figuring out what might be the best way to implement rss.chat standards in WordPress without reinventing everything that comes with WordPress. As I've been going through the elements, I've been thinking, "How would a consumer use this?" and this was one of my questions.

So if I were a feed reader and I pulled in the feed from demo.rss.chat and I had an item with `<source:account service="demo.rss.chat">dave</source:account>` I'm trying to think through what I'd do with that.

The first thing that comes to mind would be linking to the user's profile page, but we don't have an html profile as far as I can tell. We do have the user's RSS feed, and it's in the `<source>` element. The feed, interestingly enough, uses the user's homepage as the channel `<link>` and not a URL where you'd see the user's posts.

So right now I have more questions than answers, but this is where my line of thinking is going.

Fri, 17 Jul 2026 06:00:43 GMT

We did another test install with the updated docs. The agent picked up the port right away. It also suggested updating the docs to mention using "flUseMySql2": true with MySQL 8 and posted an issue at https://github.com/scripting/rss.chat/issues/10

"goodnightkiss" messages coming tomorrow

Thu, 16 Jul 2026 22:05:52 GMT

Tomorrow the plan is to add a new websocket-based way of making sure that only one copy of rss.chat is running at the same time. When you log on, on another computer or even on the same computer, this creates another copy of appPrefs.

If you change something, they get saved to the server. Meanwhile on another machine it doesn't have the new version, it has values that you don't want to write over the ones you changed on the other machine.

So when you log on, the server sends a "goodnightkiss" message to every copy it's connected to with your username. They then put up a dialog saying if you want to continue using rss.chat you have to reload.

All this is working in WordLand and FeedLand, so it's pretty likely it'll work right away. I know that sounds cocky, but that's how it's been going. It's like Claude is both a compiler and runtime, and I haven't seen any mistakes go by it without it catching them.

Thu, 16 Jul 2026 21:46:30 GMT

Andrew -- I'm interested. Is there a use-case you have in mind.

Not sure I would add anything to this element, but could create another element, and the use-case will give me an idea how to present it.

In general I don't like to add features until I have an actual use for it.

That said, I want encourage you to look over the source namespace and make comments and suggestions.

Thu, 16 Jul 2026 21:37:26 GMT

That was fast — thanks for the real-world test. The port gap is already fixed: step 8 of install.md now says the server listens on 1420, and that websockets have their own port. One detail worth knowing: the websocket default is 1422, not 1462 — 1462 is just what this server happens to use.

Thu, 16 Jul 2026 18:20:48 GMT

I've been thinking about the source:account element. Having service as a string like "instagram" makes sense because it's a single instance. For "mastodon" it's okay because the domain of the service is in the username. But I'm wondering if this will become an issue as more small services get spun up.

Should service be a URL to the service homepage? Maybe the service is on a specific port or running from a folder on the server. I know there isn't anything in the spec that says it can't be a URL, but would it be useful, since this is being parsed by a feed reader?

If we want to keep it just a label for the service, should there be an optional url or href element linking to the service homepage?

Thu, 16 Jul 2026 16:42:50 GMT

Server port issue
False web sockets error issue

Thu, 16 Jul 2026 16:26:14 GMT

Short answer: it worked. 😃
Claude did find a couple of stumbling blocks (it didn't know what port needed to be proxied, and there was a websockets error logged that wasn't really an error), but I'll write issues for those.

Thu, 16 Jul 2026 16:26:13 GMT

Scott is my bossman when it comes to stuff like this. :-)

Thu, 16 Jul 2026 15:58:13 GMT

You guys know about /init command for claude right ? usually you do this in our own repo, claude will fabricate a claude.md mostly for him, even tho you, as a human, can obviously drive what's in it, this is where you can specify some preferences too and if you commit it to the repo, then your contributors also get to work under the same paradigm with their claude

there you can have a docker or deploy section, where you define how the code should be run either node native way or docker based approach, once everything is in place, you can have custom /commands to actually deploy your code the way you want and claude will follow the exact instruction, you can grab a coffee instead of teaching claude the same stuff over and over again :)

Thu, 16 Jul 2026 15:53:31 GMT

The repo is current now — the theme is at 0.5.329, matching what's live. Also just for you: the upgrade section of install.md has a new step, the items.feedUrl migration — without it, feeds come up empty after switching to database mode. Worth a look before you update your fork's deploy.

Thu, 16 Jul 2026 15:53:14 GMT

We have to teach my Claude to do that too. We keep coming up with how useful it would be for it to have a throwaway instance to test with. I don't have the bandwidth to branch out into that area. Usual story. ;-)

Thu, 16 Jul 2026 15:49:09 GMT

As a test we're doing a straight install on a new, throwaway server. node is installed locally using fnm, and I've asked Claude to install mysql and caddy with docker.

Thu, 16 Jul 2026 14:51:05 GMT

Also, Claude has an account here, and will post, but only under my careful scrutiny.

For some reason I let it run wild on the docs. I don't generally review them, and I hope we develop a community that can read them and make note of things that don't sound right.

How the project works, division of labor

Thu, 16 Jul 2026 14:48:25 GMT

There have also been changes in the client and we're about to do something that connects client and server. Will document later. ;-)

There's a difference between the client and the theme. I have to write that up soon, but it's something that might not be immediately obvious. There's a replaceable box in the middle of the app. Only Claude writes code in that space, I insist that it talk to me as a user when it comes to that, I don't want any other perspective, where as in the rest of the code, I am the author, but I get support from Claude. Lots of support.

Thu, 16 Jul 2026 14:46:16 GMT

OK, I'll put an agent on it. 🕵️‍♂️

Thu, 16 Jul 2026 14:45:51 GMT

Not yet, we generally update the repo at the end of a session. We're still working on stuff.

Thu, 16 Jul 2026 14:43:29 GMT

It seems this has not landed on github yet ? origin/main has theme 0.5.322, and the live/deployed S3 has 0.5.328 ?

New sub-menu on Docs menu

Thu, 16 Jul 2026 14:28:26 GMT

Title of the menu -- RSS & OPML.

Links to the RSS 2.0 spec, the OPML 2.0 spec, source namespace and the RSS as a social network walkthrough.

A feed icon on every post

Thu, 16 Jul 2026 14:04:09 GMT

There's now a feed icon on every post.

When you click it a new tab opens with the post, ready to paste into your feed reader.

A blog post with a screen shot and explainer.

Thu, 16 Jul 2026 13:55:38 GMT

Much better approach !
same for dropping S3 and having Feeds in the database !

Thu, 16 Jul 2026 13:54:53 GMT

I'm already changing the deploy/ overlay in my fork to adapt to your changes :)

Thu, 16 Jul 2026 13:47:10 GMT

I'm taking a screen shot of this post, so I need there to be a reply. ;-)

Thu, 16 Jul 2026 13:46:38 GMT

We undid this, it works this way now. One server. Makes setup much easier. Please check it out, and do the upgrade on your instance.

Feed URLs change

Thu, 16 Jul 2026 13:17:59 GMT

The URLs for the feeds have changed. If you haven't subscribed to any of the feeds here, you don't need to do anything. But if you have, you should read this note, and subscribe via the new URL and unsub from the old one.

https://github.com/scripting/rss.chat/issues/7

Thu, 16 Jul 2026 00:10:45 GMT

yes definitely coming your way over email, gimme a few hours

Simpler instance-starting

Wed, 15 Jul 2026 21:53:24 GMT

We just converted both rss.chat and demo.rss.chat to use a different storage system, instead of using Amazon S3 to store the feeds, we're storing them in our database. So instead of there being two domains for on system, now there's only one. Cuts out one of the most complicated parts of setting up a new instance.

So if this works, it will show up on the blogroll on Scripting News, which is watching the old url, which should redirect to the new one.

Wed, 15 Jul 2026 21:06:31 GMT

Hi Scott — the server install just got simpler. Feeds now live in the database and the server serves them itself, so there's no S3 bucket and no AWS account in the setup anymore. install.md and config.md are updated to match. Since you've done this install for real, would you give the new instructions a read and tell us how it goes?

Wed, 15 Jul 2026 12:03:01 GMT

There's a new sub-menu for all pages on the GitHub repo.

The first two we're linking to are the worknotes files for the client and server.

We've just turned this over to Claude, previously I was taking the notes in my code, and they were spotty. Now Claude can add things to the worknotes files without my supervision.

Basically everything on the repo site that doesn't say otherwise was written by Claude.

Tue, 14 Jul 2026 22:57:50 GMT

There's a Docs menu, so now I have a place to put links to docs. Coming soooon.

Tue, 14 Jul 2026 22:54:00 GMT

How could I try your product? Do you have a demo site?

Tue, 14 Jul 2026 22:37:53 GMT

Yes this one is answered, I'll implement <source> usage in my own clients UI

Tue, 14 Jul 2026 20:15:14 GMT

I went back to the top of the thread, I think the question you asked was answered with the item-level <source> element?

Tue, 14 Jul 2026 18:30:31 GMT

It means this :

A comprehensive Microsub social reader plugin for Indiekit. Subscribe to feeds (RSS, Atom, JSON Feed, h-feed), organize them into channels, and read posts in a unified timeline interface with a built-in web reader UI.

It's a built-in RSS reader with integrated Micropub actions buttons, so this means that from the backend UI RSS items reader view I can Like, Repost, Bookmark, Reply-to, or simply write a note or an article (a note with a title) but no matter the post type on indiekit, It'll be pre-filled with the source, usually, the RSS item in question, coming from one of my Microsub (think RSS reader) channels (think Category) within the Interface, in my case the microsub reader UI is behind auth, but if I would open it to the public, it would look like your river of news UI, with buttons to interact with RSS items

Features

Microsub Protocol: Full implementation of the Microsub spec
Multi-Format Feeds: RSS, Atom, JSON Feed, h-feed (microformats)
Smart Polling: Adaptive tiered polling (2 minutes to 17+ hours) based on update frequency
Real-Time Updates: WebSub (PubSubHubbub) support for instant notifications
Web Reader UI: Built-in reader interface with channel navigation and timeline view
Feed Discovery: Automatic discovery of feeds from website URLs
Read State: Per-user read tracking with automatic cleanup
Compose Interface: Post replies, likes, reposts, and bookmarks via Micropub
Webmention Support: Receive webmentions in your notifications channel
Media Proxy: Privacy-friendly image proxying
OPML Export: Export your subscriptions as OPML
OPML Import: Import your OPML subscriptions

Tue, 14 Jul 2026 16:40:12 GMT

What does that mean to someone who doesn't know what microsub is?

Tue, 14 Jul 2026 16:22:01 GMT

I will make my microsub indiekit plugin read it/display it properly, so that it can display handles as a source, with avatar if any, it would make the whole thing much more natural from an external reader point of view

It will also benefit my other RSS feeds, because i'll be able to show the name of the source with a favicon or logo/avatar of the source

Tue, 14 Jul 2026 11:37:31 GMT

Not sure about this one. I understand the need for it, but how to fit it in, not sure.

We're going to move slowly here and hopefully there will be products that offer special features like this, highly customizable, using a variety of different approaches.

Remember, this is an attempt at a bootstrap -- not a silo. We're just here now to help get a bit of a fire burning. It's not like other systems where it can't happen unless the platform vendor does it. This is open and cloneable, and open source.

Tue, 14 Jul 2026 11:35:05 GMT

Ricardo, the information is in the feed in the <source> element.

This is a not-often-used element from core RSS 2.0.

Now most feed readers don't look for it, but it's there.

Tue, 14 Jul 2026 11:10:49 GMT

Another Idea, this time regarding authentification :

it would be probably trivial to enable IndieAuth authentification on rss.chat, this would allow me for example to auth with my own website, using my own h-card to provide, email, username, etc. this would allow anyone supporting indieweb building blocks to login without bothering with email or with more complex SSO dependency (github, google, etc)

Tue, 14 Jul 2026 11:06:51 GMT

Another idea that I'm thinking out loud as I write this down :

What if I could get a notification if/when someone directly replies to me, either using websub or perhaps an external notification provider (ie: ntfy.sh)

Tue, 14 Jul 2026 11:04:27 GMT

Just thinking out loud, but... if I subscribe to the "everyone's feed" https://users.rss.network/rss.xml in my RSS reader, I obviously see each entry, but there is no way to know who is the owner of the post.. if we'd push this idea further down the road of a "social network powered by RSS" I would love to be able to see right upfront "who" is the author of the post, a bit like we do in the rss.chat UI, i guess this is why the "client" exist, but I was wondering if we could make ANY rss feed reader able to display "rss.chat" streams with proper user attribution

Mon, 13 Jul 2026 20:58:09 GMT

In setting up the new server I forgot to configure the location of the S3 files for the feeds so we were overwriting the feeds for rss.chat.

When I post this, my personal feed and the everyone feed should rebuild and be good.

Mon, 13 Jul 2026 17:02:58 GMT

I like when I can contribute with approaches I do at work but for open-source projects :)

and Yes Claude is a great team mate to have around !!

Mon, 13 Jul 2026 16:34:30 GMT

Awesome work Dave (@Dave Winer)!

As the new guy here I sure hope I don't come off as a curmudgeon (yes I'm old but I'm not bad- tempered ;-) ), but I opened issue #3 on the repo. I was trying to respond to @Ricardo on my iPhone when I couldn't. After drinking my coffee, I realized I wasn't logged in. After finishing my muffin, I realized there was no way to login in. Now it's lunch time and I've posted an issue. I almost feel bad for doing it - like picking nits. I'll go quiet. I'm going to eat my sandwich.

Mon, 13 Jul 2026 16:33:13 GMT

Thanks Scott, that's high praise. :-)

I just finished my installation and the new server, demo.rss.chat, is up and running.

We have more excellent stuff in the pipe, still working out some details.

Also the worknotes.md files are working now. Claude is doing all the change notes there.

worknotes for server

worknotes for client

Still diggin as they say.

Mon, 13 Jul 2026 16:18:19 GMT

This is fantastic! And it’s very well documented, complements to you and @claude!

Feel free to test

Mon, 13 Jul 2026 15:48:04 GMT

Here is the localhost/vps deployment if anyone wants to test it : https://github.com/scripting/rss.chat/issues/2

Mon, 13 Jul 2026 14:59:18 GMT

Excellent. Love Localhost it's a great sandbox. Umm ... localhost too.

Mon, 13 Jul 2026 14:48:58 GMT

You could use unfurling/opengraph to even display a nice embed card of these links if the origin has it :p

Why two domains in Dave's architecture?

Mon, 13 Jul 2026 14:47:41 GMT

partly history, partly deliberate design.

History: rss.network was the project's earlier name — the server is still rssnetwork.js and calls itself that; the client later became rss.chat (his worknotes from July 3 mark the split).

Design: rss.chat is the dynamic app — the Node server, the API, the websocket — while users.rss.network is just a domain pointed at an S3 bucket of static feed files (and data.rss.network for the OPML).

Feed readers poll relentlessly, so serving feeds as static files means that traffic never touches the app server, feeds stay up even if the app is down, and it embodies his core claim: your feed is a durable artifact anyone can fetch, not an API response.

My instance keeps that same static/dynamic split — it just does it with one domain and a /feeds/ path on Caddy instead of a second domain, since there's no S3 in the picture.

Mon, 13 Jul 2026 14:38:52 GMT

I got it running in localhost :))

Mon, 13 Jul 2026 13:29:49 GMT

Ricardo, this is great and it's one of the reasons I wanted you here. The other was calling your RSS and OPML support "load bearing" in your app. ✓😀

Anyway, I am just about to start my test of the current install instructions.

We're not going to change that for a while, but I'm happy to help spread the word on new easier ways to do it. And then when the time comes, we can have alternate methods for doing an install.

Mon, 13 Jul 2026 13:15:17 GMT

Thanks for the suggestion — this is in now. URLs you type or paste into a post become links automatically when you save. If you spot anything that doesn't link right, let us know.

Yes to running your own server

Mon, 13 Jul 2026 13:12:57 GMT

Good morning sports fans!

This is the URL of one of the many blog posts I wrote over the weekend.

http://scripting.com/2026/07/12/121948.html

I also did a podcast.

https://shownotes.scripting.com/scripting/2026/07/12/myFirstRsschatPodcast.html

If you want to know where we're going, listen to the podcast. I ramble a lot, people who have heard me speak or talk on the phone know that I do that a lot. But if you're using rss.chat, esp if you're a developer, the ideas here are new, when applied to social networks on the web.

What you'll see there is a consistent theme, the action isn't in the rss.chat client, which is nice for sure -- but it's just the beginning. It's set up so that it can easily be replaced, on both ends, in the client or the server.

Ricardo, who we'll get to know, is a developer who is already signed on to this philosophy, and is running a FeedLand server, wants to get going with the server here, and I say yes! That's the way to go. We have to create a wave, to reinstate the web as the home of social networking on the web (saying it that way sounds silly, but people need to be reminded that the web is still there, and ready to be of service.

It so happens my first big task for the day is to create a second server for myself, thus testing the install instructions, and also to have an answer for people who want to kick the tires. This one will be open to anyone. No whitelist.

Mon, 13 Jul 2026 13:10:36 GMT

I'm reading this and I'm thinking... there is definitely better ways to deploy this, I'm going to submit an issue on the rss.chat repo to propose a deploy/ folder that would orchestrate deploying this either localhost or with a domain in a very easy way

Mon, 13 Jul 2026 13:00:35 GMT

Testing testing :)

Mon, 13 Jul 2026 11:19:46 GMT

If you know how to do it we’ll support you.

Also there’s a websockets based firehouse that’s implemented but not yet documented.

Mon, 13 Jul 2026 11:17:59 GMT

Glad to hear it. I think small groups of people joined by mutual respect, not trying to boil the ocean. And working together as opposed to trying to rule the world.