Thread messages missing traditional reply metadata

[jryans]

If I understand correctly, thread messages are meant to appear like replies to the thread root in clients that don't understand the threads feature. However, at the moment, that doesn't seem to happen (instead they appear as plain messages without any parent message).

For example, a thread message currently contains the following:

    "body": "Thread message",
    "m.relates_to": {
      "event_id": "...",
      "rel_type": "io.element.thread"
    },
    "msgtype": "m.text"

...but this does not look like a reply would per spec. I believe the key missing bit is the in_reply_to segment:

    "m.relates_to": {
      "m.in_reply_to": {
        "event_id": "..."
      }
    },

If this were added, existing clients should indeed show the message as a regular reply.

[germain-gg]

The idea is to keep the event source untouched, but to make the ReplyChain component looks for threads relations.

[t3chguy]

That won't fulfil the ask of

in clients that don't understand the threads feature.

Backwards compatibility would be really nice as it may take a very long time for some clients to gain threads support, and without some fallback, be it replies or a similar plaintext fallback like replies has, the timeline may become unusable as these messages will be observed without the context and thus a Yes in a thread replying to something from hours ago might make no sense to users of certain clients.

[germain-gg]

As part of the P0 launch, we're making sure that all major clients will actually implement that fallback. You have tasks like this one element-hq/hydrogen-web#552 in all major clients. And that will ensure a good backwards compatibility experience.

[t3chguy]

What's the definition of a major client? Things like view.matrix.org will unlikely see Threads this year so it will yield a very broken experience for search engine indexing

[dbkr]

I think the problem with doing backwards compat by adding reply data as well basically means you can't have replies in a thread, so as I understand it, basically we don't have much option other than to try to get basic thread support into the clients we know about and accept that some are going to just have the thread's messages inline in the room, which isn't ideal but I think it's the best we can do. We can make this clearer on the MSC / in general.

[jryans]

I added a note to the MSC so we can clarify as needed.

[jryans]

Ah, and Dave added their own version too. 🙂

[germain-gg]

@jryans according to MSC3440 threads are not expected to have reply metadata.
It looks like, you and Dave answered on the MSC. Should we close this issue and move that conversation to the MSC? Will answer/address comments this afternoon

[jryans]

Sure, now that the context is captured elsewhere on the MSC, I agree this issue is redundant.