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

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.

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.

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.

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.

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!

The RSS.chat team

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.

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

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.

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

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.

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.

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

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.

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

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.

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.

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

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.

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

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.

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.

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.

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: ca...

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

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.

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

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:

1. Get the new rssnetwork.js and package.json from the repo.

2. In your server's folder, run npm install. The updated package.json adds one package -- the cleaner -- and this brings it in.

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

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, /m...