The conflicting needs of emoji

[Mark E. Shoulson]

On 10/14/22 17:43, Mark E. Shoulson via Unicode wrote:
> I had what I thought were helpful ideas about the recent notions being 
> floated at the last Unicode meeting I attended, and maybe they're even 
> being thought about...  But although I've thought that maybe sending 
> images like this was the best of the suggested solutions, it's still 
> awful.

Just so it's on-record and for people to comment on it, let me try to 
reconstruct.

The idea under consideration was I think 
https://www.unicode.org/L2/L2016/16105r-unicode-image-hash.pdf, or 
possibly something similar; it looks like it involves having a 
Base64-encoded image plus a secure hash of some kind.  I was thinking 
that on the contrary, the thing to do is NOT have a secure hash, but 
just the image, and cache the image using a normal hash on the image 
data.  That way, later references to the image in the same document 
could include only the hash for the system to fetch from its cache and 
not have to encode all the data again.  And even better, as some private 
emoji become popular, maybe vendors will start shipping with them 
pre-cached, so the "short form" becomes something that can be used for 
interchange even without the long form (you hope.)  And "emoji servers" 
could form, websites that serve up emoji-images from a large cache so an 
even larger set of emoji can be encoded just by their hashes and not by 
their data.

Doesn't this seem like a good idea?  It tries to offload the creation 
and approval of emoji from Unicode, lets the users create their own, and 
even encourages the organic growth of infrastructure to support it.  
Maybe even shorter and shorter forms of the hash for very popular emoji 
etc.  But always with the fallback of the full-data form so it isn't 
actually dependent on the servers.

And yet with all that, it's *still* a pretty crummy idea!  It will 
always be a huge stretch to pass off anything with encoded images as 
"plain text," and hashes of images are even farther removed.  And it 
doesn't address the "meaning" animus at all.  And without that, when 
you're just doing images, not only do you wind up with potentially awful 
emoji that don't mean anything to most people (because people can't all 
draw well), you also wind up with a hundred variations on a theme, as a 
hundred different artists each give their interpretation of "CUTE 
COQUETTISH FACE WITH SMILING EYES AND COLD SWEAT" or whatever.  Consider 
the simple smiley as available from all the various different vendors.

So, yeah, potentially a good implementation for a lousy solution.

I didn't say I had answers, I'm just exploring the questions more, in 
the context of some proposals.  This is not an easy nut to crack, and 
there are conflicting desiderata, so probably any solution will be bad 
from one reasonable POV or another.

~mark