Status

Purpose

This document is intended to answer how the Kubo maintainers believe cid.contact should be integrated into Kubo. This is being thought about from the lens of IPFS implementations in general. This is not a new topic, but we’re at a time where decisions need to be made given the other work that has happened in Indexers and Kubo in 2022 and the recent push around 2022Q4 Hydra Dial Down.

We understand decisions need to be made and that Kubo maintainers need to commit. This is intended to aid in the decision making process, but the team will ultimately support what is decided. We expect for decisions to be made the week of 2022-11-21 2022-12-05.

Problem Summary

• Given recent developments in the crypto industry, there is renewed interest in ensuring critical crypto infrastructure is truly decentralized, and not smoke and mirrors. ****
• Kubo maintainers believe that the architecture where retrieval of all Filecoin data relies on a single centralized router at cid.contact is at odds with the basic “web3 promise” of both IPFS and Filecoin as resilient, open, and decentralized.
• Additionally, the lack of privacy-preserving routing protocol exasperates privacy concerns with IPFS. Previously one had to sybil the network like the PL EngRes hydras do to track who is requesting what. Indexers without privacy-preserving measures are now unintentionally central trackers by default.
  • This is especially the case for light client integrations like Brave Mobile (which can’t use DHT due to battery constraints): high resolution browsing history is being sent to HTTP endpoint(s) maintained by for-profit companies.
• This is not only a technical problem, but also a reputational risk to both Filecoin and IPFS.
• The way cid.contact will be integrated into IPFS routing must follow our values and protect the reputation of both projects.

Details: Reputational Risk to Filecoin (and IPFS)

Available Mitigations

There may exist compromises such as:

• Hard-coding more indexers than just cid.contact in Kubo initially, such as Cloudflare’s indexer.
  • This is a ‘only a temporary quick hack’, similar to how back in 2016, we created two shortcuts to enable js-ipfs to connect to other Browsers quickly. Six years later, we still did not remove ‘quick hack’. Let’s not repeat mistakes of the past.
• Introducing MVP Ambient Discovery (IPIP-342) that removes need for hard-coding routers on clients.
  • This would amount to:
    • add ambient protocol exposed via libp2p in Kubo (i.e., get the interface in place)
    • by default Kubo nodes will act as protocol clients but not as servers.
    • add config option such that Kubo nodes can have a hard-coded list of known routers that they share with connected clients
    • deploy PL EngRes bootstrap nodes (that Kubo nodes already have by default) with ambient-discovery server mode enabled using a hard-coded set of indexers. Other Kubo nodes will learn about these as part of being connected to the existing bootstrap nodes.
  • This saves us from another ‘quick hack’ that lasts another decade in clients whose upgrade path we can’t control.
  • We can model/measure to tune the feedback loop for fully de-permissioning routers in a second iteration.
  • Distributed nodes don’t need hard-coding of routers in their binaries and it doesn’t introduce more centralization than what’s already in the bootstraps in a sense
• Add double hashing (privacy preservation) to the HTTP delegated routing API used by cid.contact, Kubo, and others
  • Rather than taking a step back in IPFS’ privacy story as content routing request route to cid.contact, we improve it.
• Committing engineering resources to include other content routers in Kubo that make other tradeoffs, such as slower but more private content routing, lookups over libp2p instead of HTTP, etc.
  • More complex than the discovery protocol, less actionable due to bigger problem space.

Suggested path forward

Given the need for incremental progress AND the increased scrutiny web3 projects like Filecoin are under, Kubo maintainers suggest mitigating DoS and reputational risks by: