Replace `content-type` and `image` fields with `url`

[Boldewyn]

Re: Coded Hashes of Arbitrary Images, representation of the payload.

The data: URI scheme allows to encode images in a JSON compatible way all the while preserving the mime type information:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAACklEQVR4nGMAAQAABQABDQottAAAAABJRU5ErkJggg==

or

data:image/svg+xml,<svg%20xmlns="http://www.w3.org/2000/svg"></svg>

It might be worthwhile to consider allowing url as a replacement for content_type + image, either additionally (either one or the other two) or exclusively. The url field could be restricted to the data: scheme initially, until security implications of opening up the field for https? are considered.

One advantage of this syntax is that web-based consumers of the definition can copy the data of the url field directly, dump it into an HTML <img> and it will work.

Also, this syntax is a little bit shorter than the two-field syntax, which might sum up for a library of many thousand emoji:

"url":"data:image/png;base64,..."
"content_type":"image/png","image":"..."

[Boldewyn]

Another advantage, that I thought of just now: With name and url as sole keys, and name being unique (assuming a single "emoji registry"), the representation of lots of emoji could basically be represented as a simple key-value map:

chai => data:image/png,...
full moon => data:image/png,...
person_waving_hands => data:image/png,...

This can be easily expressed in JSON, but also in SQL, XML or whatever other flavour a consumer would need to performantly access emoji from a registry.

[keithw]

The representation was intended to be a strawman; I don't think we're that sensitive whether it has two fields (type and image) vs. a single field (url with a mandatory data: schema that specifies the type and also encoding (base64). Your proposal is also fine!

I would be less thrilled about an arbitrary (e.g. http) URL; the point of this proposal is that the hash is a secure digest that _uniquely _identifies__ the image, not just the location of an image resource that could change with time.

Similarly, I don't like the idea of a single "emoji registry"; the point here is that _any _implementer__ can create their own emoji (and some apps would probably let users create their own emoji). The globally-unique identifier is the secure hash, and as long as the receiver can somehow lay their hands on an emoji description that matches the hash (no matter where it comes from), they will be able to display the correct image.

[Boldewyn]

Similarly, I don't like the idea of a single "emoji registry";

Completely d’accord! I just formulated that idea quite unfortunately. What's meant is, that for any one of possibly many registries / implementers the name field is likely to be unique.

The representation was intended to be a strawman;

I was aware of that, but at the same time I see lots of "example, do not use" code samples copied verbatim into production code... So I figured, when the draft gains momentum, and implementers start working based on it, it's likely that the strawman becomes a factual base for the underlying code.

[srl295]

@Boldewyn missed this, but thanks for the comment. I will review.

[srl295]

@Boldewyn Name is not necessarily unique, much like the 'display name' of a user on a site (such as Github) may not be unique, it's the identity (userid or hash) that needs to be unique.

[Boldewyn]

Got that.

Is there any new movement with the proposal currently? I'm still eager to see advantages in the realm of emoji encoding, and if I can help with any input or other work, I'd gladly do so.