Events that have a non-thread relation to other events (eg. reactions) are
considered to be in the thread that their parent event is in.
MSC3981
defines a way to recursively load such relations with the /relations API
but for such events, it is impossible for a client to know what thread the
event is in when it arrives from /sync unless it already has, or fetches,
the parent event. This means performing another client-server API request to
fetch the parent event which is inefficient.
This proposal wants to reduce the amount of work required for clients to partition events with certainty.
Whenever a server returns events in the client-server API, it adds a thread_id
property to the unsigned field of the event with the ID of the event's thread root
as defined in MSC3440. This applies to any endpoint that returns events including
/sync and /messages.
{
"unsigned": {
"thread_id": "$event_id"
}
}All events that are not part of a thread should fill the thread_id property with
the special value main – as defined in MSC3771.
If a server does not have the first-order event, the unsigned thread_id property
should be filled with a null value.
This could have performance implications on the server side, requiring more work to be performed when fetching events in a room.
It is possible that a server will have the second-order event, but not have the first-order event (eg, it has received a reaction over federation, but has not yet received the event being reacted to).
If "MSC3051: A scalable relation format" were to be adopted, second-order relations could specify their thread directly as one of the relationships, in which case this MSC would become unnecessary. However, that MSC is a longer term evolution of the protocol and will take time for the ecosystem to adopt. This MSC is intended as a much shorter term fix.
No security considerations
While this MSC is not considered stable by the specification, implementations must use
org.matrix.msc4023.thread_id in place of thread_id.
This MSC does not have dependencies