Hi,

On Sat, Apr 26, 2025, at 12:57, Goffi wrote:

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

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.

But maybe i envision this worse than it is in practice.

> This comes at the cost of losing the feature to signal that a message should
> not be used for a thread.

How do you signal that a message should not be used for a thread, and why
would you do that?

From a UX point of view, I think that it would be bad that some messages can
be replied in a thread, and some other can't, the end-user would not
understand why sometime the button appears, and sometimes not.

I just wanted to note what the implications are of the design decision. I could imagine someone wanting in their channel that no thread is created under a bot message. I dont see this as a show stopper, just want to prevent that in a year we need to add <no-thread> for some reason, when we could have it now naturally by not including a thread.

As for the moderation XEP, i definitely think the moderation and als retraction XEP should exclude the <thread> element from being removed, from the message.

Regards

Philipp