You're all set then, you know how to handle what we ship in our feeds. 

Good to know. ;-)

Fresh install of rss.chat with SQLite was successful. 👍

Technically we do store hierarchical data in the database — each reply knows the reply it's replying to and the root post — but we only display replies as a flat list. I had intended to have a mode where it switches to hierarchical when a conversation has gotten long and out of control, but never got around to that.

Thanks Manton!

Keep us in the loop on what you do, and if there are any nice-to-have or must-have features. 

Are your conversations hierarchic?

Just fixed compatibility with RSS.chat feeds in Micro.blog. Next up is to figure out if we can process comment feeds to view RSS.chat conversations within Micro.blog... A little tricky because of how Micro.blog assumes hostname usernames.

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.

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.

Don I think I have to try your product before I’ll understand.

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.

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 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 Exam...

Everything seems to have worked quite nicely. Soon it will be time to break for the day. 

But it's been quite a day here in daveverse, with my excellent programming buddy, Claude.

Now we're running the new server software on rss.chat.

Not yet on demo.rss.chat.

We're testing a big new feature in the next few minutes. 

Can't wait to tell you about it, esp if you're thinking about running your own instance. 

It's about to get easier. Fingers crossed.

A lot of people are confused about wtf this is.  I don't blame them. I put out there a partially implemented vision.  But the vision isn't really new -- it's a turnback to 2002, and what UserLand would have done if we had continued pushing, which we did not.  ...

Another test post. 

This one has things that look like URLs to autolinker, but shouldn't be hotted up because they aren't full web addresses. 

This is the test part -- install.md and rss.chat are two examples, the first should not be linked and the second should.

Next test post. We made it so that the server automatically chops off extraneous blank lines at the end of a post. Sometimes they pile up after editing and you can't see them. They shouldn't be in the feed, so we take em out. So this post will have many blank lines at the end when I publish it.

Result -- it works. ;-)

BTW, changes like this will be merged with the repo at end of the work session. And I'll updated demo.rss.chat once, at the end of the session.

It's a demo app that does something quite useful and I hope illuminating. 

We're working on a new example toolkit, this is a test post to see if it worked. 

Don, I made the change described in the previous post.

1. removed the version number of the theme from the menubar.

2. changed the name of the first command in the system menu (the one with your name in its title) to "Software versions" which is what it's really about. 

3. in that dialog you will get all the versions of all the software running in rss.chat.

Don there are actually quite a few version numbers in rss.chat, so a single tool tip couldn't cover it. We do have a command that gets you all the version numbers, it's the first one in the system menu at the right side of the menu bar. You can also get to that same dialog by clicking on the theme version number, but I'm thinking we should change the way that works. While we were in rapid development mode of the UI, that would let me know that I was using the latest version of the themes code. But we aren't moving that quickly any longer, and there are other components we need to keep track of. So we'll probably change that around now. Stay tuned. 

People assume rss.chat is going to go the same route as twitter or mastodon, and it isn’t.

This is going to remain a small group. That doesn’t mean our posts can’t be viewed in other places, together, as collections of people you follow. We already have experience doing just that, in feed readers. The user interfaces there might be different. And there can be more elegant ways of editing your subs. And sharing subs among services. We already support that tech in FeedLand, btw.

The social networks we’ve been using have a lot of dead ends, by design, lot of “you can’t get there from here.” We’ve got the opposite philosophy. Small pieces loosely joined and every part replaceable. That gets you to new places we’ve never been before.

We're trying an experiment with a new format, RSS rendered in JSON, in addition to XML.

https://rss.chat/feed?screenname=dave&format=json

This only applies in that one kind of feed, the other formats haven't been modified, but we do plan to do this across the board. If we generate something in XML we will also generate it in JSON. 

Just wanted everyone to see this, I don't think it's earth-shaking -- but it's time to put this out there. For whatever reason no one listened to RSS, but imho it had something to say. :-)

Thanks. You can see why I push back when people think of this as a product.

So many people don't think in terms of small pieces loosely joined. The power of my product is not in all its features but all the things that are left undone, that are possible.

That's simply the web. For 12 years before the silos, the web was that malleable. That's how we made blogs, feeds, podcasts happen. The bigco's tried to get in the way, but it didn't work because the people knew what they were entitled to.

New on the repo today, for everyone here building outside rss.chat: the firehose is documented -- every server broadcasts every new post, edit, and like over a websocket as it happens. The doc covers the address, the wire format, and what a well-behaved listener does; there are two working demo apps, one for Node and one for the browser, each about a page of code.

Docs: https://github.com/scripting/rss.chat/blob/main/server/docs/firehose.md

Demos: https://github.com/scripting/rss.chat/tree/main/examples/firehose

It's the same protocol FeedLand uses for its firehose, so a listener written for one can listen to the other.

A peptalk for devs.

This is a test post for an experiment claude is running.