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.
Maybe what you want is a command to expand all the subs under the current post. We don’t have that now, but it wouldn’t be hard to add. you can already focus on one node by clicking on its permalink, by convention, clicking on the timestamp.
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.
It would just be a command in a menu. We have lots of room to grow there.
I’m looking for things to put there, user interface improvements are the most visible.
We tried out a lot of different ways of doing this, the switch between timeline and structure.
I had a product in the early 80s called LBBS that had a neat way of doing this, but it was a scrolling display, where things like that worked. We tried it here, but yuck. Didn’t work.
Also in the UserLand discussion group we had a flip switch like that but you could see only one level at a time.
I’m willing to put an experimental feature in for you. I think the idea of expand-all is easy enough, would have to have a limit because there could be a lot under any node.