{"action":"created","issue":{"url":"https://api.github.com/repos/jbenet/multihash/issues/14","labels_url":"https://api.github.com/repos/jbenet/multihash/issues/14/labels{/name}","comments_url":"https://api.github.com/repos/jbenet/multihash/issues/14/comments","events_url":"https://api.github.com/repos/jbenet/multihash/issues/14/events","html_url":"https://github.com/jbenet/multihash/issues/14","id":105586583,"number":14,"title":"First byte used to represent the encoding or settle on base58bitcoin-multihash?","user":{"login":"benjaminjackman","id":62048,"avatar_url":"https://avatars.githubusercontent.com/u/62048?v=3","gravatar_id":"","url":"https://api.github.com/users/benjaminjackman","html_url":"https://github.com/benjaminjackman","followers_url":"https://api.github.com/users/benjaminjackman/followers","following_url":"https://api.github.com/users/benjaminjackman/following{/other_user}","gists_url":"https://api.github.com/users/benjaminjackman/gists{/gist_id}","starred_url":"https://api.github.com/users/benjaminjackman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/benjaminjackman/subscriptions","organizations_url":"https://api.github.com/users/benjaminjackman/orgs","repos_url":"https://api.github.com/users/benjaminjackman/repos","events_url":"https://api.github.com/users/benjaminjackman/events{/privacy}","received_events_url":"https://api.github.com/users/benjaminjackman/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":9,"created_at":"2015-09-09T12:30:07Z","updated_at":"2016-01-22T23:35:47Z","closed_at":null,"body":"There probably aren't going to be that many different encodings, however consider if the first byte (shown as an ASCII char in '') represented the encoding:\r\ne.g. \r\n```\r\n'1' or 0x31 = Binary #Just put this here for fun really\r\n'2' or 0x32 = Hex\r\n'3' or 0x33 = Base32\r\n'4' or 0x34 = Base36 #Case insensitive letters and numbers\r\n'5' or 0x35 = Base58Bitcoin #Guessing bitcoin is the alphabet (e.g. not Ripple)?\r\n'6' or 0x36 = Base64\r\n```\r\netc.\r\n\r\nSo the examples from the page would change to be\r\n```\r\n# sha1 - 0x11\r\n211140beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33 # sha1 in hex\r\n324a0qvp7pqn3y3yvt5egvn3z7hdw4xeuh8tg # sha1 in base32\r\n55dqx43zNtUUbPj97vJhpHyUUPyrmXG # sha1 in base58\r\n6ERQL7se16j8P28ldDdR/PFvCddqKMw== # sha1 in base64\r\n\r\n# sha2-256 0x12\r\n212202c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae # sha2-256 in hex\r\n328g2r9nmddmfzhmfz6dmaf0x610k84u25nr690xzm3wrmqm8c9kefbg # sha256 in base32\r\n5QmRJzsvyCQyizr73Gmms8ZRtvNxmgqumxc2KUp71dfEmoj # sha256 in base58\r\n6EiAsJrRraP/Gj/mbRTwdMEE0E0ItcGSDv6D5il6IYmbnrg== # sha256 in base64\r\n```\r\n\r\nThen the multihash would be truly self-describing, instead of settling on what appears to be a de-facto base58 encoding. It would also eliminate the need for the -e parameter to the hashpipe program.\r\n\r\nI didn't work through it, but looking over all the currently generated multihashes in existence, it might be possible to implement this in a backwards compatible way, if clever characters are chosen for the different encodings such that they don't intersect with possible numbers in the wild (e.g. 1 is out because hex has it for SHAs, Q is out etc).\r\n\r\nThat of multihash might just mean `base58` in any case either the encoding should be put into the multihash or different encodings probably ought to be dropped altogether to avoid confusion and have a universal scheme, maybe some superset of the multihash called the unihash (then the multihash could be used for hash name that really do contain multiple hashes, something this doesn't quite support, but which could easily).\r\n"},"comment":{"url":"https://api.github.com/repos/jbenet/multihash/issues/comments/174087563","html_url":"https://github.com/jbenet/multihash/issues/14#issuecomment-174087563","issue_url":"https://api.github.com/repos/jbenet/multihash/issues/14","id":174087563,"user":{"login":"eminence","id":402454,"avatar_url":"https://avatars.githubusercontent.com/u/402454?v=3","gravatar_id":"","url":"https://api.github.com/users/eminence","html_url":"https://github.com/eminence","followers_url":"https://api.github.com/users/eminence/followers","following_url":"https://api.github.com/users/eminence/following{/other_user}","gists_url":"https://api.github.com/users/eminence/gists{/gist_id}","starred_url":"https://api.github.com/users/eminence/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/eminence/subscriptions","organizations_url":"https://api.github.com/users/eminence/orgs","repos_url":"https://api.github.com/users/eminence/repos","events_url":"https://api.github.com/users/eminence/events{/privacy}","received_events_url":"https://api.github.com/users/eminence/received_events","type":"User","site_admin":false},"created_at":"2016-01-22T23:35:47Z","updated_at":"2016-01-22T23:35:47Z","body":"The idea of a fully self-describing encoding is attractive, but @mildred analogy to other hash functions (where their outputs is always a fixed-length binary string) is compelling.  \r\n\r\nI suspect my desire for a self-describing format is partially due to an observation that we often use the term \"multihash\" without specifying what encoding is required.  Some examples:\r\n\r\n* Within [merkledag.proto](https://github.com/ipfs/go-ipfs/blob/master/merkledag/pb/merkledag.proto) a `PBLink` has a field that is just documented as \"multihash of the target object\", but I believe it in fact must be the binary encoding.\r\n* Within the API documentation, many arguments are describe as a multihash, but don't specify it requires base58 encoding\r\n* The files in `$IPFS_PATH/blocks` are all hex-encoded multihashes (which might be the only place we hex-encode?)\r\n\r\nIf you find this to be a weak argument, I probably would agree.  In truth, it's not very hard to figure out exactly what \"kind\" of multihash to use in each of these contexts.\r\n\r\nSo in summary, I guess I am +1 to the idea of formally defining a multihash as a function that just produces a binary string, and +1 to the idea of making it clearer what encoding is used (either by making the encodings self-describing or clear via documentation)"}}