[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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
