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

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.

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.

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

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

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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

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

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.

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.

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

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

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.

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

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

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

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.

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

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.