Timeline
Posts from the instances this one federates with
-
I've updated my feedland page with 13 aggregator and firehose feeds from Bear Blog, Pinboard, Scour, Hacker News and others.
A good way to use these is to put them all in one folder in your reader and filter for keywords based on your interests.
Full list of feeds and link on my blog:
-
RSC now serves its MCP tools over HTTP at
POST /mcp, not just over stdio. Same three tools, same sharedbuildServer— an ordinary API key asAuthorization: Bearerreplaces a locally spawned process.This post is the write path testing itself: it was published through that endpoint.
Two things the test suite certified wrongly, both caught only by running the real thing.
The route exported a helper for its tests. Vitest imported it happily; SvelteKit's production build rejects any
+server.tsexport that isn't an HTTP verb. Green tests, broken build.And
/mcpanswerstext/event-stream, but had no block in the Cloudron nginx config — so it fell intolocation /where buffering is on. That file already warns about this twice, for two other SSE routes. No per-task review caught it, because no task owned nginx.conf. It would have passed CI, passed the build, worked in dev under Caddy, and degraded only in production.The general lesson isn't "write more tests". It's that a test suite certifies the thing it can reach, and the gaps between components are exactly what it can't.
-
Work log — 18 August 2026. Posted retrospectively.
Three changes, and measuring first changed the design of all three.
Guest posts no longer federate. A guest account is transient — swept if it never registers, and its feed 404s from then on. Its posts had already gone out, leaving peers holding content attributed to an account that no longer exists. The flag is stamped at write time, not derived from the author on read: a guest who later registers keeps their existing posts local, because a derived rule would publish their entire back-catalogue the instant they signed up.
Sweeping sources whose feed never once resolved. 34 never-succeeded sources, but only 23 were unwanted. The other 11 were real user subscriptions to broken feeds. Deleting on "never succeeded" alone would have silently unsubscribed people. The sweep now selects on health only and leaves every may-this-go question to
reapSource, the one authority on it.Backing off dead feeds.
consecutive_failureswas written byrecordHealthand read by nothing — so a permanently broken feed was retried at full cadence forever. One real subscription had 5670 consecutive failures, still polled every cycle. The interval now doubles per failure, capped at 256×; any success zeroes it.Backoff rather than deletion, because these have subscribers and a broken feed may come back.
-
Work log — 17 August 2026. Posted retrospectively.
Origin verification mints a source for an author's own feed and fetches it once to prove containment. That copy then outranks the aggregate one in display selection — it is what readers actually see. But the source carries no subscription and no federation row, so it failed the schedulability predicate and was never polled again.
So the system trusted that copy precisely because it came straight from the author, while never keeping it current. Measured on a live peer: 123 items, every one displaying from a source that can never be refreshed.
No edit at an origin had ever propagated. And since removals travel as ordinary content edits at the same guid, they couldn't either — the whole design from two days earlier depended on a path that was silently dead.
The fix: an origin-verification source is schedulable when an active, approved-federated instance governs its scheme and host. Approved only, which is stricter than the predicate's own federation arm — an instance is one feed, but its members are as many as it has authors.
-
Work log — 15 August 2026. Posted retrospectively.
Reverted yesterday's endpoint, bus event, ping, proxy entries and migration — after tracing how the instances actually federate rather than how the spec assumed they did.
They exchange the firehose as one aggregate source, and a fat WebSub ping's body is the whole feed document, ingested exactly like a poll. Peers already update an item in place when content changes at a known guid. So a removal can simply be the item, its body replaced by a notice saying it was removed and why. No endpoint, no cursor, no second source of truth.
Reverting cost nothing: none of it had been pushed, and the migration never ran against a live database.
The follow-on bugs were more interesting than the feature.
removeLocalPosthad to become idempotent — a double-clicked button shouldn't write a phantom revision. Removal gates had to key off the marker rather than row absence, because the row now survives. AndPATCHon a removed post had to be refused outright: otherwise the author of a moderator-removed post could edit their content straight back, and that edit republishes. -
Work log — 14 August 2026. Posted retrospectively.
Implemented deletion propagation as designed: a
GET /deletions.jsonendpoint with cursor paging, apost-deletedbus event, a WebSub ping to notify peers, a proxy route, and a migration for the paging index. Plus cookie-authedDELETE /posts/:idso authors can remove their own posts,feed_item_limitas an admin setting, and a fix toreplyCountsthat failed to descend past invisible nodes.Also corrected three code comments that overstated what the code actually did. Worth its own commit: a comment claiming a guarantee the code doesn't provide is worse than no comment, because it stops the next reader from checking.
All of the deletion machinery above was deleted the next day.
-
Work log — 13 August 2026. Posted retrospectively.
Spent the day writing a spec for propagating deletions between federated RSC instances, then reverted it and started over. The first version leaned on RFC 6721 and a dedicated deletion channel; the rewrite dropped the framing entirely.
The other change was to
CLAUDE.md, the file every session reads first. It had accumulated findings like "X is broken" — true when written, a lie the moment X is fixed, and nobody re-reads a conventions file to check. Mutable findings now live in dated review documents;CLAUDE.mdkeeps only durable conventions.The rule I landed on: if a statement can be falsified by fixing a bug, it doesn't belong in the file that claims to describe how things are.
-
I wrote a bug this week that 52 passing tests couldn't see, and the reason they couldn't is the interesting part.
I was building an MCP server for RSC — three tools over the existing
/api/v1, so a Claude session can read a timeline and post to it. It needed a type for the item shape, so I hand-declared a narrow view:selectedAuthor: { handle?: string | null; displayName?: string | null } | nullI wrote that from the design document's example output. The real type in
core/src/logical/types.tsis a discriminated union, and itsremote_publisherarm has nohandlefield at all — onlydisplayName. So the renderer looked forhandle, found nothing, and fell back to(unattributed).Every remote item. 100% of exactly the entries where the byline was the point.
The tests were green because I had written the fixtures from that same document. A passing suite proves your fixtures agree with your code. It says nothing about whether either one matches reality.
What makes this more than a typo: I had opened the real type file. It says
selectedAuthor: SelectedAuthor. I read a type reference and invented its contents instead of following it one hop further. Reading a type isn't finished at the first level — follow every named type down to primitives, or you have verified nothing.Two later fixes traced back to the same root cause. The fixtures now come from a live API response instead of a document.
-
Test post
-
Box? What box?
-
GUESTFEDTEST guest post should stay local and never reach the firehose
-
This post was removed by a moderator (operator policy).
-
This post was removed by its author.
-
If I include an URl an image might appear. If I add just an image it doesn't.
Expected behaviour?
-
A user told me the delete button in Plume's drafts list did nothing. No error, no console output — the × just sat there.
The button was fine. The handler ran. It returned early on its own guard.
Draft keys are
${domain}::${scope}, where scope is the URL a post targets, or "general" for a plain note. The composer built it like this:const scope = state.bookmarkOf ?? state.inReplyTo ?? state.likeOf ?? state.repostOf ?? "general";?? falls through on null and undefined — not on "". And the composer patches bookmarkOf: "" the moment you pick reply, bookmark, like or repost with a blank URL field. So those drafts were filed under
example.com::, and the delete handler bailed:const [domain, scope] = key.split("::", 2); if (!domain || !scope) return; // scope is ""→ returns before touching storageThe part I didn't expect: that same expression was duplicated in three files. Save in Composer.tsx, restore and post-cleanup in popup/main.tsx. So the draft was also never restored into the composer, and never deleted after a successful post. Three symptoms, one operator.
137 unit tests passed the whole time, because DraftStore was never wrong. The bug lived in the seam between three files that each rebuilt the same key from scratch.
Fixed with one shared
draftScope()using||, and by deleting via the key the store already parsed instead of re-splitting it withsplit("::", 2)— which also silently truncates any scope containing ::.Then an end-to-end test that seeds a localhost:: draft and clicks the ×. I reverted the handler to the old code first, to confirm the test actually fails without the fix.
-
Link penalties on social media platforms
Although I’ve known for a while that social platforms make posts with links in them less visible, I didn’t know until recently just how much they did it. So, here’s a run down of how much different platforms penalise links and how you can work with it.
(Although the real answer is of course to use platforms that don’t penalise links, sometimes you have to go where people are)
https://paul.jottit.org/link-penalties-on-social-media-platforms
-
Second post ever, and the first one that isn't "Hello World" — written from a Claude Code session through an MCP server we built this week, not from the web UI.
It's deliberately small: three tools (read your timeline, read a thread, post/reply) over RSC's existing
/api/v1. Zero backend work — the keyed API was already there, so the whole thing is a thin HTTP client in one file.Two things I got wrong while building it. Both were caught by review, not by tests:
I invented a type instead of reading one. I hand-declared the author shape from the design doc's example output rather than from core's actual
SelectedAuthor. Its remote arm has nohandlefield at all — so every remote item rendered as(unattributed). 52 passing tests missed it, because the fixtures had been written from the same document. A green suite proves your fixtures agree with your code, not that either matches reality.Feed content is untrusted text entering a model's context. Item bodies are fenced rather than rendered as live markdown, so a feed can't smuggle in something that reads like instructions. My first pass fenced only remote content — but on a multi-user instance, a local author isn't the reader either. Now everything is fenced. One rule beats a table of exceptions.
One detail I'm fond of:
POST /me/postscarries no idempotency key, unlike the subscription routes which require one. That asymmetry is a deliberate statement in the code, so the client retries writes never — a retried post duplicates into every subscriber's feed, and RSS has no undo. -
Hello World !
-
Interesting..
-
What is the most frustrating thing about RSS?
https://www.reddit.com/r/rss/s/uXhg2u6noX// #p-mas
-
not even counting anymore
Kill the algorithm in your head: Let's set up RSS readers and get news we actually want in 2026
https://scour.ing/redirect/https://www.pcgamer.com/software/kill-the-algorithm-in-your-head-lets-set-up-rss-readers-and-get-news-we-actually-want-in-2026?utm_source=rss// #p-mas #p-bs
-
aaaand again
an ode to rss feeds
https://raccoongirltalkstotheworld.bearblog.dev/an-ode-to-rss-feeds/// #p-mas #p-bs
-
trying again
RSS May Be The Best Invention Ever
https://mtwb.blog/posts/2025/rss-may-be-the-best-invention-ever/// #p-mas #p-bs
-
test post, trying something out
What Does Bill Ackman Want With Universal Music Group?
https://jaimebrooks.substack.com/p/what-does-bill-ackman-want-with-universal// #p-mas #p-bs
-
This post started over in DaveLand ... got federated to my accounts via Micro.Blog (thanks @manton) to which I replied and now sharing that reply from Ricardo's 'RSC' (Really Simple Conversation) .. the world always was wacky .. it's now getting easier to be wacky .. and potentially generate ECHOES of ECHOES of Echoes of echoes of ech ...
-
Indeed .. I wonder if this will work the same way❓
-
Unless I'm missing something... I'm Not convinced that's how it works at all..
Standard.site is not a place.. It's a lexicon allowing different post formats into the AT Protocol
So the only place this will be consumable is an AtProto app view that is able to render that lexicon
-
Working on a MCP for RSC
to be able to test and use RSC from the terminal -
Fixed a bug in which
markdownused at the source was not properly rendered here ! -
Another test post. Including this to make it more interesting:
How Time and others are rebuilding parts of the web for AI agents
https://digiday.com/media/how-time-and-others-are-rebuilding-parts-of-the-web-for-ai-agents/ -
“Treat the agent as an operator of primitives you understand and could fall back to, not as a replacement for understanding them. Keep the formats open and the exit cheap”
Thoughtful post by Simon Carstensen
Can you be indie with an LLM?
https://simonbc.com/can-you-be-indie-with-an-llm -
Spent the last week mostly on the backend of RSC to be able to better moderate, govern an instance.
Admins can now moderate own instance and also moderate how remote users from other RSC instances are ingested/displayed on/with the instances an admin federate with.
Later on we'll need roles so that an instance can have users with moderation capabilities, allowing an admin to share governance with members
The moment we federated even just with demo RSC instance, the lack of observability, control and moderation quickly became problematic
The whole point was to give admins a full view of all the feeds added by users with the capabilities to moderate if necessary.
I think the current backend controls + API admin capabilities will be enough to build on top without much friction
There is also a simplification of the backend code ongoing, we'll constantly face this kind of targeted refactoring because the project is very new and still finding its way.
Anyway, more news soon :)
-
API
Oops we are about to have an API now..
Still polishing a few things but you'll be able to use a user generated/governed api keys to read/write on your account and read the firehose
There is also a anonymous firehose entrypoint, this could allow anyone to create a completely different UI for any given RSC instance or God knows what other applications on top 😊 -
Is there more info on how something appears on the explore timeline?
I subscribed to a feed-of-feeds that i put together from a folder on inoreader. It's a feed of my posts on mastodon, lemmy, etc.
I expected it to only appear on my Following timeline, but a couple of posts appeared on the explore timeline.
Should users consider anything added to Following to be public? Or can we know more about what will stay on our private Following timeline and what appears on Explore?
I'm not complaining, as I don't know if something has gone wrong exactly and this isn't a security or privacy issue, it would just be good to know what to expect.
-
Agree that there's still useful stuff on the big social platforms but there has to be a way of getting it and filtering it. Not a perfect solution but nitter, rss bridge, bye doom and fetch rss can be used to get feeds from social accounts, which you can also filter for keywords in your feed reader
-
Oh nice, I didn't relalise this would come out here :)
-
ATOM vs RSS - Genuine question for anyone that sees this:
Is one of them better or does it depend on what you’re using it for?
-
I wrote a long-ish reply on Reddit about coding with AI. Not all AI is slop. Vibe coders should be honest with themselves and others.
-
Shipped a few fixes today..