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
As of 2023-04-17, we are using dag-cbor as the codec that allows us to transform our values to binary and store them in Hyperbee (See #4).
Originally, in #9 (Explore Signing and Adding Attestations Separately to IPFS), we had planned to use dag-jose as an easy way to sign, encrypt, and hash (get the CID for) the JSON values. However, in looking more closely at dag-jose, it uses dag-codec in part, and for the signing, uses a JS crypto library which appears to be unaudited. Therefore, I think we want to continue on the path that we started rather than switch to dag-jose.
However, there is still value being able to interoperate fully with IPFS and potentially Ceramic. Currently by just using dag-cbor, the values in our key-value store have their own CIDs and could be added directly to IPFS and pinned. This is more granular than our current plan of uploading Hyperbee snapshots to IPFS, where presumably the chunking is of the file itself and independent of the contents. Ideally, Hyperbee's hash pointers would be IPLD links (aka CIDs) and Hyperbee snapshots would be internally traversable as IPLD blocks. More research is required to find the right balance between using Hyperbee as is and attempting to integrate with IPFS fully.
The text was updated successfully, but these errors were encountered:
As of 2023-04-17, we are using dag-cbor as the codec that allows us to transform our values to binary and store them in Hyperbee (See #4).
Originally, in #9 (Explore Signing and Adding Attestations Separately to IPFS), we had planned to use dag-jose as an easy way to sign, encrypt, and hash (get the CID for) the JSON values. However, in looking more closely at dag-jose, it uses dag-codec in part, and for the signing, uses a JS crypto library which appears to be unaudited. Therefore, I think we want to continue on the path that we started rather than switch to dag-jose.
However, there is still value being able to interoperate fully with IPFS and potentially Ceramic. Currently by just using dag-cbor, the values in our key-value store have their own CIDs and could be added directly to IPFS and pinned. This is more granular than our current plan of uploading Hyperbee snapshots to IPFS, where presumably the chunking is of the file itself and independent of the contents. Ideally, Hyperbee's hash pointers would be IPLD links (aka CIDs) and Hyperbee snapshots would be internally traversable as IPLD blocks. More research is required to find the right balance between using Hyperbee as is and attempting to integrate with IPFS fully.
The text was updated successfully, but these errors were encountered: