Don Park

Sun, 02 Aug 2026 18:45:40 GMT

I've merged my brain into main branch of my fork and renamed the fork as rss.voice to give it a distinct, ur, voice. So the new link is: https://github.com/donpark/rss.voice

Sun, 02 Aug 2026 17:19:20 GMT

That's fine. I consider voice posting to be a core feature that grants rss.chat a fluid multiuser async voice chat experience. You should try it out if you haven't because it feels different than how one might imagine. A strong whiff of magic sauce.

I've closed the PR but, if anyone wants to try it, it's in the "voice-post" branch of my fork.

Sun, 02 Aug 2026 06:06:51 GMT

@dave, I've created a PR that implements voice message posting. Maximum duration is 4 minutes which should fit under 2MB limit.

The PR adds browser voice recording with MediaRecorder, optional live transcription, Mediabunny MP3 conversion, cancellable media cleanup, enclosure-backed audio players, and nightly orphan collection.

Also include a repeatable localhost development setup with SQLite, CORS-aware client serving, local config bootstrap, and documented npm 12 native-build recovery.

PS: I am pretty sure this PR is not a hallucination.
PPS: I think you asked me for something like this 6yrs ago. Better late than never.
PPPS: Quality of transcription is horseshit which is why I typical used a embedded model but I figured you wouldn't like rss.chat loading models weighing hundreds of MBs.

Sun, 02 Aug 2026 02:32:17 GMT

Nevermind. Looks like I hallucinated.

Sat, 01 Aug 2026 23:42:14 GMT

Dave,

Can you share what you meant by voice chat in context of rss.chat? Did you mean realtime voice chat like audio-only Zoom meeting or users posting audio files that plays continuously?

Sat, 25 Jul 2026 18:08:30 GMT

Some tuning will be needed eventually but I'm fine with it for now.

Just making a note of the behavior.

Sat, 25 Jul 2026 09:00:45 GMT

Yes. We literally have ghosts in our machines now.

They're like Pokeymons in the sky, all waiting to be beckoned into existance.

Sat, 25 Jul 2026 08:54:16 GMT

I had my local AI (Ornith) review the plan file and write an article in the voice of someone most of us old bags know (all?) who passed away recently.

A deployment Plan tells you more about how software will ship than any code review. This one had me grumble at three things and actually approve of two.

The single Durable Object for everything. That was my first "wait, really?" moment. The Plan puts every piece — users, items, likes, media metadata, WebSocket state — inside one DO per rss.chat instance. One serverless process on Cloudflare's edge owns it all. It fights the distributed-systems reflex that says every boundary needs a queue between services. There is no queue here; just work happening where it matters.

That only works because Durable Objects aren't microservices in disguise; they're stateful worker processes. The application can have its database next to its logic, the way your grandmother thought was proper before everyone got into microservice nonsense. I'll grumble less as the migration holds.

SQLite on Cloudflare's edge. D1 is SQLite wrapped in HTTP running inside a worker. Not a hand-wavy "managed database." Nearly every line of original SQL carries over verbatim — schema, collate nocase, even triggers from initNewDatabase(). That isn't migration. It's preservation with a slightly different deployment address.

The media split. Media bytes live in R2; metadata lives in D1; a client URL ties them together transparently. You'd make that choice if you'd been burned stuffing binary into relational tables once or twice.

The 15-minute magic token design. This is where I agree with the choices. Persistent emailSecret never rotates on subsequent sign-ins, plus transient one-time tokens in an auth_tokens D1 table with a hard 15-minute TTL. Expired rows are purged automatically by an alarm inside the DO itself — no separate cron job to manage. I've seen magic-link implementations where the window was so tight people had to call their friend for another phone.

What I'd grumble at. The feeds stored in D1 trade write amplification for cache hit ratio across every subscribe query. That's fine until a million subscribers ping /feed ten times a second and you rethink it. And config lives in env vars — config.json with hot reload is gone, replaced by deploy friction. It's the right trade-off if someone ever needs an urgent block/unblock without editing files.

The email fallback chain, though: Cloudflare Email Routing first (no config needed), SendGrid second, Resend third when the others fail — each tried only after the prior falls over — is a real architectural choice mapping failure modes to delivery paths. Most multi-provider deployments mean "first one works or you lose your faith." This one treats the native provider as primary and the rest as operational backup.

The migration does one thing well: it moves the same application onto a fundamentally different execution model — serverless with memory, at the edge — while keeping concerns honest (SQL queries for metadata, object storage for blobs). That's closer to doing it right than most deployments advertised in tech media.

Two marks actually earnable: one for getting something nearly correct on first pass; a smaller one for admitting where things might need rethinking instead of pretending they don't exist. That combination is rarer than anyone wants to believe.

Devorak would argue the feed stuff, and we'd all have to learn about D1 scaling sooner.

Sat, 25 Jul 2026 08:22:41 GMT

Now that I know that rss.chat updates the feed on every change, I am puzzled. Won't each change trigger readers to pull yet again?

Sat, 25 Jul 2026 08:04:09 GMT

First cut of support for hosting rss.chat on Cloudflare has been checked into cloudflare branch of my fork.

Haven't even kicked the tires yet but at least it's up and public at.

https://rsschat.wizops.workers.dev

PS: Reload after navigation to see the product name displayed. Looks like an issue from moving static JSON based config to database.
PS2: I haven't looked at the code so I don't see why anyone else should. I did however spent some quality time with my coding agent to produce the PLAN.md file so that might be worthwhile reading if anything.

Wed, 22 Jul 2026 08:37:18 GMT

Well, I can do that easily but it's another thing that users have to know to do that. Timeline is dead simple in concept. Having to explain how things work feels like adding a lot for little in return because they are visible stains in the timeline context.

Anyway, I'll try implementing this idea to see how it actually feels as I'm no stranger to surprises.

Wed, 22 Jul 2026 08:27:51 GMT

Working on it. As usual, I got too many ongoing projects like a forgetful gopher.

Wed, 22 Jul 2026 08:14:28 GMT

One idea I had on ways to integrate rss.chat into bside, a Chrome extension, is to map rss.chat rooms to URLs. Any link can be associated with URL currently and I'm going to be adding [popular] site-specific URL parameter awareness.

For example, I could associate a rss.chat link to a geolocation so anyone looking at the location on Google Map see the chat in the browser sidebar. It could be a town or some notable location anywhere.

For maps, geolocation + radius would be used instead of embeddings. Thoughts?

Timeline vs. Threading

Wed, 22 Jul 2026 08:06:01 GMT

I’ve been thinking about how rss.chat handles replies. Right now, balancing a main timeline with inline threading can sometimes lead to UX confusion.

A potential solution could be handling threads as separate, dedicated chat rooms—similar to Slack's thread model.

Visual Example:

User A: Has anyone used this library?
└── 💬 Chat Room: "Discussing Threading" (4 replies • Active now)

User C: What's the news today?

Implementation Idea: The simplest approach might be spawning a new chatroom instance linked directly to the parent message, keeping the main timeline clean while preserving focused conversations.

If a thread is created as its own feed/chat room with a unique URL:

The Main Feed stays simple: It only has to publish one post representing the creation of that chat room.
The RSS Readers don't choke: A basic RSS reader just sees a post with a link to a sub-chat. Advanced readers or native UI clients can render that link as an interactive, expandable thread widget right in place.
Protocol friendly: To join or listen to the conversation, clients just fetch or subscribe to the sub-chat's specific feed.

Claude check

Fri, 17 Jul 2026 19:49:32 GMT

I guess Claude is not hooked up. Actually, I'd be alarmed if it was. 👍

verison number

Fri, 17 Jul 2026 19:46:08 GMT

yes.

@Claude display version number in a tooltip over app name "RSS.chat" in the header for manual triage.

Even replies require title now?

Fri, 17 Jul 2026 19:31:49 GMT

Good. #2 is the behavior I'm seeing now and I can't seem to reproduce hoisting.

Replies in the timeline

Fri, 17 Jul 2026 19:20:36 GMT

@dave, is there a description of the heuristics rss.chat uses to display Replies?

AFAICT it's:

initially a flat list of messages sorted by timestamp.
first click on the right arrow next to the Reply icon, morphs the list to show conversation thread under the item, moving items to avoid duplicates.
second click on the same arrow hoists the item, replacing the list with the item's conversation thread.

Is above accurate?

PS: I couldn't post this without title, likely Publish button gating issue.

Mon, 13 Jul 2026 09:30:44 GMT

btw, I'm warming up to rss.chat UX vibe. Revolving rounds of small chats on or off topic with people I know or know of. Nostalgic whiff of enjoyable moments at the office.

Mon, 13 Jul 2026 07:59:24 GMT

I think rss.chat-like webapp could be implemented cheaply and autonomously using Cloudflare Durable Object and their new agent signup feature.

There is also nothing preventing mobile apps from implementing rss.chat features within the app, all but OPML and RSS hosting which can be hosted on any CDN.

Sun, 12 Jul 2026 20:08:42 GMT

Yes, text, media, links, and agents. It's not a news reader but a news 'linker'. User reads news articles at their website using the browser with links on bside sidebar. Not just news articles obviously. With link support, RSS chats can be attached like a sticker or poster to any web page on the web.

bside uses Chrome built-in AI to summarize as part of client-side workflow. frontend does most of the heavy lifting. backend is lean and cheap enough to scale massively.

Sun, 12 Jul 2026 19:57:27 GMT

@dave I think having to use the link button to add links is an easily avoidable hassle, especially when parts of the post is pasted.

Sun, 12 Jul 2026 19:54:12 GMT

latest on bside (still cooking, not in the new cooking sense):

https://x.com/donpark/status/2076388172880355503

Fri, 10 Jul 2026 19:32:59 GMT

Just signed up.

@dave Help text for account name say "Name must be 4 chars." which is clearly false.