[ptman]

Many of these problems stem from the fact that matrix is federated. And it's a protocol, not really even for messaging but for a federated graph database. In federation some messages may be missing and arrive out-of-order. And different clients have different capabilities. There's a really simple example client implemented in a couple of lines of bash.

[dzaima]

No, most of those are just plain and simple bad outcomes due to not having thought out extremely basic things ahead-of-time. And even if there are problems with actually no simple fix, that in no way means the problem ceases to be a problem.

Replies to threads from thread-unsupporting clients are the one potentially-hard thing federation-wise, as doing it properly would require the server to trace back the reply and from that handling it as in the thread, but that's not far from what servers already have to do with edits. Or you could also just not require/suggest that behavior, having replies without thread metadata always be outside of threads; would probably save on confusion too, as the illusion would break anyway when someone on a client without thread support would not do a reply on some message after having used replies on others.

There might be some graph core to it, but it's still primarily a messaging service. Opening the client spec will show you tons of messaging-specific APIs.

I utterly disagree that saving a half-dozen lines in largely-useless toy clients is worth making more feature-complete clients more complex, and doubling the size of every edit event.

[self_awareness]

> In federation some messages may be missing and arrive out-of-order.

Doesn't "some messages are missing" trait defeat the point of a reliable communication protocol?

[ptman]

Missing at any given moment. There's eventual consistency. But sometimes connectivity isn't 100%