Output service hash as base58

Hey guys, I would like to propose to use base58 to output the service hash instead of the current base16 (hex).

base58 is used by Bitcoin and IPFS.
base16 (with 0x prefix) is used by Ethereum.

base58 is shorter than base16. 44 characters vs 64.
The same value represented in both way:


The marketplace url will look like:

// instead of

In the core, hash is a string, so there is no difference to use a base58. (but actually hash should be of type []byte and transformed to a string when outputted).
See: https://github.com/mesg-foundation/core/blob/b215cc4c091a1cf78fb423f5a7dfb8bca9a91a28/service/service.go#L123

The only counterargument is in the marketplace smart contract, hash is represent as a bytes32 that is compatible with string that start with 0x follow by the base16 value (eg: 0xe50b7d3bf80e522a59fd2a9b5f50b0f59062501f0ba98d29fdb30c094e806410).
But as most of the data of the marketplace are already transformed to there base16 representation, it will follow the same pattern: sid, manifest url, manifest protocol (everything that’s not a number) are already encoded / decoded from ascii to hex in the service marketplace.
Base58 value can be super easily encoded to base16 for the marketplace smart contract on ethereum by the marketplace service.

Let’s me know what you think :wink:

I just wonder if there is any good technical reason or if it’s just some cosmetic. If we have to change the marketplace to accept a new kind of sid and the reason are just cosmetic I don’t really see the necessity.

I like the cosmetic change and I think it’s good in a future because of shorter size so reducing the data on the network and also on disk but I don’t think this is a huge difference. Also transactions on the marketplace might be more expensive.

Would like to have more detail of what are the reasons to change.

Cosmetic :slight_smile:

Sid won’t be touched - do you mean hash? It won’t be touched either!

So the hash in the marketplace will still be saved on bytes64, in go it will be a slice of bytes (also over the network and inside the database).

It is just for printing (like in service list cmd or on the web/url) to make it shorter. That’s all :slight_smile:

The technical reason is independent from the output for human.
The technical improvement is to store hash as byte.
The cosmetic improvement is to show it as a shorter string using base58 because it have more “vocabulary” than base16.

There is no modification in the marketplace smart contract. The marketplace already only accept a array of 32 bytes (bytes32). The hash that we currently pass already need modification: adding and removing the 0x prefix. Using base58 will require to encode and decode the base58 value to a base16 value for the marketplace smart contract.

The hash on the network, in the proto definition, and in the service struct should be an array of byte. Same type as the hash function returned. This is completely independent of how we want to output the hash to human. Using a string to store the hash is not optimized whatever base we choose.

i’m fine with storing the hash in bytes that makes sense, for the representation then if it’s just cosmetic, the cli will manage this or the markeplace. Just the marketplace might not need to have a hash related to the service but that’s a different discussion.

So []bytes for the hash -> OK
Display with base58 (pure cosmetic) -> OK

1 Like

Implemented in this Pull request https://github.com/mesg-foundation/core/pull/849 and part of the v0.9.0