Hi,

Adding a few design notes from my experience with other platforms. Hopefully this will help inform further discussion.

I don't see that it's needed to check for other replies. If two people start a 

reply at the same time, there will be two threads with the same parent, in the 

UI this appears like a tree, i stays readable. This is what happens on sites 

like Reddit on ActivityPub (but on Mastodon, the tree doesn't appear in 

comments, making it very confusing IMO).

ActivityPub uses the concept of "parent post" rather than "threads". And yes, it does get confusing when the replies branch out into a tree and then get "flattened" out for display in interfaces like Mastodon's.

If I want to choose a single strand of the conversation, I would choose the last post in that sequence, and then get presented with all direct ancestors of that post (which is a single strand as each child can only have one parent). I think this "single linear sequence, among possibly many", is what originally became Twitter-style "threads" (now used by Mastodon too).

In summary: AP "threads" are basically "a sequence of posts where each post is a child of the immediately preceding one", but as each original post can branch out into many "threads" I'd say it's more of a GUI consideration than anything else.

Never used those services, but the normal flow i imagine is, im in a support channel, someone asks a question "How do i do X?", now 2 people start to type, and create two separate threads with the answer, now a 4. person wants to join, then the client needs to decide to reply to one of the threads.

Also from the GUI side its unclear how should handle this, should i hide the fact that there are 2 threads? Should i show 2 threads? But then obviously both users wanted to answer the same person, i would say it would be the expectation that this conversation is wrapped in a single thread and not multiple.

What happens in AP in practice is that the third commenter would make another reply that is a direct child of the original post (yet another "thread" if you will). People also use it in this way; if I wanted to reply specifically to Commenter 1 I would reply to Commenter 1's post, but if I wanted to make a general comment on the entire conversation I would reply directly to the main thread.

This is very different from how I would approach interacting with a conversation in a chat-oriented app (XMPP or otherwise): on ActivityPub I'm more diligent about selecting the specific message I want to reply to. I think that's partly because each reply is a "post" in its own right that could be shared, boosted, etc. and show up on peoples' timelines as an entry point to whatever they're going to see next. Depending on which message I reply to, they'd be presented with a different view of the conversation (which they could change, of course, but it is their first view of the entire conversation).

Finally, with regard to moderation/retraction: with ActivityPub software (including Akkoma and Mastodon), when I'm deleting a post I get a warning that any replies to that post will be "orphaned", i.e. not have a parent any more. I have also seen some posts where in place of a parent all I get is "this post no longer exists". So it is arguably an issue there as well (but see my next section with thoughts about threads).

---

On a different note, since there was some debate about how to include thread IDs: Discord, unlike AP, treats "threads" and "a sequence of replies" as two different things. The default mode is to have all the conversation inline (no threads/parents/etc.) but if there's a sequence of replies (a message, to which there is a reply, to which there is another reply) then it asks if I want to "convert that message to a thread". (One can decide to make a message into a thread at any point, but the UX explicitly suggests it when it thinks a sequence of replies has gone on for long enough)

At that point, only the parent message will be shown in the main message area and subsequent replies (which are all linear/sequential) show up only when you click on that parent message to navigate into the thread.

Mattermost, on the other hand, does "both" which I suppose is somewhat similar to Mastodon. Replies are internally a "tree of replies", but the default view is to show only the first message and make the user click through to see the other replies in a linear way (so, visually similar to Discord "threads").

However, there is also an option to turn off "threads mode" at which point all the child replies will show up along with the main messages (visually similar to Discord "replies"). In this mode clicking on any of the child messages will show up the entire "thread" (i.e. initial parent message and all it's descendant replies).

In my opinion Mattermost is the most confusing as people experience the messages differently depending on their settings. For XMPP, perhaps we should first decide which of "linear threads" or "branching-out replies" is being defined? Even if we have both, in my opinion it would be better to treat them as separate (if somewhat related) concepts. Linear threads would be the ones with thread IDs whereas "branching out replies" don't need to have anything to do with threads at all.

After typing the above, I realised that Goffi had outlined these different modes of thinking too; I am pasting a quote for reference:

The way I got it, we have basically 2 ways to see threads:

1. A series of replies to any message in a group chat, à la Slack (in Slack, 
you see the replies hidden under parent message, with something like "X 
replies", and when you click, a panel appear with the whole thread.

2. A side discussion explicitly started, that could be seen like a new chat 
window (UI example: user clicks a "start a new thread button", and start a 
blank window with it message, this message has a new thread ID, that will be 
used by people replying to it).

As I said, I think it would be best to treat these as two separate features, and either decide which we want or do as Discord does and offer each as distinct options.

Best,
Badri