Figure out hash situation

[taoeffect]

Problem

There are several problems with the way we're hashing:

1. We're specifying the hash type incorrectly (it should be 'blake2b-256' not 'blake2b-32'), resulting in the wrong hash prefix
2. For whatever reason, the multihash people have added an extra encoding parameter to the prefix, meaning that instead of hashes that look like 2DrjgbEipReKVH8QSmAxE586CiaCtyh1GVRTaPf5d5aqCcZowc we need hashes like z2DrjgbEipReKVH8QSmAxE586CiaCtyh1GVRTaPf5d5aqCcZowc for compat with the chel command as it currently exists
3. The multihash people are unsatisfied with a simple multihash and have invented a complicated CID system. They keep changing what they're doing and it's hard to keep up.
4. The original reason for using multihash was to allow for IPFS compat, but given how our server stuff works in a rather unique way, it doesn't seem like that makes sense anymore.
5. Multihashes are difficult to identify simply by reading them. They are not human-readable.

Solution

Explore how hashes are identified in other systems. For example, SSB uses a human-readable postfix instead of a prefix.

We want something like that. There are some considerations with SSB's approach:

1. They don't use base58 which makes double-clicking the hash more difficult for copying
2. Using . as a separator also makes double-clicking an issue, but if we use base58 for everything then I'm not sure a separator is possible.

[taoeffect]

How about something like:

blake2b-256.b58=EipReKVH8QSmAxE586CiaCtyh1GVRTaPf5d5aqCcZow

Where the hash consists of:

<hash-type>.<hash-encoding>=<hash>

Thoughts @corrideat @snowteamer?

[taoeffect]

OTOH, we already have code in chel for generating the new hashes, and we could just copy that.

Being able to double-click hashes is nice.

Plus, we can identify hashes in the database by their prefix. It's just not human-readable, but maybe that isn't a big deal.

[snowteamer]

Agreed on being able to double-click hashes is nice.
If using underscores instead of dots is possible, that could preserve the ability to double-click.

In our case I'm not sure hash human-readability is a big deal either. We're not using many different hash formats anyway.

[taoeffect]

@snowteamer Yeah, agreed, we can stick with the current format. Question about that: do the changes that you made in chel result in the encoding format (in this case, JSON) being included in the hash? Or is that another change that we need to make?

I'd like to make sure that information is included in the hash.

[snowteamer]

@taoeffect IIRC, these changes result in hashes including binary-to-text encoding format (i.e. that z prefix), but nothing about text-level encoding like JSON

[taoeffect]

@snowteamer how do we add the fact that JSON was used to the hash?

[taoeffect]

Hash situation figured out!

Many thanks to @snowteamer for helping implement it in chel! Next step: implementing it here.

okTurtles/chel#21