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

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to