• It seems that we’re going for a wider DHT refactor and that’s a big endeavour. I’d like to make sure we know where we’re going and we set the right expectations for what’s the outcome and what’s the timeline.
  • Do we have a design doc?
  • Do we have a list of tasks (e.g., project board or similar) that need to be done?
  • By the end of this meeting, or shortly afterwards (e.g., in the coming week(s)), I’d like us to have a list of things that need doing, an ETA and a DRI.
• Migration Plan Details: Migration Plan
  • A check on the overall migration plan.
  • Are we ok with the strategy details drafted Migration Strategy Details
• Design consideration: are we sure it is the best choice to have things “encrypted”/double-hashed with the CID?
  • Is it a solid design choice for content that will stay there for the long term?
  • Is it maybe better to have something that can rotate? Similar to credentials/passwords?

Work items

• Cross cutting
  • spec for current DHT
  • spec for reader privacy upgrade: https://github.com/ipfs/specs/pull/373
• go-libp2p implementation work
  • go-libp2p-kad-dht cleanup
    • Address test flakiness
    • Refactoring necessary code to make it easier to developer faster
    • Provider delay to 0 - make the DHT implementation more efficient
  • Provider record store
  • Provider
• rust-libp2p implementation work
• js-libp2p implementation work
• rust-libp2p implementation work
• jvm-libp2p implementation work

Option of doing Composable DHT first and doing the Privacy Upgrade later.

Risks:

• we might find out things that can’t be tested that need more work, or are broken and this will delay getting the privacy upgrade rolled out.

• some content providers might not upgrade to the privacy preserving release, because their content will be findable even if they don’t upgrade.

• How would the Composable DHT help us in upgrading to the double-hashed DHT.

• Effort needed for Composable DHT