Nice !
loving the openness and the vision !
that was the case for him and me, until I cleared my browser cache. now its working neat
Clear your cache, I did so and I can reply without title or add new posts without title..
Test new post after cache clear in the browser.
Hmm this is odd..but after clearing my cache I'm able to reply without adding a title
from what I can tell from the client code :
1. ✅ Flat list of all posts, replies included, sorted by timestamp. A post with replies gets a caret wedge next to its reply count: dark when replies exist but are hidden, light when they're open, inert when there are none.
2. ✅ First click on the wedge (toggleReplies) fetches one level of replies and nests them under the post. If a reply was already on screen as its own timeline row, that row is folded away so nothing shows twice — that's the "moving items to avoid duplicates" you noticed. Each nested reply carries its own wedge, so you walk deeper one click at a time.
3. ⚠️ A second click on the same wedge doesn't hoist — it collapses (closeReplies) and restores the folded rows. Hoisting is a different control: the Hoist icon in the left bar, which acts on the selected post and replaces the timeline with that post as a temporary root showing its whole reply tree (Dehoist backs out). The code tags this #104, MORE/Drummer lineage.
So: wedge = expand/collapse in place; Hoist icon = swap the whole view to one thread.
Doubt you can move Bluesky out of its current track, the direction they seem to take is to expand their lexicon to all kinds of usage (blogs, instagram clones, livestreaming, even federated code repositories etc) this link gives an overview of the current diversity being built in the open ecosystem
overview of shared data types here :
https://atstore.fyi/apps/lexicons
But that being said, the community is very open, its easy to build uppon and even to diverge from the current protocol akin to what https://standard.site is doing
You guys know about /init command for claude right ? usually you do this in our own repo, claude will fabricate a claude.md mostly for him, even tho you, as a human, can obviously drive what's in it, this is where you can specify some preferences too and if you commit it to the repo, then your contributors also get to work under the same paradigm with their claude
there you can have a docker or deploy section, where you define how the code should be run either node native way or docker based approach, once everything is in place, you can have custom /commands to actually deploy your code the way you want and claude will follow the exact instruction, you can grab a coffee instead of teaching claude the same stuff over and over again :)
It seems this has not landed on github yet ? origin/main has theme 0.5.322, and the live/deployed S3 has 0.5.328 ?
Much better approach !
same for dropping S3 and having Feeds in the database !
I'm already changing the deploy/ overlay in my fork to adapt to your changes :)
yes definitely coming your way over email, gimme a few hours
Yes this one is answered, I'll implement usage in my own clients UI
It means this :
A comprehensive Microsub social reader plugin for Indiekit. Subscribe to feeds (RSS, Atom, JSON Feed, h-feed), organize them into channels, and read posts in a unified timeline interface with a built-in web reader UI.
It's a built-in RSS reader with integrated Micropub actions buttons, so this means that from the backend UI RSS items reader view I can Like, Repost, Bookmark, Reply-to, or simply write a note or an article (a note with a title) but no matter the post type on indiekit, It'll be pre-filled with the source, usually, the RSS item in question, coming from one of my Microsub (think RSS reader) channels (think Category) within the Interface, in my case the microsub reader UI is behind auth, but if I would open it to the public, it would look like your river of news UI, with buttons to interact with RSS items
I will make my microsub indiekit plugin read it/display it properly, so that it can display handles as a source, with avatar if any, it would make the whole thing much more natural from an external reader point of view
It will also benefit my other RSS feeds, because i'll be able to show the name of the source with a favicon or logo/avatar of the source
Another Idea, this time regarding authentification :
it would be probably trivial to enable IndieAuth authentification on rss.chat, this would allow me for example to auth with my own website, using my own h-card to provide, email, username, etc. this would allow anyone supporting indieweb building blocks to login without bothering with email or with more complex SSO dependency (github, google, etc)
Another idea that I'm thinking out loud as I write this down :
What if I could get a notification if/when someone directly replies to me, either using websub or perhaps an external notification provider (ie: ntfy.sh)
Just thinking out loud, but... if I subscribe to the "everyone's feed" https://users.rss.network/rss.xml in my RSS reader, I obviously see each entry, but there is no way to know who is the owner of the post.. if we'd push this idea further down the road of a "social network powered by RSS" I would love to be able to see right upfront "who" is the author of the post, a bit like we do in the rss.chat UI, i guess this is why the "client" exist, but I was wondering if we could make ANY rss feed reader able to display "rss.chat" streams with proper user attribution
I like when I can contribute with approaches I do at work but for open-source projects :)
and Yes Claude is a great team mate to have around !!
Here is the localhost/vps deployment if anyone wants to test it : https://github.com/scripting/rss.chat/issues/2
You could use unfurling/opengraph to even display a nice embed card of these links if the origin has it :p
partly history, partly deliberate design.
History: rss.network was the project's earlier name — the server is still rssnetwork.js and calls itself that; the client later became rss.chat (his worknotes from July 3 mark the split).
Design: rss.chat is the dynamic app — the Node server, the API, the websocket — while users.rss.network is just a domain pointed at an S3 bucket of static feed files (and data.rss.network for the OPML).
Feed readers poll relentlessly, so serving feeds as static files means that traffic never touches the app server, feeds stay up even if the app is down, and it embodies his core claim: your feed is a durable artifact anyone can fetch, not an API response.
My instance keeps that same static/dynamic split — it just does it with one domain and a /feeds/ path on Caddy instead of a second domain, since there's no S3 in the picture.
I got it running in localhost :))
I'm reading this and I'm thinking... there is definitely better ways to deploy this, I'm going to submit an issue on the rss.chat repo to propose a deploy/ folder that would orchestrate deploying this either localhost or with a domain in a very easy way
Testing testing :)