Secondary bridging

[snarfed]

If you post on protocol A, and we bridge that post to protocols B and C, and someone replies on B, we could hypothetically bridge that reply across to C. Kind of an horizontal/indirect/secondary bridged federation. Shades of SWAT0, across protocols. Should we? Thoughts?

[WisTex]

It depends if you want to support threaded conversations.

On platforms such as Mastodon, which are unthreaded, it does not matter much, since there is no thread and the conversation is unfettered.

Whereas on a threaded conversation, you expect to see all of the replies, and it can get weird when replies are missing from the thread.

[snarfed]

Hmm, I'm confused. Mastodon's threaded comment UI may not be deep, or great, but it does exist, right? And the underlying AP activites and AS2 objects all have the inReplyTo links needed to reconstruct fully nested threaded conversations, and those are the same across all platforms.

Missing replies is indeed a common problem in the fediverse, but it's independent of threading UIs or AP objects. It's due to AP's inbox delivery and (especially) AS2's audience targeting models. Replies are always delivered to their immediate parent, but beyond that, up the chain or horizontally across subthreads, depends on inbox forwarding, which is complicated and only partially supported in the current fediverse, at best. (The spec even refers to this explicitly, as "ghost replies.")

(Apologies, I'm sure you already know much of this!)

[WisTex]

Mastodon does not support threaded conversations. It has replies, but every reply is considered a new post, which can also have its own replies. So the replies may not be "in reply to" the post that started the whole conversation.

That is not how threaded conversations work.

In a threaded conversation, such as a forum post or a PeerTube video or a Facebook post or comments on a blog post, there is one post that is the parent of all other posts in the conversation. And the person who started the conversation has control over all of the posts in the conversation (including the ability to delete comments by others in their thread).

For example, if you post a comment on a forum or a blog, your comment can be deleted since the container the comment is in belongs to someone else. Whereas on Mastodon, there are no containers. Each post is independent of each other.

Some platforms use collections in addition to inReplyTo to indicate the parent of the thread. So you can't go by inReplyTo by itself.

There is an effort to standardize threaded conversations in ActivityPub because there are many different platforms that have implemented discussion groups or forums. Whereas, Mastodon's pre-X Twitter style of posting doesn't currently understand what a group or thread is.

[snarfed]

OK. We may have had different expectations of what "threaded" means, which isn't too surprising. 😁 I don't know that it necessarily implies who has control over (ie can delete) the replies, that seems orthogonal, but otherwise I get your difference between microblogging style reply chains (Twitter, Mastodon, Bluesky) vs forum style posts (Reddit, Lemmy, etc).

[snarfed]

(Btw, minor note, many forums and blogs also support nested, reply-to-reply style comments too! Precedent for all of this is fuzzy and overlapping and evolves over time. 🤷 I'm hoping to mostly avoid product/feature design decisions like these in the bridge, but I can't avoid all of them. Whee.)

[Tamschi]

There is work related to this that just completed here: NeuromatchAcademy/mastodon#44
In short, hopefully this will soon be automatic on ActivityPub, as long as Bridgy Fed exposes the replies collections of posts.

(Some software other than Mastodon already has this feature, IIrc.)