2 of 12

IPFS Content Routing WG

An introduction and look forward

Torfinn Olsen

Protocol Labs

3 of 12

There’s such a lot in the world, there’s so much distance between the fundamental rules and the final phenomenon that it’s almost unbelievable that the final variety of phenomenon can come from such a steady operation of such simple rules.

It’s not complicated, there’s just a LOT of it.

Richard Feynman on Curiosity (https://www.youtube.com/watch?v=lmTmGLzPVyM)

4 of 12

What is the IPFS Content Routing WG?��We’re a dialogue driven focal point for all parties

across the PL network and public interested in or affected by content routing planning and execution.��A place to learn the status of events across the network, participate in design discussions, or propose your own improvements.��

What is the IPFS Content Routing WG?

The IPFS Content Routing WG exists as an interface for all the parties across the network attempting to address the challenges of content routing in the network.

It’s a group discussion which occurs every 2 weeks that attempts to guide the decision making and execution processes which contribute towards an improved cross system content lookup across the entire network

We focus largely on 2 areas of effort.

Immediate efforts in flight that have to be coordinated across multiple teams. Particularly changes that have either up/downstream impacts that other teams building products benefit from knowing about in advance�.
Discussions about design decisions and broader network strategy for approaching the content routing roadmap with a eye for IPNI, DHT, Kubo related improvements.

Our true goal is about value and action alignment across all of these teams and bringing these groups together so that we’re consistently in sync with one another, and enjoy the benefits of broader group consensus and supporting efforts for the most important things they’re working on. ��Specific examples of this occurring have been IPNI cascading lookups to support retrievals, DHT cross team efforts bidirectionally likewise with readerprivacy. Lots of cross team support and discussion on specs.

5 of 12

Who are we?

To many people to name regularly join our work group

Sessions.��Broadly you can expect to see the following teams:��

IPNI
IPFS Stewards
Probelab
Bifrost

Special guests:�

IROH
The general public
Interested IPFS folks�

6 of 12

Why should you care?

The current state of Content Routing across the Network:��

What content routing looks like rn:

Kad-DHT - the indomitable force of good plugging along as reliably as ever.

The Hydras(DHT nodes designed to accelerate the content resolution and content providing on the IPFS network) still perform a bridging function for the network inspite of having their database pipeline(dynamoDB) severed. As v0.18 deploys further across the IPFS ecosystem the benefits of bridging are a diminishing return. ��As Delegated content routing deploys to nodes across IPFS there is now a path of lesser resistance to pass lookups particularly for large content providers.

HTTP delegated content routing makes it easier for large content providers to leverage industry standard tools such as HTTP load balancers, CDN’s and reverse proxies using standard HTTP idioms and payload encoding.�

Reframe in Kubo will be deprecated in the next release and delegated content routing will subsequently use this HTTP API. We may decide to re-add Reframe support in the future once these issues have been resolved.-

IPNI value store(CIDs:peerID’s) is ~1.4 Trillion key IS HUGE:value pairs growing roughly at a rate of ~30 billion a week. 5.4 TiB The IPNI also now has the ability to search alternative routing systems through familiar IPNI endpoints via ‘cascade’ (specify a list of comma separated alternate routing systems). https://github.com/ipni/specs/pull/9��We currently ingest advertisements from ~600 providers,

Kubo v0.18 is configured by default to lookup records on the DHT and IPNI and Production bifrost cluster is hardcoded to default to cid.contact for lookups.�

7 of 12

The look forward for IPNI [What’s currently on our plate?]

< 2.5 months

Indexer edge node service(cache)

Deploying an edge node service with the necessary API calls to perform self synchronous value store replication

End of H123

Deploy edge node service to Saturn L1s

Pushing the cache strategically to station nodes would deeply benefit from the decentralized nature of these nodes, and possibly ride the coat tails of their incentive system

< 1 month

Double Hashed Value Store(Reader Privacy)

Moving our presently operating double hashed value store ‘DHStore’ over to fulfilling production cid.contact queries.

< 2 months

Monitoring of Index Operator instances

Leveraging the public endpoints we can validate the depth of an IPNI instances adchain and recognize how closely in sync they are to our reference image at cid.contact

Masih did an excellent deep dive into the accomplishments of IPNI so I wont belabor the point but from a content routing perspective these items track our near term goals.

Later on today you’re going to hear a lot of details about DoubleHashing and reader privacy. We’re on the cusp of a number of breakthroughs that will greatly enhance the privacy of the network. These are nearer term goals that our users will enjoy the benefits of almost immediately. We additionally have some work to do in order to provide them the guidance necessary to leverage these benefits.��We’ve also got new capabilities being released presently that Andrew is going to tell you more about enabling Content Advertisement Mirroring. I won’t steal his thunder but the big takeaway you should leave today with is that bootstrapping a new instance of an indexer and syncronizing it with cid.contact(the true reference image) will be an efficient process.

8 of 12

What does the broader Content routing wg roadmap look like

Bitswap provider search delays and Peer routing optimization

Working towards a content routing system when there aren’t always long lived desktop nodes with well connected swarms

Ambient Discovery - Federated Network of Indexers

With monitoring and syncronization under our belt, as well ambient discovery of nodes we can direct content lookups to different indexer instances using a handful of criteria

DHT refactoring by Probelab with some IPNI support/DHT Migration strategy

Really acting on seeing through double hashing efforts across the entire network not just isolated to cid.contact.

Delegated Content Routing /PUTs

Writing to the indexer simply over HTTP opens up a world of options and content routing fluidity. This also opens up IPFS ephemerally publishing content.

You’ve just heard about all the amazing accomplishments of cid.contact, but what’s ahead for us?

Provider search delays and peer routing optimization: We want to rely less on bitswap gossip for content routing. Goal is to reduce the reliance and not necessarily the optimization itself. We can reduce the scope of jobs that are required to support this effort. (Make infura hate us less 😂 ) We’re focused on the server not the client. THERES A BIGGER GOAL HERE: we need a content routing system that’s able to function when there aren’t long lived desktop nodes with well connected swarms. Moves towards delegated routing and getting content into those things weens us off this dependency on well formed bitswap mesh.(however, in an event you’re relying on bitswap for content discovery you’re not actually getting that anyhow a bit of bumping into the node).

Long tail optimization of peer routing functions. For lookups that continue to bypass the IPNI lookup times are very long. We can create some functionality for which helps the network self repair routing tables to support reducing secondary lookups. (Is there a way to run a kubo node without a DHT in it) - one way to do this is peer routing. Peer routing, interface libp2p mapping peerID to address, vs roots of DAG being advertised and CID’s below the root are discoverable via bitswap spam and not discoverable by IPNI and DHT.

9 of 12

So what does a Federated Network of IPNI nodes look like?

We’ve actually got a pretty good head start, although some might say North America is possibly “overindexed” comparatively with representation of lookups in South America, Africa, Europe and the Middle East.

10 of 12

What kind of design discussions can you expect in the future from the content routing wg?

Index operator discussions and feedback - how we incentivize these behaviors and participation! Modeling the cost of operating indexer instances with relation to forecasted growth while respecting improvements.

Ambient discovery of IPNI nodes by (starting to exam client code around supporting this)

Leverage Rhea/Lassie as a staging ground

Client agnostic interfaces focused on what the clients want to do.

You’ve just heard about all the amazing accomplishments of cid.contact

Make Reprovide process Content Router Specific https://github.com/libp2p/go-libp2p-kad-dht/issues/824 & https://github.com/libp2p/go-libp2p/issues/2175�

IPFS implementation is responsible for reprovide of CID, we think this is the wrong abstraction we suspect that content routers should have int to start and stop advertising of content. DHT and IPNI have different publish/provide mechs its not IPFS implementations role to care about this. Kubo should start and stop, content routers should republish or choose to republish.

Breaking interface change that needs to be coordinated before we make any commitments.�� NOT talking about relaxing TTL just an implementation interface. Content publishing with indexers should be clarified. You don’t have to republish at all vs the DHT. Republish every 24hrs to DHT vs Indexer once. - Should the indexer have a TTL? - Ephemeral accessibility of data(consider IOT sensor like time based reporting without reproviding disappears). - Benefit of doing this with IPNI you can do it at a high scale. - TTL shifts the burden of calling the delay function. TTL forces a semi frequent interaction)bandwidth vs storage TTL bias towards bandwidth - With IPNI the barrier for staying discoverable is once a week or something infrequent so it’s not a huge trade off. What’s the amount of work someone needs to do to stay viable. - Cost of deletion for IPNI is BIG - Opportunistic deletion of multihashes queried vs stored. Data store has a lot of unneccessary baggage. Explicit deletion doesn’t help that. - TTL mech could reduce complexity on the back-end to optimize storage and have mechanisms with worst case storage(rate of pub of recs never goes beyond xtime vs pubs over x+n time). - Is the idea to enforce the TTL globally? - Lowest barrier of adoption have IPFS nodes publish to IPNI(right now would have to be graphsync to HTTP) - compared to IPNI DHT int just works(new idea). - Get the time based records from DHT to IPNI - - Interface flexibility swappable and irrelevant to the client and the INT is focused on what the client wants to do. Each content routing system would need to have one and a shared INT on which we need to agree upon - start/stop providing with timelines. - HTTP delegated routing sort of does this consider a nested layer of delegation(provide on a periodic basis).�

11 of 12

We ENCOURAGE participation!

Join our slack for the latest: #ipfs-content-routing-wg there are routine updates and deep discussions frequently occurring in this space.

Participate in a discussion: https://lu.ma/ipfs-routing-wg or watch prior discussions on our youtube: https://www.youtube.com/playlist?list=PLuhRWgmPaHtRP5lVouK_eqhC98xaej6Px

Check out our notion for in depth details around our discussions and the actions that result from them/status updates.https://www.notion.so/pl-strflt/Content-Routing-Workgroup-e59fa94a9c3f48d58480b7daf15bd356?p=3a97d53aaddc40e5bc7daa43e9b5d3c4&pm=s