[Standards] Business rules of Last Message Correction
georg at op-co.de
Mon Jun 11 09:20:28 UTC 2018
* Ненахов Андрей <andrew.nenakhov at redsolution.ru> [2018-06-11 11:05]:
> The only technical reason for doing only last message correction is a
> possible absence of unique id in sent message.
The XEP requires the sending client to generate IDs:
| Clients MUST send ids on messages if they allow the user to correct
I wish it would require *unique* IDs, but that's what we've got, and a
reasonable client will use unique IDs anyway.
> Proprietary services like Telegram, for example, set arbitrary
> business rules that only messages in the last 48 hours can be
> retracted/edited. I think such business rules are hard to enforce in
> federated service,
I think there is a compelling reason to allow correcting more than just
the last message - imagine typing multiple lines in a row, and only then
reading what you sent, to realize a typo / incorrectness.
> Maybe It's better not to try doing things you can't do well.
If the worst thing that can happen is a "duplication" of the message,
where the receiver can see both the original and the correction, I think
it makes sense to try. I'd prefer to have had a business rule defining
an arbitrarily set time limit like in Telegram (48h) or a smaller one
(2h?) instead of the current strict last-message-only approach; but on
the other hand, the XEP does not forbid changing older messages, it just
makes the interop inconsistent, which I'm used to live with from other
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Standards