You have when the client claims it was sent (so where it goes in the displayed history) and can see when it was received. What else could you possibly do?
For example, you could reject the message and show the user an error but only if there's a discrepancy of >X minutes. But how much discrepancy should be allowed? I don't know, I only mean to show why I think the solution isn't as simple as it appears
> you could reject the message and show the user an error but only if there's a discrepancy of >X minutes
No you can't, not in a federated and decentralised system like this.
The sender can wait for a read receipt from a given receiver user, if the receiver is willing to make those public. But if the message left client A and didn't arrive at client B, there's no objective fact of the matter about whether the message "was sent" or not.
Seems like a design deficiency of Matrix then. When IRC federation breaks, everyone can see it, except for the rare people who aren't in a shared channel with anyone on the other side of the break.
> When IRC federation breaks, everyone can see it, except for the rare people who aren't in a shared channel with anyone on the other side of the break.
Well sure, you could see that something was going on, if you were paying attention. But how does that solve the problem? Does your IRC client stop you from sending messages if it detects a netsplit?
I don't think IRC is a good analogy here because there's no "message resync" that happens when the netsplit is resolved. If there are two people on opposite sides of a split, and they both send messages to a channel while things are still split, they will not see the other's messages when the split is over.
In the Matrix case, if a homeserver disappears for a while, it will sync any missed messages when it comes back online.
