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
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to