No m.thread handling anywhere — zero hits across backend/matrix/. A threaded message falls into the flat timeline with no marker, so a busy threaded room reads as an interleaved mess and there is no way to reply into a thread.
Done looks like:rel_type: m.thread recognised inbound and threads rendered as their own buffers or an inline panel, matching whatever shape the Discord threads issue settles on.
No `m.thread` handling anywhere — zero hits across `backend/matrix/`. A threaded message falls into the flat timeline with no marker, so a busy threaded room reads as an interleaved mess and there is no way to reply into a thread.
**Done looks like:** `rel_type: m.thread` recognised inbound and threads rendered as their own buffers or an inline panel, matching whatever shape the Discord threads issue settles on.
What is fixed. A threaded message carries rel_type: m.thread naming the message the thread grew from, and usually also an m.in_reply_to which is a fallback for clients that cannot read threads. That fallback points at the previous message in the thread, not at the thread — so a client reading only it, which this one was, shows a chain of one-line replies where a conversation was. The thread relation is now preferred, so a threaded message says which conversation it belongs to instead of arriving with no context.
What is not. Threads are not buffers, there is no thread list, and replying to a threaded message still sends an ordinary reply rather than continuing the thread. That last one is the gap worth naming: the store keeps a reply target but not what kind of relation it was, so nothing here can tell "reply to this message" from "reply into this thread" at send time.
Doing it properly means a thread being a first-class thing in the buffer model — which is the same design Discord's #75 needs, for the same reason. Both are waiting on the same decision about whether a thread is a buffer, a panel beside the log, or an inline expansion, and building one shape for Matrix and a different one for Discord would be the wrong order to do it in.
Partial work landed, and the issue stays open deliberately — this is the honest half, not the feature.
https://git.salastil.com/Salastil/nobilis/commit/5ce6d50
**What is fixed.** A threaded message carries `rel_type: m.thread` naming the message the thread grew from, and usually *also* an `m.in_reply_to` which is a fallback for clients that cannot read threads. That fallback points at the **previous message in the thread**, not at the thread — so a client reading only it, which this one was, shows a chain of one-line replies where a conversation was. The thread relation is now preferred, so a threaded message says which conversation it belongs to instead of arriving with no context.
**What is not.** Threads are not buffers, there is no thread list, and replying to a threaded message still sends an ordinary reply rather than continuing the thread. That last one is the gap worth naming: the store keeps a reply target but not *what kind* of relation it was, so nothing here can tell "reply to this message" from "reply into this thread" at send time.
Doing it properly means a thread being a first-class thing in the buffer model — which is the same design Discord's #75 needs, for the same reason. Both are waiting on the same decision about whether a thread is a buffer, a panel beside the log, or an inline expansion, and building one shape for Matrix and a different one for Discord would be the wrong order to do it in.
Finished — threads are read as threads and can be opened and continued.
A thread now has its own panel beside the room (the member list column, which it closes while open), reached either from the reply count on the message a thread grew out of or from the “in thread” line on a message inside one. It has its own composer, so the room’s composer still answers the room.
Underneath: ReplyPreview carries whether the relation is a thread — that was the missing bit, since Matrix says “reply to this” and “say this in here” with the same field — and sending into one builds rel_type: m.thread with the fallback marked is_falling_back. /relations reads a thread whole, because its replies are ordinary timeline events and a room paged backwards only finds them by crossing all of them. Backfill records relations too; it was dropping them, so history arrived as loose messages.
Verified live on poa.st: a thread sent from the panel came back from the server marked as a thread against the right root, and fetched whole.
Finished — threads are read as threads and can be opened and continued.
A thread now has its own panel beside the room (the member list column, which it closes while open), reached either from the reply count on the message a thread grew out of or from the “in thread” line on a message inside one. It has its own composer, so the room’s composer still answers the room.
Underneath: `ReplyPreview` carries whether the relation *is* a thread — that was the missing bit, since Matrix says “reply to this” and “say this in here” with the same field — and sending into one builds `rel_type: m.thread` with the fallback marked `is_falling_back`. `/relations` reads a thread whole, because its replies are ordinary timeline events and a room paged backwards only finds them by crossing all of them. Backfill records relations too; it was dropping them, so history arrived as loose messages.
Verified live on poa.st: a thread sent from the panel came back from the server marked as a thread against the right root, and fetched whole.
nobilis 8dc0b7c, moho https://git.salastil.com/Salastil/moho/commit/12a90b2
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
No
m.threadhandling anywhere — zero hits acrossbackend/matrix/. A threaded message falls into the flat timeline with no marker, so a busy threaded room reads as an interleaved mess and there is no way to reply into a thread.Done looks like:
rel_type: m.threadrecognised inbound and threads rendered as their own buffers or an inline panel, matching whatever shape the Discord threads issue settles on.Partial work landed, and the issue stays open deliberately — this is the honest half, not the feature.
https://git.salastil.com/Salastil/nobilis/commit/5ce6d50
What is fixed. A threaded message carries
rel_type: m.threadnaming the message the thread grew from, and usually also anm.in_reply_towhich is a fallback for clients that cannot read threads. That fallback points at the previous message in the thread, not at the thread — so a client reading only it, which this one was, shows a chain of one-line replies where a conversation was. The thread relation is now preferred, so a threaded message says which conversation it belongs to instead of arriving with no context.What is not. Threads are not buffers, there is no thread list, and replying to a threaded message still sends an ordinary reply rather than continuing the thread. That last one is the gap worth naming: the store keeps a reply target but not what kind of relation it was, so nothing here can tell "reply to this message" from "reply into this thread" at send time.
Doing it properly means a thread being a first-class thing in the buffer model — which is the same design Discord's #75 needs, for the same reason. Both are waiting on the same decision about whether a thread is a buffer, a panel beside the log, or an inline expansion, and building one shape for Matrix and a different one for Discord would be the wrong order to do it in.
Finished — threads are read as threads and can be opened and continued.
A thread now has its own panel beside the room (the member list column, which it closes while open), reached either from the reply count on the message a thread grew out of or from the “in thread” line on a message inside one. It has its own composer, so the room’s composer still answers the room.
Underneath:
ReplyPreviewcarries whether the relation is a thread — that was the missing bit, since Matrix says “reply to this” and “say this in here” with the same field — and sending into one buildsrel_type: m.threadwith the fallback markedis_falling_back./relationsreads a thread whole, because its replies are ordinary timeline events and a room paged backwards only finds them by crossing all of them. Backfill records relations too; it was dropping them, so history arrived as loose messages.Verified live on poa.st: a thread sent from the panel came back from the server marked as a thread against the right root, and fetched whole.
nobilis 8dc0b7c, moho https://git.salastil.com/Salastil/moho/commit/12a90b2