26 Apr
2025
26 Apr
'25
4:57 a.m.
[sorry my previous message was badly formatted, I send it again to make it more readable]
Hi Philipp, thanks for your feedback.
Le samedi 26 avril 2025, 12:26:47 heure d’été d’Europe centrale Philipp Hörist
a écrit :
The one thing that bugs me about the reply method is,
that it depends on
that i go searching first if someone else has replied to be able to send a
message.
This leads to the situation that multiple threads are created if different
people answer nearly at the same time. At this point its unclear how to go
forward. Certainly the two people didn't want to have separate threads.
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).
Further stuff like moderate can remove all content
from a message, it would
destroy the link to the parent message if the first reply gets moderated.
Leaving all other messages hanging in the air without context.
Indeed, that's a problem if the first reply with the new thread ID is deleted,
good point.
So for me the thread string needs to be generated out
of the parent message
to avoid this, and also make it simple.
If for some reason the community deems it absolute necessary to create
threads from messages that don't have a thread themself s, i would simply take
the message-id of the parent message and use it as a thread id, circumventing
any mentioned problems above. This is even moderate safe, because the message-
id is never moderated.
Yeah, that's the alternative that I have proposed. I think that using parent
message ID as thread ID is a good option, maybe with a XEP to explain this
behaviour. This can be used at the same time as XEP-0461, so clients
implementing only XEP-0461 can still see it as a reply (but XEP-0461 says that
it should not be used for sub-thread, so if other replies are made using
XEP-0461, it may be a problem).
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.
Best,
Goffi