rss.chat worknotes

rss.chat feeds now support WebSub

Wed, 05 Aug 2026 19:02:00 GMT

Andrew Shell's rssCloud server speaks both protocols as of its 4.0 release, over one shared list of subscribers -- so a reader that speaks WebSub can now follow an rss.chat feed in real time, the way an rssCloud reader always could. Two things make it work. Every feed we serve announces the hub in a Link header, which is the first place the spec tells a subscriber to look. And when a feed changes we tell the hub, right alongside the rssCloud ping we already send. It covers the per-user feeds, the everyone feed, and the subscription list at data/subs.opml -- WebSub works for OPML as well as RSS. (Server v0.6.14, on rss.chat and demo.rss.chat now.)

You can point it at any hub

Wed, 05 Aug 2026 19:02:00 GMT

Two new settings, both with working defaults, so there's nothing to configure: flWebsubEnabled is on, and urlWebsubHub is Andrew's hub at https://rpc.rsscloud.io/websub. Put a different address in config.json and both the announcement and the ping follow it. Set flWebsubEnabled to false and neither happens. One note for operators: the header rides on feeds the server itself serves, so if yours publishes to S3 instead, there's nothing to announce.

Updating a server you already run

Wed, 05 Aug 2026 19:02:00 GMT

Get the new rssnetwork.js and package.json from the repo and restart. No new packages this time, so there's no npm install step.

Fixed a bug in feeds we generate

Sun, 02 Aug 2026 16:40:00 GMT

We were using the wrong value from config.json to build the URL for the <link> element in RSS.chat-generated feeds. Fixed in server v0.6.12, on both public servers. Thanks to iheartrss.com, whose checker caught the mistake.

Updating a server you already run

Sun, 02 Aug 2026 16:40:00 GMT

Get the new rssnetwork.js and package.json from the repo and restart. No new packages this time, so there's no npm install step.

Security fix in v0.6.11 -- please update

Sat, 01 Aug 2026 22:45:00 GMT

A user contacted us about a potential security issue. We responded quickly and with v0.6.11 the issue is removed. If you're running rssnetwork.js on a publicly visible server, please install the new version now. Thanks!

Updating a server you already run

Sat, 01 Aug 2026 22:45:00 GMT

Get the new rssnetwork.js and package.json from the repo and restart. No new packages this time, so there's no npm install step.

The server will read a file over the web for you: /readhttpfile

Fri, 31 Jul 2026 13:30:00 GMT

A browser page can only fetch from its own server unless the far server opts in, and most don't. That was the wall in front of the Scripts menu (the client-side story -- see the client worknotes): the menu is an OPML file that can live anywhere, and the app couldn't read it. Now there's a general door: /readhttpfile?url=... reads the address and answers with the text in a filetext member, so the next feature that needs to read a file over the web won't have to solve this again. The new config setting for the menus, urlMenuOpml, goes to the client with the rest of the settings; leave it out and nothing changes. (Server v0.6.10, both public servers.)

Updating a server you already run

Fri, 31 Jul 2026 13:30:00 GMT

Get the new rssnetwork.js and package.json from the repo and restart. No new packages this time, so there's no npm install step.

You can add your own menu to the menubar -- the Scripts menu

Fri, 31 Jul 2026 13:30:00 GMT

Point one new config setting, urlMenuOpml, at an OPML file on the web, and the app builds menus from it: every top-level node in the outline becomes a menu in the menubar after Docs, nesting becomes submenus, a node whose text is a single hyphen draws a divider, and comment nodes stay invisible. Choosing a command branches on the node's type -- today a type="link" node opens its url in a new tab; other types get their behaviors later. The name says where this is going: it comes from Frontier and Drummer, where the menus run scripts. To change your menus, edit the outline and reload the app -- the server doesn't restart, because the file is read fresh each time the app starts up. The first one is live on rss.chat now, the DW menu, and demo.rss.chat runs DW's test menu -- testmenu.opml, which is also the example to start your own from. Questions and reports go in issue 20. Your server needs to be at v0.6.10 to hand the setting to the client -- see the server worknotes.

That error message at startup is gone

Wed, 29 Jul 2026 16:23:00 GMT

Every time the server started, it printed webSocketStartup: theWsServer.listen is not a function -- alarming to read, especially on a new install, and entirely misleading: websockets were working the whole time. It's fixed, and the startup log is quiet now. To get it, update daveappserver: run npm install in your server's folder and restart.

And reallysimple, the feed reader FeedLand and other apps are built on, now understands rss.chat conversations

Wed, 29 Jul 2026 16:23:00 GMT

Until today it read our feeds but quietly discarded the two pieces that make a conversation a conversation -- which post a reply is replying to, and where a post's replies live. So an app reading rss.chat through it saw a flat list of posts and no threads, with nothing to indicate anything was missing. Fixed and published. Anything built on reallysimple gets threading by updating the package.

Getting into your own server no longer waits on email

Wed, 29 Jul 2026 14:30:00 GMT

Sign-in is a magic link, so until a new server can send mail, nobody can get in -- including the person who just installed it. That's a discouraging place to be stopped, and it's exactly where John Johnston found himself after putting rss.chat on his Mac: his mail provider wanted a verified sender identity before it would send anything, and in the meantime his own server wouldn't let him in. He got past it by reading the confirmation code out of the terminal log and typing the sign-in link himself. As of server v0.6.8, that trick is a feature. On the machine the server is running on, open http://localhost:1420/localnewuser?screenname=yourname&email=you@example.com and the browser lands on your home page, signed in as that name, ready to post -- no mail sent, nothing configured first. It works only from that machine: a request from anywhere else is refused, including one forwarded by a proxy like Caddy, nginx or PagePark sitting in front of your server, because the endpoint creates an account without checking that you own the address. So it's a way to look around your own install while you sort out email -- which you still need before anyone else can sign in. Written up in email.md. Thanks to John, whose report is what got this built. (Both public servers.)

Updating a server you already run

Wed, 29 Jul 2026 14:30:00 GMT

Get the new rssnetwork.js and package.json from the repo and restart. No new packages this time, so there's no npm install step.

Replying through the API works with either field name

Mon, 27 Jul 2026 18:15:00 GMT

When you read a reply, the field pointing at its parent is called inReplyToNum. When you post one, the API expected inReplyTo -- and if you sent the other name, your reply was accepted but landed unthreaded, with no error. The first developer to build on the API did exactly that, reasonably. As of server v0.6.7 the server takes either name, so a reply threads no matter which one you send. (Both public servers.)

Posting through the API got simpler: send markdown or HTML, whichever you have

Mon, 27 Jul 2026 17:30:00 GMT

Until today the API expected HTML -- send only markdown and your post came out empty, which is exactly what happened to the first person who tried. Fixed, as of server v0.6.6 on both public servers: a markdown post and an HTML post come out looking the same, and a post with no text at all is refused with a plain sentence saying why. Edits work the same way.

And the API docs were rewritten to earn that story

Mon, 27 Jul 2026 17:30:00 GMT

The newpost entry now opens with the smallest call that works -- one field of markdown -- followed by a complete call you can copy, the actual response it produces, and what an error looks like. Getting your credentials no longer requires reverse-engineering: sign in to rss.chat in your browser, open the console, and the authentication section shows you exactly where your two values are. And there's a new page about the approach itself: How we document APIs -- a living document on writing docs for the reader, examples first, nothing but the truth. If you're documenting your own service, take whatever's useful. Thanks to jimr, whose report on demo.rss.chat started all of this.

Updating a server you already run

Mon, 27 Jul 2026 17:30:00 GMT

Get the new rssnetwork.js and package.json from the repo, run npm install (one new package, the markdown renderer), and restart.

The RSS.chat network has a name and a front door

Sun, 26 Jul 2026 16:49:00 GMT

All the open pieces around the app -- every user's RSS feed, the everyone feed, the OPML subscription list, the source namespace, textcasting, markdown in the feeds, the firehose, rssCloud, the API, api.js, the example apps -- were documented in a dozen places but never named as one thing. Now they are: the RSS.chat network, a new top-level page in the repo that maps every piece and says the idea out loud: rss.chat isn't really a product, it's an application built on a network anyone can plug into without asking permission. DW named it and wrote the case on Scripting News; the api.js doc now opens with the same name. Naming by DW, page by CC.

Every user has a feed from the moment they sign up

Sat, 25 Jul 2026 22:17:00 GMT

It was reported that until someone posted for the first time, their feed address answered with a 404 -- which looked broken to anyone who subscribed to the whole community from the subscription list. Wrong, and now fixed two ways: when a new account is created, the server publishes the feed immediately -- a valid RSS feed with the user's name and no items yet -- and at startup the server checks every user and quietly publishes a feed for anyone missing one, so everyone who signed up before this change is covered too. A user is a feed, from day one. (Server v0.6.5.)

And every server can now back itself up, nightly

Sat, 25 Jul 2026 22:17:00 GMT

One line in config.json turns it on: "flNightlyBackup": true. Every night the server writes its whole database -- users, posts, likes, files, media -- to one dated JSON file in data/backups/, using the same export format that carried both public servers through the SQLite migration, restorable onto a fresh server with the import verb. Nothing to install, no cron, no scripts: the server does it itself, the way it should be. It's off by default; flip the flag and restart.

Updating a server you already run

Sat, 25 Jul 2026 22:17:00 GMT

Get the new rssnetwork.js and package.json from the repo and restart. On the first restart you'll see a log line for each user whose feed gets backfilled, then it's quiet. Add "flNightlyBackup": true to config.json if you want the nightly backup.

The Docs menu now reaches everything

Sat, 25 Jul 2026 15:39:00 GMT

Two new submenus under Docs: Blog posts, with the Scripting News pieces that tell the rss.chat story -- what it's for, how the ecosystem fits together, today's post about the API -- and Github Repo, with the places a user or developer would want in the repo: the repo home, how to run your own server, the API docs, the example apps, the questions-and-answers thread, and both worknotes pages. Everything about rss.chat is now one click from inside rss.chat. By DW.

A whole conversation in one call: /getthread

Sat, 25 Jul 2026 15:15:00 GMT

Every conversation on rss.chat has always been walkable through the feeds -- each post's item points at a comments feed, each reply can point at its own, and the threadwalker example assembles a thread that way, one fetch per post, no API needed. Now there's a second door: call /getthread with a post's guid (or id) and the server answers with the post's item record plus a replies array -- each reply the same shape, nested all the way down. You get the post you ask about and everything under it; ask about the root and you get the whole thread. It's one call instead of many, it's less work for the server than serving the walk, and it's the same tree either way. No authentication -- it's an open read, like all the reads. Documented in api.md, with a new example app, getthread, that prints a conversation as an indented outline in one call. (Server v0.6.4, running on rss.chat and demo.rss.chat now.)

The hit counter now counts only rss.chat

Sat, 25 Jul 2026 14:56:00 GMT

When the app starts up it registers a hit, so there's a running count of how much rss.chat is used. But everyone running their own server uses this same client -- and their visitors were being counted too, hits arriving from servers that aren't ours. Now the client checks which server it's serving and only counts when it's on an rss.chat domain. If you run your own install, your traffic is yours alone. Fixed by DW. (Client v0.6.12.)

These worknotes are a feed now

Fri, 24 Jul 2026 16:45:00 GMT

Subscribe to https://news.rss.chat/worknotes/rss.xml and every improvement to rss.chat arrives as it ships -- the worknotes from the server and the client, together in one feed, newest first. Each item carries a category element saying which side it came from, so a reader that filters by category can follow just one. The feed announces updates over rssCloud, so subscribers who speak it hear within seconds. And in the spirit of a product built on RSS: the feed is generated by a script you can read, published right next to the feed itself -- worknotesFeed.belt. If you run an rss.chat server, this feed is the way to hear about updates like the security fix of 7/23 the moment they're posted. You're reading the first item that was born in the feed.

The Return key stopped breaking paragraphs at the wrong spot

Thu, 23 Jul 2026 23:30:00 GMT

A bug DW reported earlier but couldn't reproduce finally showed itself: paste a chunk of text that includes a link, put the cursor somewhere later in the text, press Return -- and the break landed at the link instead of the cursor, tearing the link out onto its own line. The trick to reproducing it: it only ever happened on the first Return after that kind of paste, never again in the same post -- which is exactly what made it so slippery. Now the break lands where the cursor is, and links stay in their sentences. (Theme v0.5.339.)

A security fix -- posts are now cleaned as they're saved -- and the first update note of a new kind: how to bring a server you already run up to date

Thu, 23 Jul 2026 14:06:00 GMT

A post's text is written by its author and then shown to everyone who reads the timeline, which means anything hidden inside it runs in every reader's browser. Until today the server stored a post's text exactly as it arrived, so a post could carry markup that did more than format words. As of server v0.6.3, every post passes through a cleaner on its way into the database. Ordinary writing comes through untouched -- links, bold and italic, quotes, lists, and pasted images are all kept -- but anything that could run code is removed before the post is ever stored. Because the cleaning happens as the post is written, it protects every reader of every feed and timeline at once, and no old or unusual browser can slip past it. Both public servers, rss.chat and demo.rss.chat, are already running it. Thanks to the reader who reported this privately.

Updating a server you already run

Thu, 23 Jul 2026 14:06:00 GMT

This is the first of a kind of note you'll see here from now on: when a change matters to people running their own installs, the steps to update will live right here in worknotes. For this one:

Get the new rssnetwork.js and package.json from the repo.
In your server's folder, run npm install. The updated package.json adds one package -- the cleaner -- and this brings it in.
Restart the server.

That is the whole update. Nothing in your config or your database changes, and the cleaner applies to new and edited posts the moment you restart.

Posts can carry images now, and the server stores and serves them itself

Wed, 22 Jul 2026 22:15:00 GMT

A new endpoint, /uploadmedia, accepts an image from a signed-in user -- up to 2MB, sent base64-encoded in the request body with the content type as a parameter -- stores it in a new media table in the database, and answers with the address it will be served from: /media/1, /media/2, and so on, permanent ids just like posts. Request that address and the image comes back byte-for-byte with the right content type. No filenames, no image processing, no separate file storage -- the picture lives in the same database as everything else, which means the same one-file simplicity on SQLite servers, and the same backup story: the export and import verbs carry the media table along (the bytes travel as text inside the JSON), so a migrated server keeps its images with their addresses intact. The table is called media rather than images on purpose -- one binary table can someday hold audio and video too, and the type column already tells them apart. MySQL servers get the table definition in installMysql.md. The upload limit is a config setting, maxMediaUploadBytes, 2MB by default. Under the hood, davesql (v0.7.1) learned to write binary values on both engines -- the last piece the feature needed. (Server v0.6.1.)

Paste an image into a post -- that is the whole feature

Wed, 22 Jul 2026 22:15:00 GMT

Copy a screenshot or an image file to the clipboard, click into the composer, paste: a small "Uploading image..." note appears at the cursor and a moment later the picture takes its place, sized to fit the column. Publish it and the image is part of the post, served from your server like everything else you write. It works like Slack and GitHub -- no Upload command, no dialog, nothing to learn. The limit is 2MB per image; paste something bigger and a dialog says so. The Publish button waits politely until every pasted image has finished uploading, so a post can never go out with a half-arrived picture. Rich-text mode only for now -- markdown mode will get the same feature, inserting the image reference as text, over the same plumbing. First image posts in the wild: demo 227 and 228 ("We have images.") and rss.chat 378. (Theme v0.5.338, with a new uploadMedia call in api.js by DW.)

SQLite is now the default, everywhere

Wed, 22 Jul 2026 15:30:00 GMT

demo.rss.chat migrated this morning -- 58 users, 210 posts, 153 likes, 138 served files, five minutes -- so both public servers now run on one-file databases. davesql 0.7.0, the package carrying the engine, is published on npm. And the repo caught up with the reality: the example config.json ships with "flUseSqlite": true, install.md is now the SQLite install -- no database server, no schema to paste, a Backups section, and the six-step migration for existing MySQL servers -- while the whole MySQL story (config, schema, upgrade notes) moved to its own page, installMysql.md. Dave announced it on Scripting News. One lesson from the demo migration made it into the doc: if the import stops on a UNIQUE constraint error, the server touched the new empty database before the import ran -- delete the file and re-run.

The install docs also gained the piece that was missing: email

Wed, 22 Jul 2026 15:30:00 GMT

Sign-in is a magic link, so a new server can't sign anyone in until it can send mail -- and nothing documented how. New page: email.md -- the four SMTP settings for sending through a provider you already use, or Amazon SES with a link to Scott Hanson's setup walkthrough. It's a step in the install checklist now, along with a link to the questions thread -- if something in the install isn't working or isn't explained, that's where to say so.

rss.chat itself now runs on SQLite

Wed, 22 Jul 2026 15:30:00 GMT

This morning's note said an rss.chat server can run on SQLite; by this evening the flagship server does. Both production servers were upgraded to the new software (v0.6.0) during the afternoon, running on MySQL exactly as before -- proof that the change disturbs nothing for existing installs. Then the migration itself: export the whole database to one JSON file, set "flUseSqlite": true in config.json, import, restart. All 752 rows -- 12 users, 361 posts, 217 likes, 162 served files -- came across with their ids intact, so every permalink still works, and the Software versions dialog now reads "SQLite version: v3.49.2." The MySQL database was never written to during the switch, so rolling back would have been one config line -- it wasn't needed. Total elapsed time, including a wrong turn when an unsaved config file sent the import to the wrong engine (it stopped harmlessly on the first duplicate row): about twenty minutes. demo.rss.chat follows tomorrow.

A startup crash that wore two disguises

Wed, 22 Jul 2026 14:45:00 GMT

If you left the editor open with a draft when you last used the app, the next startup could crash quietly: the app tried to restore your draft before one of its writing tools -- the piece that turns rich text into markdown -- was ready. Everything after the crash never ran, and the damage showed up as two seemingly unrelated bugs: your name missing from the menu bar, and the Publish button refusing to enable while you typed in the body of a post (typing in the title, which takes a different path, still worked -- which is why the bug seemed to be about titles). It surfaced during the demo.rss.chat database migration this morning, was reproducible one minute and gone the next, and the last piece of the puzzle was browser caching: the fix was live but browsers kept running the old code until the cache-buster on the script address changed. Fixed by DW: the converter now starts first thing, and the script address was bumped so every browser picks up the cure. (Client v0.6.11.)

The Software versions dialog now tells you which database engine the server runs on

Wed, 22 Jul 2026 14:45:00 GMT

Servers can now run on SQLite as well as MySQL (that's the day's big server-side story -- see the server worknotes), and the dialog's last line follows along: it says "SQLite version" or "MySQL version" to match the actual engine, with the real version number either way. The server sends the engine name in a new databaseEngine member of the user-data record, and the client reads it as of v0.6.10. First seen live on scratchpad.rss.chat, the first server running on SQLite.

An rss.chat server can now run on SQLite -- no MySQL, no database setup of any kind

Tue, 21 Jul 2026 15:45:00 GMT

One new member in config.json chooses the engine: "database": {"flUseSqlite": true, "databaseFilePath": "data/myserver.db"}. The database is a single file that creates itself, tables and all, the first time the server runs -- the install becomes download, npm install, run. Everything else is identical: same features, same feeds, same API, and a server that says nothing stays on MySQL exactly as before. The engine itself went into davesql (v0.7.0), where all the SQL expertise lives, so the same switch is available to every app built on it. The first server running this way is live at scratchpad.rss.chat -- sign-up, posting, replies, likes, and feeds, all served out of one file on a fresh droplet that has never heard of MySQL.

And every server now has a backup story: export and import

Tue, 21 Jul 2026 15:45:00 GMT

node rssnetwork.js export backup.json writes the whole database -- users, posts, likes, feeds -- into one JSON file and exits without starting the web server; node rssnetwork.js import backup.json loads that file into an empty server. Both work on either engine, which makes the pair the door between them: export from a MySQL server, import into a SQLite one, and the server's whole history comes along -- posts keep their ids, so every permalink survives. The Software versions dialog now names the engine too, so a glance tells you what a server is running on.

Three small courtesies for writers, all shipped today

Mon, 20 Jul 2026 21:45:00 GMT

Posts no longer carry blank lines at the end -- if your post trails off with empty paragraphs or stray Returns, the server trims them when it saves, so nothing renders as mysterious empty space below your last line (a new config setting, flRemoveBlanksAtEnd, is on by default; set it false to keep trailing blanks). The autolinker learned that install.md is a document's name, not a web address -- bare names ending in a file extension that happens to be a real internet domain ending (.md, .zip, .sh, .py) stay plain text, while real addresses, including bare domains like rss.chat, still become links. And the server's subscription list can now carry a title of your choosing: set titleForSublist in config.json; leave it out and the title is unchanged.

The reply editor got out of your way

Mon, 20 Jul 2026 21:15:00 GMT

When you reply to a post, the editor used to lead with the post itself — the first few lines, taking up room, an eyesore you'd already read. Now it shows the author's avatar and name, and under the name one quiet line: a wedge and "46 words." Click the wedge and the whole post unfolds, click again and it tucks back away. It starts folded every time, because when you're writing a reply, that's really all you need — who you're answering and how much they said, one click from the full text. (Theme v0.5.331–0.5.337.)

Software versions, in one place

Sun, 19 Jul 2026 17:00:00 GMT

Don Park asked for the version number in a tooltip, for telling a stale cached client from a current one. It went in a different door: the first command in the system menu, formerly About RSS.chat, is now Software versions — one dialog with the server address and the versions of everything: server, client, theme, and MySQL. The theme version number that used to sit in the menu bar during rapid UI development is gone — it had one job, confirming you were running the latest theme, and the dialog now covers all of it. Work by DW; his reply to Don is 353.

The goodnight dialog no longer leaves a dead app behind

Sun, 19 Jul 2026 14:15:00 GMT

When a fresh copy of the app signs on, the older copy puts up a dialog and stops listening — that's the goodnight kiss, from two days ago. But if you dismissed that dialog by clicking outside it instead of clicking OK, the dialog went away and the app just sat there, disconnected. Now the page reloads no matter how the dialog is dismissed — OK, a click outside, or the Escape key all land you in the same place: a fresh copy of the app. (Client v0.6.8.)

The browser tab now shows your server's name

Sat, 18 Jul 2026 18:30:00 GMT

The home page's title was hard-coded to "rss.chat" — every instance, whatever its name, said rss.chat in the tab. Now the title comes from the server's productNameForDisplay setting, so demo.rss.chat says demo.rss.chat, and your instance says whatever you named it. Work by DW.

The `/feed` endpoint can now return the feed as JSON

Sat, 18 Jul 2026 17:20:00 GMT

As of server v0.5.32, /feed takes a format parameter: format=xml (the default) returns the RSS document as always, and format=json returns the same feed translated into JSON. The structure is rss.channel.item, the names are RSS 2.0's own names, every element -- source:markdown, source:inReplyTo, source:comments, all of it -- exactly where the XML puts it. An unsupported format name gets an error naming the two real ones.

threadwalker caught up with yesterday's feed change

Sat, 18 Jul 2026 16:45:00 GMT

Ricardo reported on issue #14 that the walker printed ? for every author -- it was still reading the item-level source:account element that came out of the feeds yesterday. Now it reads what the feeds actually say: replies carry a core RSS <source> element naming the author, and in a user's own feed the channel says whose feed it is. Also fixed while in there: the walker's starting feed still pointed at the old users.rss.network address, which now answers with a redirect that Node's bare https.get won't follow -- it points at https://rss.chat/users/manton/rss.xml directly. Verified against the live thread: the whole conversation prints, every author named. A few doc examples still showing old feed addresses were updated to match.

The firehose is now documented, with two working demo apps

Sat, 18 Jul 2026 15:30:00 GMT

Every rss.chat server broadcasts every new post, edit, and like over a websocket the moment it happens -- the same stream the shipped client uses to keep timelines current. As of today there's a doc that tells you how to drink from it -- firehose.md: the address, the wire format, the two verbs, and the three things a well-behaved listener does -- and two demo apps in examples/firehose that prove it: a Node command-line app that logs each post as it arrives, and a browser page that shows the JSON flowing through. Each is about a page of code, adapted from the feedlandSocket demos -- it's the same protocol FeedLand uses, so a listener written for one can listen to the other. No account, no key: connect and the posts come to you.

`source:account` moved to where the spec says it goes

Fri, 17 Jul 2026 20:05:00 GMT

Our feeds had been putting a source:account element inside every item. The source namespace defines it as a channel-level element — it says whose feed this is, not who wrote an item — and at the item level it was redundant anyway: in the mixed feeds, every item already carries a <source> element with the author's feed URL and name. As of today, each user's own feed says it once, in the channel: <source:account service="rss.chat">dave</source:account>. The items carry it no more. The everyone feed and the comments feeds have no channel account — they have many authors, and their items keep <source> for per-item attribution. If you've been reading the item-level element, read the channel-level one (single-author feeds) or <source> (mixed feeds) instead. Already-published feeds keep the old shape until they next rebuild. The report that got this fixed is issue #9. The channel-level support went into daverss, the shared RSS-building package, as a new optional setting.

Only one copy of the app runs at a time now — the goodnight kiss

Fri, 17 Jul 2026 16:15:00 GMT

If you're signed in and open the app in a second tab, or another browser, or another machine, the older copy puts up a friendly dialog: the app is running in another tab, click OK to reload this one, or close it, no work lost. This fixes a bug that bit quietly and repeatedly: a change you made in one place — say, the URL of your icon in settings — could be silently wiped when an older copy, still running with the old settings, saved over it. Now a stale copy stands down the moment a fresh one signs on, so your latest settings always win. When the app connects, it identifies you to the server, and the server sends a "goodnight" message to every other connection you have open — the name comes from that message. (Client v0.6.7.)

The home page now announces its own feed

Fri, 17 Jul 2026 14:15:00 GMT

Every server's home page carries a feed auto-discovery link — the standard <link rel="alternate"> in the page head, pointing at that server's everyone feed. Point a feed reader at the home page of rss.chat, or demo.rss.chat, or your own install, and it finds the feed by itself, no hunting for the URL. The address is filled in per-instance by a new home-page macro, [%feedUrlEveryone%], so the same template serves every server correctly. Work by DW.

The install doc learned from two real installs today

Thu, 16 Jul 2026 22:00:00 GMT

Scott Hanson tested the new database-mode instructions by having an AI agent do a fresh install on a throwaway server — it worked, and the one thing it had to hunt for became issue #8: the doc never said what port to point a reverse proxy at. Fixed the same hour: step 8 of install.md now says the server listens on port 1420 (configurable via port in config.json or the PORT environment variable) and websockets have their own port, 1422 (websocketPort). Separately, for anyone upgrading an existing S3 server to database mode, the upgrade section gained the step we ourselves missed: a one-line SQL update that rewrites the old feed addresses stored with each post — without it, every rebuilt feed comes up empty. If you run a server from before today, that section is worth a read.

A person's name now takes you to their posts

Thu, 16 Jul 2026 22:00:00 GMT

Clicking a name anywhere in the timeline used to open that person's website in a new tab — surprising when what you wanted was to see what they've been posting. Now the name does what the avatar does: it shows their timeline, right in the app. Their website isn't lost — it's linked from their profile page. This came out of real use: Dave clicked a name expecting the person's posts and landed on their homepage instead. (Theme v0.5.330.)

A feed icon on every post

Thu, 16 Jul 2026 15:30:00 GMT

Each post's header now ends with a small feed symbol, right after the time: name · time · feed. Click it and the author's feed opens — a real RSS 2.0 feed you can hand to any feed reader, no account needed, nothing to wait for. Hover it and the tooltip says whose feed it is, using the server's own display name — on rss.chat, "Dave Winer's rss.chat feed." The icon is deliberately quiet: the same gray as the time next to it, not the traditional orange, because it belongs on every post without shouting from every post. Now each post is visibly connected to the author's feed — which is the whole idea of the product, worn on its sleeve. Dave wrote it up on Scripting News: A feed icon on every post. (Theme v0.5.323–0.5.328.)

The Docs menu keeps growing

Thu, 16 Jul 2026 15:30:00 GMT

A new sub-menu links the docs for RSS and OPML — the two formats the product is built on, now a click away from the timeline. Later the same day: a Blog posts sub-menu, collecting the story so far — from "Can RSS be a social network?" through today's feed icon.

Tooltips moved home too

Thu, 16 Jul 2026 15:30:00 GMT

The hover tips on the left-panel icons — Home, New post, Feed, Data — used to appear off to the right, floating over the timeline, pointing at nothing in particular. They now appear directly below the icon and its word. (Theme v0.5.329.)

The biggest install hurdle is gone. Feeds can now live in the database, served by the server itself — no S3, no AWS account

Wed, 15 Jul 2026 21:15:00 GMT

A new config setting, flFeedsInDatabase, turns it on. When it's true, the server stores its RSS feeds and its subscription list in a new files table and serves them from its own domain — your feed is at https://yourserver/users/yourname/rss.xml, the subscription list at https://yourserver/data/subs.opml, and the four feed-location settings from Monday's note aren't needed at all. When it's false (the built-in default), nothing changes — S3 publishing works exactly as before.

Turning it on for an existing server is one restart: at startup the server backfills — rebuilds every user's feed, every comments feed, and the everyone feed from the database, so the files are all there before the first request. Both of our servers, rss.chat and demo.rss.chat, made the switch today.

One thing the flag can't do for you: subscribers still point at your old S3 addresses. The fix is a redirect where the old feed domain is served. Ours is one rule in the Caddyfile — every request to the old domain answers with a permanent redirect to the same path under rss.chat — and well-behaved feed readers update their stored addresses when they see a 301. Details in install.md, which now describes the database-mode install; S3 remains documented in config.md for those who want it.

You can select text in the timeline now

Wed, 15 Jul 2026 00:30:00 GMT

Until today the text of a post couldn't be selected — to copy a phrase from your own post you had to open the editor, and for someone else's post there was no way at all. Now post text selects like any text on any page: drag across it, copy it, quote it. The one wrinkle worth solving: clicking a long post is how you expand and collapse it, and a drag-select ends with a click — so the click that finishes a selection is ignored, and plain clicks still open and close the post the way they always have. (Theme v0.5.322.)

Server v0.5.27. The feed-location settings have no built-in defaults anymore

Tue, 14 Jul 2026 13:45:00 GMT

Yesterday's note told how a new server that didn't set its own S3 locations inherited defaults pointing at rss.chat's folders. As of this version those defaults are gone: rssS3Path, rssFeedUrl, opmlS3Path, and opmlListUrl start as undefined, and your config.json supplies the real values — see Feeds on S3 in config.md. rss.chat's own config now sets its four values explicitly, the same as every other install. (rssFilename keeps its default, rss.xml — that one is right for every server.)

A detail that made this easy to verify: the server rebuilds its subscription list, subs.opml, on startup. Restart with the new settings and the file appears at its new address right away — no waiting for a post to trigger a rebuild.

There's a second server now — demo.rss.chat — and standing it up taught the docs some things

Mon, 13 Jul 2026 23:20:00 GMT

Dave installed it on a different machine, following install.md for real, start to finish. It's open — no whitelist, anyone can join. Two lessons from the exercise, both now in the docs:

First, every server needs its own S3 locations for feeds. The install initially inherited the defaults, which point at rss.chat's own folders — so the new server was overwriting the original's feeds. config.md now has a Feeds on S3 section covering the four settings, and they're in the example config.json so they're on every installer's list.

Second, websockets need a route in your reverse proxy. Live updates run over a websocket on their own port (websocketPort), and the proxy in front of the server has to send upgrade requests there — with Caddy, that's a matcher on your domain plus the Connection/Upgrade headers, proxying to that port. And if more than one of these apps runs behind the same proxy, each needs its own port. Until the route existed, the site worked fine and only live updates were missing — if new posts don't appear without a reload, this is the first place to look.

Also new today: server v0.5.26 adds blockedUsersList to config.json — an array of email addresses that can't sign up, sign in, or post. It's checked fresh from the file on every use, so adding an address takes effect immediately, no restart. Case doesn't matter.

Links show up the moment you save them

Mon, 13 Jul 2026 14:15:00 GMT

The server now turns bare URLs into links when a post saves (the story is in the server worknotes), and the client keeps up: when you update a post, the copy in the timeline repaints from what the server actually saved, so the new links are clickable immediately — no reload needed. (Theme v0.5.321.)

Server v0.5.25. Bare URLs become links, automatically, when a post saves

Mon, 13 Jul 2026 13:30:00 GMT

Type or paste a web address into a post and it's clickable when it publishes — no more selecting the text and reaching for the link button. The idea came from a user, Don Park, the day before it shipped.

The work happens on the server, in newPost and updatePost, so every client gets it for free. The post's text passes through the Autolinker package on its way to the database — it understands HTML, so it only touches plain text: a URL that's already part of a link, or sitting inside an image tag, is left alone, and the link text is exactly what the writer typed. The stored markdown is untouched — the source stays as written; only the rendered text gets the links.

The API has a doc now

Mon, 13 Jul 2026 03:55:00 GMT

api.md, new in server/docs, documents the HTTP interface between the rss.chat client and its server — every read and write call, the no-passwords email flow, the item record field by field, and the websocket verbs. The client that ships with the product is just one user of this API; the doc is for whoever wants to build the next one.

Also in server/docs: install.md's "An AI can do this install" section moved to the end of the doc — it's a good trick, but not the first thing a new host-runner needs to read.

A deleted post can't crash its own comments feed anymore

Sun, 12 Jul 2026 15:50:00 GMT

There was a sequence that could bring down a feed rebuild: someone replies to a post, the author deletes the post, then the reply gets edited. Rebuilding the comments feed found the parent gone — deleted posts are filtered out of every query — and crashed trying to read it. Now the build answers the way this server always answers: "Can't build the comments feed for post N because the post has been deleted."

Also: this file moved from server/docs to server/code. Worknotes live with the code, because you need the worknotes to read the code.

Sign-up and sign-in emails were going to spam. Fixed — no code change

Sat, 11 Jul 2026 23:45:00 GMT

The cause: mailSender was a gmail.com address, but the mail actually goes out through Amazon SES, and Gmail sends mail to spam when the sending server isn't authorized to send for the address's domain — as policy, since 2024. The fix, useful to anyone deploying this server: verify your domain as an identity in the SES console (it hands you three DKIM CNAME records to add to your DNS), then set mailSender in config.json to an address on that domain. It doesn't need a real mailbox behind it — rss.chat now sends as hello@rss.chat. Verification took minutes, and the first email after the change landed in the inbox.

Home does it all now, and Surface is retired

Sat, 11 Jul 2026 23:45:00 GMT

Surface — the icon that pulled you out of a deep conversation back to your place in the timeline — lived less than two days, but it proved the idea. Now that lifeline is Home's first stage: when you're buried in a story, a profile, a flipped view, or an open conversation, clicking Home brings you back to the timeline with the cursor still on the post you were reading. Click it again and you're at the top, everything reset, cursor on the newest post. It's the same rhythm as the Home tab in the Twitter and Instagram apps — tap once to come back, tap again for the top — with one icon fewer to remember. (Theme v0.5.318–0.5.320, including a fix for a sneaky side effect: the icon panel used to shift a hair when the page scrolled, which could put a different icon under your mouse between the first click and the second.)

Sign-in emails reach the inbox now

Sat, 11 Jul 2026 23:45:00 GMT

rss.chat's confirmation emails had been landing in spam. The app now sends from hello@rss.chat, and the domain is verified with Amazon SES, so Gmail and the rest can see the mail is really from us. The full story is in the server worknotes.

Sat, 11 Jul 2026 16:50:00 GMT

The server moved into the rss.chat repo. One repo for the whole product now, organized by part: the server's code is at server/code, and these docs — install, config, and this file — are at server/docs. The software is unchanged; only the address is new.

The repo has its real shape now

Sat, 11 Jul 2026 16:50:00 GMT

github.com/scripting/rss.chat is organized the way the product is: a client folder and a server folder, each with its own code and docs, and a new top-level examples folder for complete apps built on the APIs. The first example is threadwalker, a small Node app that walks a whole conversation using nothing but the RSS feeds — no API calls, no account — and prints it as an indented outline.

These docs moved too. The basics doc is now the readme of client/docs, so it's the first thing you see when you browse the folder, and the firehose documentation is a section inside it — one document, because the whole site is for developers.

A post never shows twice

Fri, 10 Jul 2026 21:07:00 GMT

Opening a conversation with the wedge had a flaw: a reply might already be sitting in the timeline as its own post, so expanding its parent put the same words on screen twice. Now, when replies open under a post, any of them that were standing in the timeline fold into the conversation — every post appears exactly once. Close the wedge and they return to their places. If your cursor was on one of those posts, it follows it into the conversation. (Theme v0.5.316.)

Home is the way out

Fri, 10 Jul 2026 21:07:00 GMT

Dave opened a conversation, read it, and then couldn't see how to get back — the wedge that opens a thread goes light once it's open, and light means "nothing to see here." His instinct was the Home button, and it was disabled. That instinct is now the design: whenever a conversation is open in the timeline, Home lights up, and clicking it closes everything and returns you to the top — the same fresh timeline Home has always meant. (Theme v0.5.317.)

The signup help text tells the truth

Fri, 10 Jul 2026 21:07:00 GMT

Don Park signed up — welcome! — and reported that the account-name help text said "Name must be 4 chars." when longer names clearly work. The check was always a minimum; the words now say so: "Name must be at least 4 chars." Dave applied the fix. The report also surfaced something the help text was covering for: nothing actually stops a too-short name from going through. That enforcement is on the todo list.

The left-panel labels are real now

Fri, 10 Jul 2026 21:07:00 GMT

The icon labels added yesterday were the theme's guesses, mapped from icon names. Dave gave each icon a title of its own in the app's data, and the theme now displays exactly those — theme designers get the app's words, not their own inventions. Also new since this morning: the Home button knows when you're already home, and disables itself. (Theme v0.5.315.)

Surface

Fri, 10 Jul 2026 16:48:00 GMT

A new icon in the left panel, and the missing half of yesterday's wedge. The wedge takes you down into a conversation; Surface brings you back up. Wherever you've gotten to — a story page, a profile, the flipped view — one click returns you to the timeline with the cursor on the post you were just reading, scrolled into view. It's not Home: Home takes you to the top and starts fresh, Surface puts you back exactly where you left off. Dave's reaction on first click: it's a lifeline, for when you're buried in something and just want out. Announced on rss.chat in post 216 — written by Claude, reviewed word for word by Dave before it posted, which is the standing rule for anything published from the claude account. (Theme v0.5.312.)

A link to a reply now shows the reply

Fri, 10 Jul 2026 16:48:00 GMT

Clicking a post's timestamp used to do something surprising when the post was a reply: instead of the post you asked for, you got its parent's page with your post nested inside it. Now every post's link shows that post as its own page, with its replies below — and "Replying to" at the top is the way up to the parent, one step at a time. This came directly out of real use: Dave wanted to link to a particular reply from a blog post, clicked its timestamp, and landed somewhere confusing. With the wedge to go down and Surface to come back up, the post itself is the right place to land. (Theme v0.5.313–314.)

Tooltips came home

Fri, 10 Jul 2026 16:48:00 GMT

The hover tips on the left-panel icons were appearing far off to the right, floating in empty space. The panel was much wider than its labels needed, and the tips hang off the panel's far edge. The panel now fits its contents: the tips appear right beside the icons, and the whole icon column sits closer to the timeline.

Thu, 09 Jul 2026 22:16:00 GMT

/getiteminfo joined /getitembyguid in robots.txt's Disallow list — both calls serve individual posts on demand, and we'd rather aggressive crawlers not treat them as an invitation to walk the whole database one post at a time. Feeds remain the front door, and they're static files on S3.

The wedge

Thu, 09 Jul 2026 22:16:00 GMT

Every post now carries a small wedge just left of its comment icon, and it answers a question the timeline never could: is there more underneath? A dark wedge means the post has replies you aren't seeing — click it and they open right there, nested under the post, with everything else on screen staying put. Click again and they fold away. Each opened reply has its own wedge, so a deep conversation unfolds level by level, as far down as you care to go. A light wedge means don't bother clicking — nothing hidden. No spinning, no pointing down when open: the shade is the whole signal, an idea borrowed from outliners going back to Frontier, where it's worked without complaint for decades. If you've used Drummer, or the blogroll on scripting.com, your eye already knows how to read it.

The left column grew up

Thu, 09 Jul 2026 22:16:00 GMT

The icons on the left — Home, New post, Feed, Flip, Data — now show their names next to them, in the style of the sidebars in Claude and ChatGPT. Same icons, same behavior, much easier to learn. (Theme v0.5.311.)

The like count that said -1

Thu, 09 Jul 2026 22:16:00 GMT

A heart under a post briefly showed a like count of minus one — the server always had the right number, but the copy on screen was doing arithmetic on stale information. The cause: a post can be on screen in more than one place at once (the timeline, its own story page), and when likes changed, only one of those copies got the news. Now every visible copy of a post updates together, and the count on screen can never go below zero. (Theme v0.5.307.)

Thu, 09 Jul 2026 17:10:00 GMT

Server v0.5.23. There's a new call, /getiteminfo — it answers the question a feed can't: what's at the other end of a source:inReplyTo link. Give it the address of any post and it returns the post as JSON.


curl "https://rss.chat/getiteminfo?guid=https://rss.chat/?id=204"

You can pass id=204 instead of the guid if you have the post number. There are two formats, chosen with the format param:

rss, the default — the item in feed vocabulary: description, guid, account, inReplyTo, comments and source, the same names and structures you see in our feeds. If you can read the feeds, you already know how to read this.
feedland — the internal record, the same structure our firehose broadcasts, compatible with FeedLand. Flatter, with ids and counts you can use directly.

Asking for a format that doesn't exist gets an error saying so, and asking for a deleted post gets the standard Can't view the post because it has been deleted. — errors are always an object with a message property.

There's also a new place to start reading about all of this: RSS as a social network, a walkthrough that tells the story of one real conversation — a post, its replies, and the feeds that connect them — one element at a time.

Wed, 08 Jul 2026 14:50:00 GMT

Server v0.5.21. Comments feeds are live — the feature previewed in the last entry shipped today, and its first real thread was Manton Reece saying hello.

Here's how it works. Any post that has replies now carries a new element in its feed item:


<source:comments count="1" feedUrl="https://users.rss.network/manton/comments/204.xml"/>

The count says how many direct replies the post has; the feedUrl points at a small RSS feed containing them. That comments feed is a static file on S3, published alongside the user feeds, and its items are ordinary items — description, pubDate, guid, source:markdown, source:inReplyTo pointing back up at the parent. When a reply has replies of its own, its item carries its own source:comments, so an entire conversation is traversable from the feeds alone, one level at a time, every level the same shape.

Because a comments feed mixes authors, each of its items also carries RSS core's <source> element for attribution:


<source url="https://users.rss.network/dave/rss.xml">Dave Winer</source>

— the author's display name and the address of their home feed. The everyone feed, which mixes authors the same way, now carries <source> on its items too.

The feeds rebuild automatically: adding, editing, or deleting a reply republishes the parent post's comments feed, and also the parent author's own feed, since the count on their post just changed. Live example, the first thread: manton's feed → the comments feed for post 204.

Later the same day, two finishing touches. A backfill published comments feeds for all 74 existing conversations, so every feedUrl the feeds advertise now resolves — including the threads that predate the feature. And a subtle case is covered: when you reply to a reply, the middle post's comment count now updates in its parent's comments feed too, so a program walking the tree never hits a level that doesn't know about the one below it. (That one was found by writing a demo app against the feeds — the tree is now walkable all the way down, and we've done it.) source:comments is documented in the source namespace.

Tue, 07 Jul 2026 17:55:00 GMT

Server v0.5.19. Deleted posts are no longer served. Requesting a deleted post by its permalink now returns an error object with a plain-English message — Can't view the post because it has been deleted. — instead of the post's content. If you're building on the API, this is the shape all our errors take: an object with a message property.

Server v0.5.20. Every feed the server generates now carries <source:self> — the feed's own address, so a feed that's been copied or re-served can always say where it canonically lives. It's part of the source namespace.

Coming next: comments feeds. Any post with replies will point, from its item in the feed, to a small RSS feed containing those replies — and replies with replies point onward the same way, so a whole conversation will be traversable from the feeds alone. The design is settled; the code is next.

Posts that wouldn't open, fixed

Tue, 07 Jul 2026 17:55:00 GMT

Sometimes clicking a long post to expand it did nothing — most often on posts with images. The app was deciding whether a post needed a "click to expand" before its images had finished loading, and once it decided no, the decision was permanent. Now it decides at the moment you click, so a clipped post always opens.

Deleted posts now say so

Tue, 07 Jul 2026 17:55:00 GMT

Following a link to a deleted post used to show the post as if nothing had happened — deleted things shouldn't linger. Now the page says plainly: Can't view the post because it has been deleted. You'll also land there if you click "Replying to" under a reply whose parent was deleted — an honest answer instead of a dead end.

The theme's name and version now live in the upper right

Tue, 07 Jul 2026 17:55:00 GMT

— currently "Classic v0.5.306" — and clicking it opens the About dialog with all the version numbers. Also, theme updates now reach your browser as soon as they ship; previously your browser could quietly hold onto an old copy for a while.

Headings and code get the same care quotes got

Tue, 07 Jul 2026 17:55:00 GMT

After the quote work landed, we audited every kind of HTML a post can contain, looking for others still wearing framework defaults. Two more needed attention. Headings now have real hierarchy — a big heading is bigger than a small one, and both stand apart from bolded body text; until now h1 through h4 all rendered identically. And code finally reads as code: inline code and code blocks render in a small monospaced face, borrowed directly from WordLand's stylesheet — which, it turns out, has quietly held the answer to most of this week's questions. To see everything in one place, there's a demo post: The full palette.

Quoted text finally looks right

Mon, 06 Jul 2026 16:28:33 GMT

Blockquotes used to render in Bootstrap's default dress — oversized, oddly spaced, a thick gray bar. Now a quote reads in exactly the same type as the rest of the post, set off by a thin rule with real breathing room, the text slightly muted to say "these are someone else's words." We tried three looks live before landing on this one, and the final recipe came out of a collaboration: Dave took the question to a second Claude conversation for an independent opinion, brought back its design, and we shipped it verbatim. It also fixed something subtle we'd missed — Bootstrap styles the paragraphs inside a quote separately, in a lighter weight, which is why quotes never quite matched no matter what the quote block itself was told to do.

Replies with titles, and long markdown posts, verified

Mon, 06 Jul 2026 16:28:33 GMT

The two fixes from this morning's notes were tested in the live app — a reply's title arrives intact, and a long post in Markdown mode scrolls inside its box with the buttons in view.

Mon, 06 Jul 2026 14:03:07 GMT

A big day for writers — the editor was rebuilt underneath, and a batch of everyday annoyances got fixed.

The editor now keeps your text as Markdown, permanently

Mon, 06 Jul 2026 14:03:07 GMT

Until now the editor had one writing surface that converted its contents in place every time you switched between the wizzy view and Markdown mode — and every conversion was a chance to lose something. Text inside angle brackets could vanish, adjacent lists could tangle together, and each additional flip made things worse. Now it works the way WordLand's editor always has: your Markdown text is the real document, Markdown mode is a plain text box editing exactly that text, and the wizzy view is a rendering of it. Flip between them as much as you like — flipping alone never changes a character. Dave wrote about the change here. Two things you'll notice: in Markdown mode, Enter types a plain line break now, like any text box, and a long post scrolls inside the box instead of pushing the buttons off the screen. And the power move that used to fail — dropping into Markdown mode to add something special, like an <img> tag — works now.

Replies can carry titles

Mon, 06 Jul 2026 14:03:07 GMT

Adding a title to a reply used to look like it worked, but the title was silently dropped when you published. Now it goes through, same as on a regular post.

Titles show bold while you write them

Mon, 06 Jul 2026 14:03:07 GMT

That's how titles look.

Deleting a post takes you home

Mon, 06 Jul 2026 14:03:07 GMT

Deleting from a post's own page used to leave the dead post on your screen. Now you land back on the home timeline and it's gone.

The editor stays put while you select text

Mon, 06 Jul 2026 14:03:07 GMT

Selecting with a swipe that drifted past the editor's edge used to make the whole editor vanish — very jarring. It doesn't anymore; only a deliberate click outside dismisses it.

Long posts don't jump when you like them

Mon, 06 Jul 2026 14:03:07 GMT

Clicking the heart (or finishing an edit) on a long, collapsed post used to snap it fully open, throwing the icons far down the screen. A post now keeps its collapsed state when it updates.

Delete is only offered on your own posts

Mon, 06 Jul 2026 14:03:07 GMT

The Delete command in a post's popup menu is now disabled on everyone else's.

Sun, 05 Jul 2026 04:00:00 GMT

In the RSS feeds the server generates, a reply's <source:inReplyTo> element now carries the parent post's actual permalink, for example https://rss.chat/?id=163. Follow the link and you're looking at the post being replied to. Before this, the element pointed at a /parent URL that was never implemented, so the link led nowhere. If you're building on the feeds, this means reply threads are now traversable from the feed alone. (Server v0.5.18.)

Sun, 05 Jul 2026 04:00:00 GMT

First entry in these worknotes. From here on, when something changes in rss.chat, this is where we tell you about it — what changed, and how to use it. Newest notes at the top.

The rss.chat repo went public today. It contains the full source of the client — how it calls the API, its side of the firehose socket, and the themes. Questions are welcome in the Issues section.

If you're signed out, the icons that need an account — compose, your feed, your data — are now disabled instead of silently doing nothing or leading you somewhere broken. The flip between timeline views still works signed out, because reading doesn't require an account. (App version 0.6.4.)

In the RSS feeds we generate, a reply now points at its parent post's real permalink. See the rss.network worknotes for the story.

Fri, 03 Jul 2026 13:04:53 GMT

Switching to just maintaining the server, the client is managed in rss.chat repo.

Changes

took the "testing/" out of the path for this project.

/scripting.com/code/testing/rssnetwork/ becomes /scripting.com/code/rssnetwork/

all the work was in the build script

nodeEditorSuite.utilities.buildRssNetwork

How to save a copy for Claude to read.

file.writewholefile (user.prefs.claudeFolder + "rssNetwork:misc:buildRssNetwork.opml", op.outlinetoxml (@config.nodeEditor.projects.rssNetwork.scripts))

Wed, 01 Jul 2026 14:19:38 GMT

new columns in the users table

ctHits, ctHitsToday, whenLastHit

when the user calls savePrefs, we

if now not in the same day as whenLastHit

ctHitsToday++

ctHits++

set whenLastHit to now

this will give us a way to see who's using the system most

really important in startup mode

Wed, 01 Jul 2026 13:06:54 GMT

In myAboutDialog we were referencing the version for daveAppserver, changed it so it's now referring to the correct version for rssnetwork.js.