Review the hashlink hash in the linkset for data URI

[troyronda]

In cases where the data URI contains a compressed linkset, should the hash be on the compressed version or the plain-text version?

As a comparison:

• if the URI was HTTPS and the content type was gzip then the hash would be on the gzip.
• if the URI was HTTPS and the content type was application/json then the hash would be on the plan-text.
• if the URI was HTTPS and the content type was application/json AND the content-encoding was gzip then the hash would still be on the plain-text.

So in the data URI, do we treat its type as content-encoding or as content-type?

Currently we are treating as content-encoding, so the hash is on the plain-text.

[bstasyszyn]

In HTTP, you have Content-Type (e.g. application/json) and Content-Encoding (e.g. gzip). In the data URI, the media-type mixes the two concepts, e.g. application/json and application/gzip. With Orb data URIs the content-type is always JSON but the content encoding can be:

• URL-encoded (e.g. data:application/json,,%7B%22linkset%22%3A%. . .)
• Gzip and base64-encoded (e.g. data:application/gzip;base64,H4sIAAAAA. . .)

I believe that the hash should be on the canonicalized JSON before it is encoded. This way, the hash does not change with the encoding. So, I believe that the current implementation is correct.