API's with emoji reactions reject invalid emojis. The problem is that what constitutes a valid emoji changes with Unicode releases, and so that's *yet another fucking point where emojis will break*.

API's with emoji reactions reject invalid emojis. The problem is that what constitutes a valid emoji changes with Unicode releases, and so that's *yet another fucking point where emojis will break*.

The thought process is probably "but what if someone sends an 'a'", but that's a mistake. The server doesn't need to care. Just let the client handle it because that's where emoji compatibility matters. Some systems can handle Unicode 17, others only Unicode 15. An 'a' is virtually the same as an incompatible emoji. The client must handle this case anyway.

Just think about it for 5 seconds. Why does it matter if the fucking server can understand an emoji? It's just a string, like any other text. If you didn't have a font for Kanji installed on the server, would you reject such characters as well?

You know what would be robust? Let the server take any string and maybe cap it at, idk, 20 characters. Let the clients detect what Unicode version is supported, and then add some feature negotiation where the client tells the server, so the server can finally do the filtering when the client requests data. And if Unicode version detection isn't possible (because there is no proper API for this), then just ship your own font with a known supported version and report that.

Hell, you could leave out the negotiation part and let the client drop unsupported data. Whatever floats your boat.