Add CIDs for IPFS and Swarm #104
Conversation
|
Ping? |
table.csv
Outdated
| @@ -447,3 +447,7 @@ leofcoin-pr, Leofcoin Peer Reputation, 0x83 | |||
| torrent-info, Torrent file info field (bencoded), 0x7b | |||
| torrent-file, Torrent file (bencoded), 0x7c | |||
| ed25519-pub, Ed25519 public key, 0xed | |||
|
|
|||
| CIDs,, | |||
There was a problem hiding this comment.
Maybe "content namespaces"?. We're not really defining new types of CIDs.
- ipld-ns: [/arbitrary/path]
- ipfs-ns: [/arbitrary/path]
- swarm-ns: [byte range?]
We could also merge #93 to allow arbitrary string paths (although we don't have to do it that way).
Basically, I'd like to make this as flexible as possible.
There was a problem hiding this comment.
Can you elaborate on what an IPLD NS would encode, as opposed to an IPFS-NS? Would it be a CID, or some other data format?
There was a problem hiding this comment.
I'm just taking string paths and encoding them in a compact binary form.
/ipld/SomeStringCID/some/remaining/path-><ipld-namespace-multicodec><binary-cid><path>/ipfs/SomeStringCID/some/remaining/path-><ipfs-namespace-multicodec><binary-cid><path>
So these will both be CIDs + Paths.
We need different namespaces because IPFS is built on top of IPLD. In IPFS, we' interpret the content as files and directories and the path a traversal through a directory tree. In IPLD we interpret the content as structured data and the path as a traversal through a JSON-like datastructure.
For the swarm namespace, I wrote [byte range?] as you may want to allow for a byte range in addition to the CID.
There was a problem hiding this comment.
How are paths encoded, in this scheme?
There was a problem hiding this comment.
As a string although we may want to length-prefix these strings.
Regardless, we can probably skip that for now. The important part here is to reserve these numbers. Regardless of what we say now, we'll probably change our minds when we actually try to prototype these.
There was a problem hiding this comment.
(If you'd like to avoid the github round-trip, you can ping me on the #ipfs IRC channel, also #ipfs-dev:matrix.org. Unfortunately, we don't have an active multiformats channel.)
table.csv
Outdated
| @@ -447,3 +447,8 @@ leofcoin-pr, Leofcoin Peer Reputation, 0x83 | |||
| torrent-info, Torrent file info field (bencoded), 0x7b | |||
| torrent-file, Torrent file (bencoded), 0x7c | |||
| ed25519-pub, Ed25519 public key, 0xed | |||
|
|
|||
| Content Namespaces,, | |||
| ipld-ns, IPLD CID and optional path, 0xee | |||
There was a problem hiding this comment.
We can be a bit more abstract here and just say "IPLD path", "IPFS path", and "Swarm path" instead of specifying the precise format for the argument. That is, we know we'll use <namespace-codec><stuff...> but we can decide on <stuff...> later.
For example, swarm probably won't want arbitrary paths (it doesn't support directories, as far as I know. Instead, it will at most want byte ranges (e.g., /swarm/CID or /swarm/CID/0..200).
There was a problem hiding this comment.
Swarm does support paths, in a similar fashion to IPFS, by storing manifest files.
There was a problem hiding this comment.
Ah, got it. I just saw the docs on Swarm-Hash and assumed it was blob-only.
There was a problem hiding this comment.
In that case, I there is some value in trying to standardize on a binary format for content paths up-front. My thinking was just <namespace-codec (varint)><binary-cid><string-path> (where <string-path> is an optional /a/b/c...). Thoughts?
(we can also discuss this in a separate issue if you'd like).
There was a problem hiding this comment.
That seems reasonable. I liked the suggestion of reserving / as the multicodec for "path component". I think this'd be best discussed in its own issue, though.
|
@Stebalien I just noticed that the 0xf0 codec is already in use. Not sure what should be done about that |
|
I had one job... I guess it's time to give in to our robot overlords. Fix and CI in: #113 |
As discussed in multiformats/multiaddr#73 and offline.