------ Original Message ------
From "Nicolas Cedilnik" <[email protected]>
To [email protected]
Date 06/01/2023 06:12:36
Subject Re: [Standards] XEP-0444 update: restrict reactions
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.
I guess the question is "Do we want 'normal' services to be able to have
limited emoji sets?". If we do, then requiring users to keep sending
reactions and getting errors back until they find one that's supported
is clearly not a reasonable approach. If we don't, are we happy that the
experience interacting with transports is basically going to suck?
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,
I'm not sure that's true, I could see this being a system-wide config,
but I don't think it's directly relevant to how they're advertised.
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.
That wouldn't help things that aren't MUC rooms, and I don't see why
entire services mightn't limit the available emoji, if rooms might.
/K
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
