You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 19, 2024. It is now read-only.
Phase 2 of IPCR will be refactoring the existing IPFS/unixfs registry data model into an IPLD data model (OCI ADL, codec, etc). In general this transition should include the following:
remove/address mapping between SHA256 and IPFS CIDS that currently takes place. Because the "hash sum" of an IPFS file is the root of an underlying merkle dag, it doesn't deterministically map to the traditional sha256 hash sum. (ie. shasum -a 256 <file>). Working this into the ADL/Codec would be the most ideal. The alternative would be to have replace the sha sums with the CID sums in the registry itself... not impossible, and perhaps more "IPLD-ish", but further reaching into the registry codebase.
ideally has an interface to do IPLD querying/traversal by name/version, for example nginx:v1.2
as with version 1, this version of the registry must work with the native Docker client - all of the integration should happen in the registry itself, allowing for a transparent experience to the end user
As this develops, it is also a good idea to document best practices in generating new hashlinked structures with IPLD for Estuary consumption. (ie. a github template project)
The text was updated successfully, but these errors were encountered:
Phase 2 of IPCR will be refactoring the existing IPFS/unixfs registry data model into an IPLD data model (OCI ADL, codec, etc). In general this transition should include the following:
shasum -a 256 <file>
). Working this into the ADL/Codec would be the most ideal. The alternative would be to have replace the sha sums with the CID sums in the registry itself... not impossible, and perhaps more "IPLD-ish", but further reaching into the registry codebase.nginx:v1.2
As this develops, it is also a good idea to document best practices in generating new hashlinked structures with IPLD for Estuary consumption. (ie. a github template project)
The text was updated successfully, but these errors were encountered: