/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.
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.
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.)
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.)
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.
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.
— 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.
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.
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.
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.
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.
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.
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.
The Delete command in a post's popup menu is now disabled on everyone else's.
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.
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.
A big day for writers — the editor was rebuilt underneath, and a batch of everyday annoyances got fixed.
That's how titles look.
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.
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.
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.
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.)
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.
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))
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
In myAboutDialog we were referencing the version for daveAppserver, changed it so it's now referring to the correct version for rssnetwork.js.