Proof of concept: parse head advertisement

[bajtos]

• Ask cid.contact for the head advertisement of the given provider
• Fetch the head advertisement from the provider
• Fetch the first block of entries from the provider
• Extract the first entry (multihash)
• Convert the multi hash to a CID v1 using the codec raw (0x55)
• Parse PieceCID from the Graphsync metadata

Look at the file poc.js, the rest are utilities & helpers.

Links:

• Spark v2: DDO, Allocators, Data Quality Improvements space-meridian/roadmap#115
• Lightweight DDO Compatibility: Spark Piece Indexer space-meridian/roadmap#143

[juliangruber]

What's not possible: convert the multihash to CID. We don't know what is the
multicodec of the payload.

Could we iterate over a list of known multicodecs?

[juliangruber]

As far as I'm familiar with the concepts, lgtm!

[bajtos]

What's not possible: convert the multihash to CID. We don't know what is the
multicodec of the payload.

Could we iterate over a list of known multicodecs?

I discussed this with @willscott. It's safe always to use the raw codec. Even if the actual payload was uploaded under a CID using a different codec (typically dag-pb), both Boost and Frisbii respond with block data when the retrieval client uses raw-codec CID in the request.

I pushed a new commit adding two more steps to the PoC script:

• Convert the multi hash to a CID v1 using the codec raw (0x55)
• Parse PieceCID from the Graphsync metadata

Example output:

PieceCID   CID(baga6ea4seaqitygl5p5fxrbqiatnowox2zwly2dvgrhpxha4lmlqplfanvjp4mq)
PayloadCID CID(bafk2bzaceaybhh2uenrbiuv4x6xywbv6oxizamydggd5r2xgnnvr53uwnjqea)

[bajtos]

Closing in favour of #7

[juliangruber]

Closing as in #1 (comment)