{"action":"created","issue":{"url":"https://api.github.com/repos/ipfs/go-ipfs/issues/5349","repository_url":"https://api.github.com/repos/ipfs/go-ipfs","labels_url":"https://api.github.com/repos/ipfs/go-ipfs/issues/5349/labels{/name}","comments_url":"https://api.github.com/repos/ipfs/go-ipfs/issues/5349/comments","events_url":"https://api.github.com/repos/ipfs/go-ipfs/issues/5349/events","html_url":"https://github.com/ipfs/go-ipfs/issues/5349","id":348199579,"node_id":"MDU6SXNzdWUzNDgxOTk1Nzk=","number":5349,"title":"RFC: Handling of Alternative Multibases","user":{"login":"kevina","id":1271492,"node_id":"MDQ6VXNlcjEyNzE0OTI=","avatar_url":"https://avatars2.githubusercontent.com/u/1271492?v=4","gravatar_id":"","url":"https://api.github.com/users/kevina","html_url":"https://github.com/kevina","followers_url":"https://api.github.com/users/kevina/followers","following_url":"https://api.github.com/users/kevina/following{/other_user}","gists_url":"https://api.github.com/users/kevina/gists{/gist_id}","starred_url":"https://api.github.com/users/kevina/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kevina/subscriptions","organizations_url":"https://api.github.com/users/kevina/orgs","repos_url":"https://api.github.com/users/kevina/repos","events_url":"https://api.github.com/users/kevina/events{/privacy}","received_events_url":"https://api.github.com/users/kevina/received_events","type":"User","site_admin":false},"labels":[{"id":993502733,"node_id":"MDU6TGFiZWw5OTM1MDI3MzM=","url":"https://api.github.com/repos/ipfs/go-ipfs/labels/cidv1b32","name":"cidv1b32","color":"9165d8","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":12,"created_at":"2018-08-07T07:27:24Z","updated_at":"2018-08-28T00:53:02Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"As we switch to using CidV1 base32 encoding the question is how we should handle this displaying of CID in alternative multibases.\r\n\r\nThis issue is only about the output.  For the input will we already handle CIDv1 in any base supported by `go-multibase`.\r\n\r\nHere are the alternatives, as I see it, and what I estimate it will take to do it.\r\n\r\n### 1. Don't Preserve the multibase, Use Settings or Defaults to determine multibase\r\n\r\nAccept CidV1 in any multibase, but ignore the base that is used.  Output the CIDs based on either a global `--cid-base` flag or a config value.\r\n\r\nThis means that the string a user passes in may not be the same string that is returned.  For example\r\n```\r\n$ ipfs pin add zb2rhfwrxLo7wm3ZT2ishCdimPKWdRCe3KuxHFQYMR8Kyj96x\r\npinned bafkreiekhi5qqy64ovh7jckh5ewnyt6lcvfzqfubv3l66cazo5dknu6dre recursively\r\n```\r\n\r\nThis also means that https://github.com/ipfs/go-ipfs/issues/5234 (ipfs resolve should respect CID base) will not be implemented.\r\n\r\nThe most straightforward way to implement this is replacing every call of `cid.String()` with something like `cid.Encode(base)` (see https://github.com/ipfs/go-cid/pull/60) and make sure the base is available at the point when this method needs to be called.  The `WithValue` functionally on contexts can be helpful here.\r\n\r\nAs most CID's are converted to strings on the server side, rather than the client, doing a quick hack such as setting a global variable is not going to work.\r\n\r\nAnother way to implement this, at least when working with the API, is to modify our API to make CID's a special type and then set the multibase as part of the writer that formats the output for this user.  This means extra CPU cycles as the CID is converted from a binary represenation to a string twice.  If we go this route I recommend the API be hardcoded to use `base32` as is a more efficient encoding than our current default of `base58btc`.\r\n\r\n### 2. Preserve the multibase.  Children of DAGs inherit multi-base of parent when known.\r\n\r\nWhen a CID is decoded preserve the multibase used with the CID so when it is converted back to a string the same multibase will be used.  In addition associate the CID of any children of the DAG with the same multibase prefix.  When a CID does not have a multibase associated use the settings from the command line or config option.\r\n\r\n`ipfs pin add` will then display the same base.  In addition commands like `ipfs ls` will use the same base to display directory entries as the hash used for the parent.\r\n\r\n```\r\n$ ipfs ls f017012205be9e545b52def2d18a922146c6cdec6bcbf4007b6ee7bec3341673bbf1d8c06\r\nf01551220f6ba0f2491f2371dee0ea66e8812331b78f162697d2f41b5d55b667e5ae6bc67 3606  diff.go\r\nf01551220e43f16413e6e1aa73eee0194d40363b7082d06faae8d6e94f18bd5f8cc08dfee 18299 object.go\r\nf015512201985aa3462ff163c46de0f5e6634bde41f2bd537780ccbe5401aea1cccc49577 9057  patch.go\r\n```\r\n\r\nImplementing this will involve associating a multibase with CID's when it is known (see https://github.com/ipfs/go-cid/pull/66).  It will also involve setting the multibase of children CID's in the DAG code.  New CID's will also need to get the base set somewhere.\r\n\r\nAfter thinking about this I think this will involve _less_ code change than #&#xfeff;1 as the base does not need to be set everywhere, although the changes may not be as straightforward.\r\n\r\nI think this is the most user friendly approach.\r\n\r\n### 3. Attempt to Preserve the multibase.\r\n\r\nThis solution does not store the multi-base with the CID but makes an attempt to output the same multibase on a ad-hoc bases.  For the current implementation of `ipfs resolve` it turned out to be easy.  `ipfs pin add` is more difficult.  It was in fact after looking at `ipfs pin add` that I decided that #&#xfeff;2 will be required to do it properly, especially when multiple CIDs are given on the command line.\r\n\r\nImplementing this involves doing #&#xfeff;1 and in addition detecting the multibase of any CIDs used and setting and using the correct base for the output.  Things can get tricky when CID's with different mutlibases are used at once.  This will involve more code that either other solution.\r\n\r\nhttps://github.com/ipfs/go-ipfs/pull/5289 started effort towards this solution (see the code for `ipfs resolve` and `ipfs ls`)\r\n\r\nI do not like this solution as it will only work some of the time and prefer we go with #&#xfeff;1 or #&#xfeff;2 for more predictable output.\r\n"},"comment":{"url":"https://api.github.com/repos/ipfs/go-ipfs/issues/comments/416415099","html_url":"https://github.com/ipfs/go-ipfs/issues/5349#issuecomment-416415099","issue_url":"https://api.github.com/repos/ipfs/go-ipfs/issues/5349","id":416415099,"node_id":"MDEyOklzc3VlQ29tbWVudDQxNjQxNTA5OQ==","user":{"login":"kevina","id":1271492,"node_id":"MDQ6VXNlcjEyNzE0OTI=","avatar_url":"https://avatars2.githubusercontent.com/u/1271492?v=4","gravatar_id":"","url":"https://api.github.com/users/kevina","html_url":"https://github.com/kevina","followers_url":"https://api.github.com/users/kevina/followers","following_url":"https://api.github.com/users/kevina/following{/other_user}","gists_url":"https://api.github.com/users/kevina/gists{/gist_id}","starred_url":"https://api.github.com/users/kevina/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kevina/subscriptions","organizations_url":"https://api.github.com/users/kevina/orgs","repos_url":"https://api.github.com/users/kevina/repos","events_url":"https://api.github.com/users/kevina/events{/privacy}","received_events_url":"https://api.github.com/users/kevina/received_events","type":"User","site_admin":false},"created_at":"2018-08-28T00:53:02Z","updated_at":"2018-08-28T00:53:02Z","author_association":"CONTRIBUTOR","body":"> Won't that cause problems with CIDv0?\r\n\r\nI am still of the option that will should just allow multibase prefixes on CidV0.  @whyrusleeping was against it but I discussion feels unfinished as I do not see how it can cause harm.\r\n\r\nHowever, since we made that discussion that multibase prefixes on CidV0 are not allowed, CidV0 will simply remain the same while CidV1 will be converted to `APICidJSONBase`.  I am against the idea of upgrading CidV0 to CidV1 except at the U.I. level as it is not technically correct."}}
{"actor":{"display_login":"kevina"}}