XEP-0444: fallback mechanisms?
Hi, I noticed that, in the current implementations of XEP-0444 are not really backwards-compatible. Non-compliant clients completely miss the emoji reactions and the users are completely unaware that the reaction has been sent. One idea would be to provide the following as a fallback:
Content of the original message 😀
in a similar way to how message replies are currently shown on non-compliant clients. Similarly, when an OMEMO-incompliant client receives an OMEMO- encrypted message, it still receives some placeholder message indicating that the message is OMEMO-encrypted but the client does not support it. Is there any reason why there is currently no fallback mechanism in XEP-0444? Regards, Marcin
Hi,
I noticed that, in the current implementations of XEP-0444 are not really backwards-compatible. Non-compliant clients completely miss the emoji reactions and the users are completely unaware that the reaction has been sent.
Even if it not mentioned in XEP-0444, XEP-0428 can be used…
One idea would be to provide the following as a fallback:
Content of the original message 😀 …and that's actually what Cheogram Android does. You can see an example of such reaction+fallback stanza in this test case: <https://git.sr.ht/~nicoco/slidge/tree/master/item/tests/test_shakespeare.py#L558> Is there any reason why there is currently no fallback mechanism in XEP-0444?
It gets rapidly messy in groups. One of the values of emoji reactions is to improve signal to noise in large groups, and non-supporting clients will have a ton of noise with fallbacks. There are also other not-so-edge cases that are annoying to handle: reaction to attachments, modification of reactions. That said, I think in 1:1 chat it would be quite reasonable to include a fallback, as the signal to noise ratio is not an issue there. Again, XEP-0444 does not forbid it, it's a up to client (and gateways ;)) developers. -- nicoco
On Tuesday, 27 August 2024 13:35:15 GMT+2 Nicolas Cedilnik wrote:
Is there any reason why there is currently no fallback mechanism in XEP-0444?
It gets rapidly messy in groups. One of the values of emoji reactions is to improve signal to noise in large groups, and non-supporting clients will have a ton of noise with fallbacks. There are also other not-so-edge cases that are annoying to handle: reaction to attachments, modification of reactions.
I agree. However, I don't think we can have a non-messy fallback, as a single <message> stanza may only contain a single reaction. The alternative is that the users are completely unaware that something was communicated to them - which is much worse than being messy. It's akin to messages being dropped, IMO.
That said, I think in 1:1 chat it would be quite reasonable to include a fallback, as the signal to noise ratio is not an issue there. Again, XEP-0444 does not forbid it, it's a up to client (and gateways ;)) developers.
Maybe it's only my use case, but I often use MUCs containing just one other person for content separation: for example a separate MUC for sending memes, that can be easily muted, and another one for more urgent stuff. Do we have any XEP to indicate that a message should be a silent one, i.e., that the client should not issue a notification? MS Teams has @silent messages. - MM
-- nicoco
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
participants (2)
-
Marcin Mielniczuk -
Nicolas Cedilnik