Hi, On 06.01.2023 11:01, Kevin Smith wrote:
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?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.
Is it going to suck that bad, if the transport replies with an error message containing the set of allowed emoji? I do not think it is a terrible limitation, and for people who mostly interact with transports, their client/OS will show first the emojis they usually use, which will mostly be from the limited set. I do see the value on communicating a restricted set if clients have inline interface only showing preconfigured emoji (like signal does), requiring the user to click on the button for additional emojis each time if the ones allowed by the gateway are not in there. Cheers, Mathieu
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
