- celld support - This is to allow standalone deployment to any host, including Digital Ocean droplet with cloud_init. Turns out D1 support is not yet available in celld so deferred.
- CF temporary account support - This is to allow user to launch their own instance under a temporary Cloudflare account which they could claim and use directly. Turns out R2 is not supported in temporary accounts which leaves two viable paths:
I'm leaning toward the most obvious yet robust path for now: add skills for agents to deploy and manage on-behalf of user.
PS: `rewrite` changes has been merged into `main` branch. It's a complete rewrite. UI appearance hasn't changed much except for addition of message thread view.
I don't know about wpIdentity but rss.voice uses D1 which is a SQLite database. You can see how it's used in this file. Just find "env.DB.prepare" calls.
https://github.com/donpark/rss.voice/blob/main/apps/server/src/index.ts
I did a full rewrite from scratch Sunday to run on Cloudflare or standalone using celld.
The rewrite branch and screenshot of the its current state at:
https://github.com/donpark/rss.voice/tree/rewrite
Aside from fullter testing and pen-testing on Cloudflare and celld, a key feature I'm planning to add next weekend is ability to spawn new instances using Cloudflare's temporary account creation support.
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
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.
@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.
Nevermind. Looks like I hallucinated.
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?
Some tuning will be needed eventually but I'm fine with it for now.
Just making a note of the behavior.
Yes. We literally have ghosts in our machines now.
They're like Pokeymons in the sky, all waiting to be beckoned into existance.
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.
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?
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.
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.
Working on it. As usual, I got too many ongoing projects like a forgetful gopher.
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?
I’ve been thinking about how [rss.chat](http://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.
Good. #2 is the behavior I'm seeing now and I can't seem to reproduce hoisting.
@dave, is there a description of the heuristics rss.chat uses to display Replies?
AFAICT it's:
Is above accurate?
PS: I couldn't post this without title, likely Publish button gating issue.
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.
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.
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.
@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.
latest on bside (still cooking, not in the new cooking sense):
Just signed up.
@dave Help text for account name say "Name must be 4 chars." which is clearly false.
