New RFC: CODEX-MANIFEST #191
Conversation
emizzle
left a comment
emizzle
left a comment
There was a problem hiding this comment.
I'd rather see the Rationale section of the original spec in the Background, since it is more cohesive and in depth.
Also, there are some functional and non-functional requirements from the original spec that could be translated into specs here.
| In version 1 of the BitTorrent protocol a user wants to upload (seed) some content to the BitTorrent network, | ||
| the client chunks the content into pieces. | ||
| For each piece, a hash is computed and | ||
| included in the pieces attribute of the info dictionary in the BitTorrent metainfo file. |
There was a problem hiding this comment.
This can be removed, but I think it was a good intro to how the Bittorent metainfo file is constructed compare to the Codex manifest. Also helps reader get introduced to the concepts.
| The Codex manifest provides the description of the metadata uploaded to the Codex network. | ||
| It is in many ways similar to the BitTorrent metainfo file also known as .torrent files, | ||
| (for more information see, [BEP3](http://bittorrent.org/beps/bep_0003.html) from BitTorrent Enhancement Proposals (BEPs). | ||
| While the BitTorrent metainfo files are generally distributed out-of-band, | ||
| Codex manifest receives its own content identifier, [CIDv1](https://github.com/multiformats/cid#cidv1), that is announced on the Codex DHT, also | ||
| see the [CODEX-DHT specification](./dht.md). | ||
|
|
||
| In version 1 of the BitTorrent protocol a user wants to upload (seed) some content to the BitTorrent network, | ||
| the client chunks the content into pieces. | ||
| For each piece, a hash is computed and | ||
| included in the pieces attribute of the info dictionary in the BitTorrent metainfo file. | ||
| In Codex, | ||
| instead of hashes of individual pieces, | ||
| we create a Merkle Tree computed over the blocks in the dataset. | ||
| We then include the CID of the root of this Merkle Tree as treeCid attribute in the Codex Manifest file. | ||
|
|
||
| In version 2 of the BitTorrent protocol also uses Merkle Trees and | ||
| includes the root of the tree in the info dictionary for each .torrent file. | ||
|
|
||
| The Codex manifest, CID in particular, | ||
| is the ability to uniquely identify the content and | ||
| be able to retrieve that content from any single Codex client. |
There was a problem hiding this comment.
Why not use the Rationale section from the component spec instead? These paragraphs lack depth that is presented in the component spec.
There was a problem hiding this comment.
Yes, this info came from the rationale section, I just titled it Background. Updating the title of section to Rationale is probably better.
codex/raw/manifest.md
Outdated
|
|
||
| | attribute | type | description | | ||
| |-----------|------|-------------| | ||
| | `treeCid` | string | A hash based on [CIDv1](https://github.com/multiformats/cid#cidv1) of the root of the [Codex Tree], which is a form of a Merkle Tree corresponding to the dataset described by the manifest. Its multicodec is (codex-root, 0xCD03) | |
There was a problem hiding this comment.
protobuf shows this as bytes, also the codex specs as well
There was a problem hiding this comment.
actually most of the fields have wrong types here
codex/raw/manifest.md
Outdated
| @@ -0,0 +1,94 @@ | |||
| --- | |||
| title: CODEX-MANIFEST | |||
| name: Codes Manifest | |||
|
@jimstir can you please check the comments and fix linting issues? |
Co-authored-by: Eric <[email protected]>
Co-authored-by: Eric <[email protected]>
|
@emizzle The other functional requirements I think you are referring to, like how a file would be downloaded with the manifest from the network, I don't think should be added to this spec. |
RFC for Codex manifest....