Thanks for the feedback.
I suspect that in most instances, you're happy to accept any
reactions, and forcing a poll of available ones before that would be
unhelpful,
My earlier iteration of the PR did include a mechanism to fetch the
available emojis (and rules, eg 1 emoji per reacter per message), but
after discussion with Marvin (author), we decided that it's a bad idea,
since, as you said, most instances are probably happy to accept any
reactions.
blindly sending and seeing if they stick.
This is the current behavior described in this patch indeed. At the very
least, this PR clarifies what clients should do when they receive an
error after sending a reactions payload. I believe that the default
behavior would be "revert to previous reactions state" but we made it
"reset reactions to null" instead.
Would it work to advertise a disco feature of 'limited-reactions' so
that e.g. a MUC that's going to filter such things could advertise the
feature, and clients would know they need to fetch first, and
otherwise wouldn't need to bother?
Outside of a gateway context, this is probably something that should be
configurable by room admins, so wouldn't it be better as a muc#config
field? Clients supporting it can adapt their UIs accordingly, and
clients that don't can at least not display a bogus reaction state by
taking into accounts the <msg errors> they receive when trying to send a
forbidden reaction payload.
-- Nicoco
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
