26 Apr
2025
26 Apr
'25
5:17 a.m.
Hi,
On Sat, Apr 26, 2025, at 12:57, Goffi wrote:
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
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.