unrealistically high standards for encrypted messengers (an ability to establish any happens-before relationship at all)
Conversation
Replying to
guess there’s nothing stopping you from sending the msgs in a DAG prior to encryption. might do that? Matrix orders them in the server in a DAG after encryption, but encryption lets you pick sequence IDs out of order if you’re being perverse.
1
2
Replying to
this is prompted by eternal frustration with S*gnal and, yes, discovering that Matrix does sort of kind of the same thing in some circumstances (still haven't narrowed it down exactly, so it might actually look worse than it is)
1
messages from both parties intermeshing after something happens (even though there's delivery receipts!), no federation involved: not that bad
desktop Element doing weird stuff that causes messages appear to not be sent and also appear out of order: unfortunate
1
never got that on Android Element, so maybe just an issue with the desktop Element codebase? a restart usually fixes it, though today i had to restart it three times while that part of the interface gradually broke more until it fixed itself, kind of frustrating
1
Replying to
This is a flaw in the Matrix client-server API; to send a msg you do an HTTP PUT with a txn ID but no causality information. So if the PUT gets delayed in a proxy or hits a worker which is struggling relative to the next PUT, the messages (very rarely) could get out of order.
1
1
It happens so infrequently that we've not bothered fixing it (plus smarter transports might have explicit ordering of the requests in future). Separately element web/desktop may have a queuing bug for unsent msgs.
1
Replying to
yeah, i get that, but it's been happening like every other day for some reason
might just do something about it one day if it keeps happening
2
Element has a UI bug where it sometimes displays a message at the bottom but I don't think it has anything to do with the protocol. It's a UI race condition or something along those lines. Not entirely sure if that's the issue you're talking about. There's probably a bug open.
1
1
if you have a stuck msg at the bottom of the timeline it’s generally a Bad Sign as it means that remote echo didn’t arrive - ie the server dropped a msg, which should never happen. debug logs are *really* appreciated in this instance.
1
1
Refreshing the page always fixes the issue for me and I've always been able to confirm that the message did go through. I could be wrong but it seems like a UI bug. It doesn't show the message as still sending, etc.