Agenda

Important reference documents:

• cid.contact in Kubo
  • Double Hashing and IPNI / DHT Reader Privacy Upgrade (Double Hashing)
• https://cid.contact/
• IPFS Async discussion with leadership on Kubo integration

Purpose of Meeting 5m:

To conclude the decisions needed in order to design the MVP for indexer Kubo inclusion.

Topics to cover 30m:

• HTTP Delegated Routing rollout to Kubo and gateways

  • https://github.com/ipfs/go-delegated-routing/issues/63
  • https://github.com/ipfs/kubo/issues/9150
  • Will we complete this integration by EoY? We accomplished this with reframe but there were issues with reframe API.
    • We are dialing down non-bridging portions of hydras Thursday #probe-lab leading(severing DB pipeline between hydras and dynamoDB).
    • No hydra deployments for a handful of days before and after requested.
    • Not deploying hydras with HTTP delegated routing until Dec 8, doesn’t block Indexer efforts.
    • Need approval on the implementation Indexer team has proposed for review to IPFS stewards team(linked above). Will live in go/libIPFS repo. It’s easier for IPNI team to own this code, so we just need the review completed by @Gus Eggert targeting EoW 12/02/22. -see: ‣

• Commitment to doublehashing design pathway.

  • Decision: Can Bedrock propose a delegated routing double-hashed findProviders method? Are there other stakeholders that need to sign off?

• (Timeline for implementation of doublehashing which is a deliverable required for integration to Kubo). Please keep in mind these are still under analysis.

  • There are 2 options being discussed dependent on making a determination for handling provider record encryption:
    • A) Have an access to the original CID so that we can encrypt a peerID on demand.
      • This scenario requires storing both a hashed(lookups) as well as raw CID(encryption). This costs us 32 bytes for each multihash, or at the present rate of 30b new CIDS per week 1.6TB/wk additional storage. Additional compute and storage costs added to read path as well.
    • B) encrypt peerID upfront for each CID on ingestion. Encrypted peerID grows O(N * P), where N is a number of CIDs and P is a number of providers.

Outcome:

Ingestion is still outstanding but async decision on direction for indexer ingestion/hashing is fully analyzed and ready to propose to the team. Ingest spec lives in IPNI/specs.