Interop requirements conversation thread

[andrewshell]

I'm thinking about what things need to be present to be considered compatible. My gut says to create several standard patterns, but maybe not be super strict about how they are implemented.

For example, if we wanted to have WordPress in the network, could we still use the underlying post/comment structure even if it's different than rss.chat?

The WordPress comments aren't peers of the posts, but could it still be considered compatible? WordPress comments are threadable (comment on comments), but they don't have their own permalink URLs (unless you consider the anchor a permalink).

For reference, here is a blog post on WordPress: https://test.geekity.com/2026/07/16/hoopla-world/
It is in the main feed: https://test.geekity.com/feed/
Comments aren't in the main feed, but each post has its own comment feed: https://test.geekity.com/2026/07/16/hoopla-world/feed/

[jeherve]

I've been thinking about that as well, but I wasn't really sure how WordPress could interact with rss.chat as it's currently designed?

We could certainly think of ways to:

1. Extend WordPress post feed items to include the new element rss.chat uses,source:comments,
2. Extend WordPress comment feed items, with a source:inReplyTo element to each one of them.

If each comment needs to have a custom permalink instead of just the parent post's URL with a hash, that's certainly possible. We have precedents with ActivityPub for example, that has an ActivityPub representation of each post AND comment.

Check these links to see how this is done in the ActivityPub plugin:

• custom query
• comment redirect

All that said, once you've added those items to a random WordPress blog, what does that give you? Is there something I'm missing? rss.chat doesn't currently allow you to interact between instances, does it? @scripting Is that something you think you'd support in the future?

[andrewshell]

@jeherve One thing I'm considering is whether this should be built on top of BuddyPress. It has its own activity type for both posts and replies and it tracks reply-to already.

[jeherve]

I know a very simple way to enable cross instance chats : its called webmentions

This was my initial thought as well; webmentions bring a lot, although not the concept of a thread, so you would be limited to a reply and its parent.

It has its own activity type for both posts and replies and it tracks reply-to already.

Same with ActivityPub, and it feels like a better candidate in my opinion, it's more in line with the idea of a federated discussion.

I have a prototype that I have not published yet

Nice! 🤩

[scripting]

@jeherve -- welcome.

i'm just going to kick back and see how this evolves.

happy to answer questions about the product, there are a lot of pieces that are only visible by reading the source, though we're marching through them pretty quickly.

[scripting]

I don't think it's a match, it may be that webmention is right, but i want to move beyond today's model for blogging, i want a network of equal power nodes. Nothing wrong with the way WordPress works, I just want to try out a different way.

Also have some experience how this works, I did a BBS in the early 80s that had this kind of structure and it was great!

Also the first UserLand discussion group, where somewhere in the middle of its life everyone went off to create blogs and that led to feeds, and the world we live in now.

The problem is everyone feels limited by what Twitter does, and WordPress, honestly.

@jeherve -- we might look at it from the point of view of your feed reader to get started and see where that goes.

[scripting]

With webmentions on both sides, my reply would lodge itself under the comment I'm replying to.

i don't want random replies from the internet on my rss.chat instance.

been there a million times, and it's always the same story because people don't change.

but because we have feeds for everything we can build anything you want.

[scripting]

@jeherve -- just thought of something.

1. we have an "everyone" feed for each instance.
2. you have a blogging platform.
3. i want to view the feed as a blog.
4. that's the best first connection imho.

i would love to see that, and the great thing is it brings in a new kind of wordpress writing.

a group of authors, like a news org.

and i imagine we'd have a lot of competition there.

this is kind of like what i wanted to do with wordland only better. much more opportunities for development of new ideas.

[scripting]

@rmdes -- there's a lot to say about this, but one very simple idea.

1. imagine a feed reader that where you can subscribe to people on using their feeds.
2. when they post something that's /inReplyTo, you know that's a reply, right? And you know what it points to. And from that you can get all the info you need to display it. the way comments work on wordpress, if you like or anything else.

Someone should write an app that makes the kind of list you want!

Also I want to do more with OPML, ideas not fully formed. I think we have to more about lists.

[scripting]

Want to be sure you've seen this.

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

[scripting]

@rmdes — I’m overloaded and tired all the time, so I can’t keep up with what you’re posting. Summaries help, and clear call to action.

[scripting]

@rmdes — I’m overloaded and tired all the time, so I can’t keep up with what you’re posting. Summaries help, and clear call to action.

[scripting]

Somehow we should be able to route that to Claude who did all the work on that example.

Actually -- if you post that on rss.chat -- Claude will see it.

[scripting]

This is Claude, writing from Dave's account.

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.

[scripting]

@jeherve -- i don't think i replied to your comment here 8 days ago. there was so much coming at me then, things have settled down a bit.

rss.chat doesn't currently allow you to interact between instances, does it? @scripting Is that something you think you'd support in the future?

it does not interact between instances, unless there's a breakthrough idea that makes that simple enough, no -- the reply threads on rss.chat contain only messages from within the instance. but that doesn't mean that such a user interface couldn't be created. everything here is on the web, so anything you can think of can be done. it's just another browser on data that could appear on different servers. that doesn't seem like a hard job for the web. ;-)

what's going on here is a different context. not so much a focus on one app, but rather data flowing in certain ways that can be captured and have things done with it, and then send that out into the world. the silos have put big blocks in the way of synergies develop, just look at the horrible situation with writing tools that depend on web text trying to coexist with bluesky in the atprotosphere. but when it's all out here, very often you think of things you want to do and can do, without any help from anyone.

i couldn't predict what will happen when we have a bunch of instances, there are people playing around at the source code level. my answers about what it can and can't do might not be theirs! ;-)