27 Aug
2024
27 Aug
'24
4:10 a.m.
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
27 Aug
27 Aug
5:35 a.m.
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:
…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>
Content of the original message
😀
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
6:09 a.m.
On Tuesday, 27 August 2024 13:35:15 GMT+2 Nicolas Cedilnik wrote:
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.
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.
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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
23
days inactive
23
days old
2 comments
2 participants
participants (2)
-
Marcin Mielniczuk -
Nicolas Cedilnik