Replace all string hash with []byte

[krhubert]

TODO:

• fix tests
• create type Hash []byte and implement New and String methods

[mesg-bot]

This pull request has been mentioned on MESG Community. There might be relevant details there:

https://forum.mesg.com/t/2019-06-19-update/316/4

[NicolasMahe]

Good idea to create a dedicated type 👍

[NicolasMahe]

@krhubert please next time you create a PR not finished, set the PR in WIP using this new GitHub feature ;)

[krhubert]

@mesg-foundation/mesg-core-team

Please review this PR (especially hash/hash.go implementation) and if everything is ok I will just replace:

• every hash definition from []byte to hash.Hash
• base58.Decode with hash.Decode
• base58.Encode with hash.String()
• []byte{0|1} with hash.Int(0|1)

What I don't like is the fact that hash.Hash is in our repository and in std golang package, but:

• I couldn't find a better name (this one is perfect but will have a conflict with std hash.Hash)
• probably nobody will ever use hash outside packages that calculate the hashes.

[NicolasMahe]

I valid the implementation of hash that you did 👍
The API of the package is simple.
I like that there is 2 type: Digest to generate the hash (and it's only overriding Sum function of sha256) and Hash to convert []byte from and to string.
I don't mind having the same name as std Hash.Hash..

[antho1404]

Good job with the hash.
Can you resolve the conflict?

Also, there is a big breaking change here which is removing the support of the sid.
I'm totally ok to use hashes everywhere that simplifies a lot but let's make sure that the apis are still working with sid resolution.

Maybe a FindBySid method on the database that returns a list of services and every api will call this function first to convert the sid to the right hash. This can go in another PR

[krhubert]

Can you resolve the conflict?

Done

I'm totally ok to use hashes everywhere that simplifies a lot but let's make sure that the apis are still working with sid resolution.

Nope, I asked @NicolasMahe and said he talked to you about the sid removal and you have agreed on this. Also, you said that sid/hash resolution should be on the client side, not in the core.

The one condition I started working on this was dropping support of sid in the api.
Keeping the sid support requires a lot of changing in the databases, passing the right parameter down to database etc.

If you want sid support it won't be done in this PR (I don't know if it will be done at all because it's pretty hard to introduce such support).

[antho1404]

I valid but we still need the support of SID and this doesn't need to be done at the database level but just at the api level. But let's merge this one, then do some cleanup on the API and reenable the sid support

[mesg-bot]

This pull request has been mentioned on MESG Community. There might be relevant details there:

https://forum.mesg.com/t/new-grpc-nameservice-api/324/1

[NicolasMahe]

I valid but we still need the support of SID and this doesn't need to be done at the database level but just at the api level. But let's merge this one, then do some cleanup on the API and reenable the sid support

I created to forum post to continue this discussion: https://forum.mesg.com/t/new-grpc-nameservice-api/324