Hi,

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.

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.

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.
This comes at the cost of losing the feature to signal that a message should not be used for a thread.

Regards
Philipp


On Sat, Apr 26, 2025, at 11:24, Goffi wrote:
Hello,

We've got a discussion about thread on xsf@ a couple of days ago, and I would 
like to bring it here.

I initially thought that XEP-0461 (Message Replies) was redundant with 
threads, except in the case where there is no thread ID in the message a user 
wants to reply too. After discussion, notably with singpolyma and lovetox, it 
appears that we don't have the same view  on this.

The way I got it, we have basically 2 ways to see threads:

1. A series of replies to any message in a group chat, à la Slack (in Slack, 
you see the replies hidden under parent message, with something like "X 
replies", and when you click, a panel appear with the whole thread.

2. A side discussion explicitly started, that could be seen like a new chat 
window (UI example: user clicks a "start a new thread button", and start a 
blank window with it message, this message has a new thread ID, that will be 
used by people replying to it).

In case 1, the parent message needs a thread ID so that thread can continue 
with the same ID. Problem is if parent message doesn't has a thread ID 
(because client doesn't support thread, or because there is no thread ID for 
each message), in this case a XEP-0461 "reply to" can be used, then the first 
reply has a new thread ID, and the thread can continue.

In case 2, the explicitly started thread has a newly generated thread ID, so 
there is no problem.

I want to support both 1 and 2. For 1, my initial reading of XEP-0201 (Best 
Practices for Message Threads) was that a new thread ID should be generated 
for each message:

> Unless a <message/> stanza is written in direct reply to another <message/>
> stanza, if a ThreadID is included then its value SHOULD be newly generated
> when a human user initiates a chat conversation with another user (i.e., a
> <message/> stanza of type 'chat'), starts a new conversation in the context
> of a multi-user chat environment (i.e., a <message/> stanza of type
> 'groupchat'), or sends a normal message.
XEP-0201 §3.2.

But after discussion, I realise that it's not requested to generate a new ID 
each time, and it seems that generating new thread ID for each message would 
be a problem for some clients (notably Cheogram which would create a thread UI 
for each ID).

The solution would be to use "reply to" from XEP-0461, then a newly generated 
thread ID.
I've also proposed an alternative when parent message ID could be used as 
thread ID, this may we can find parent message without relying on XEP-0461.

For the moment, I think that I won't generate new thread ID for each message, 
and if I create a thread from a parent message I'll use a XEP-0461 "reply to" 
and generate a new thread ID, then use this thread ID for following message in 
this thread.

However, I would like to have feedback from the wider community:
- how to you handle or plan to handle threads?
- Are you planning to implement case 1 (threads can be started from any 
message) and/or case 2 (threads are explicitly started)?
- How would you handle case 1?

Thanks!

Best,
Goffi
_______________________________________________
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-leave@xmpp.org


Attachments: