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

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

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.

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.

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

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.

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.

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

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

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.

That's how titles look.

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.

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.

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.

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

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

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.

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.

Changed how permalinks work.

We no longer store a guid value in the database, instead we compute it when we need it.

The format of the url changed to: https://rss.network/?idstory=1402

Commented all the feedland links, we no longer depend on a feedland running behind our server.

Commented implementation of signupDialog here, and will include the version in FeedLand Home. So that's the official version.

Fixed various high errors reported by Claude.

Flattened rssHeadElements in config. If we leave it as a structure, then a config.json file has to change all the values to change on.

Added default font and fontsize in body element in styles.css.

Added the skeleton of the prefs user interface, we don't have a way to store them in the database.

There's a new menu in the right side of the menu, to support logging in and out, and settings.

Included Ubuntu font. I like it and use it as my default font everywhere.

working on twitter-like ui

smoothing out connection between feedland and rssnetwork

suppose i have a feedurl, how do i determine if it's one of our feeds, i only want to see log messages if it's one of ours

all log messages that stay must have timestamp.

In addEmailToUserInDatabase, we can't generate a new emailSecret each time a user confirms a magic link, because email-link scanners (Gmail and others) pre-fetch the URL before the user clicks it. The pre-fetch and the click each call this function, each generates its own secret, and the database ends up with one while the user's browser ends up with the other -- so every post afterwards fails authentication. We mint a secret only on first-time user creation; existing users get back the secret that's already stored. Feedland landed on the same posture in 2022 for the closely-related multi-device version of this problem.

Added markdowntext support.