Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

IPIP-342: Ambient Discovery of Content Routers #342

Open
wants to merge 15 commits into
base: main
Choose a base branch
from
Open

IPIP-342: Ambient Discovery of Content Routers #342

Changes from 1 commit
Commits
Show all changes
15 commits
Select commit Hold shift + click to select a range
25abd6d
Propose a spec change for automatic discovery of content routers.
willscott Nov 12, 2022
2585578
Update IPIP/0000-content-router-discovery.md
willscott Nov 13, 2022
1202cdf
update with ipip number
willscott Nov 15, 2022
92cf422
Merge branch 'feat/content-router-discovery' of github.com:ipfs/specs…
willscott Nov 15, 2022
07710d5
Some updates in response to @ajnavarro's review
willscott Nov 17, 2022
8ac57d9
Address code review comments
willscott Nov 18, 2022
e558e66
further elaboration of protocol.
willscott Nov 20, 2022
d79bb40
Apply suggestions from gui
willscott Nov 23, 2022
d99131a
Apply suggestions from code review
willscott Nov 30, 2022
b033bee
Merge remote-tracking branch 'origin/main' into feat/content-router-d…
willscott Jun 2, 2023
b05960a
update format
willscott Jun 2, 2023
b6a3611
lint
willscott Jun 2, 2023
8174cea
chore: editorial tweaks to enable HTML render
lidel Aug 8, 2023
6c837cc
Update ipip-0342.md
willscott Sep 19, 2023
88dd4de
correcting typos
guillaumemichel Sep 20, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
68 changes: 57 additions & 11 deletions IPIP/0342-content-router-discovery.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,14 @@ these alernative content routing systems automatically. This IPIP proposes
a mechanism by which IPFS nodes can discover and make use of content routing
systems.

The mechanism proposed by this IPIP, where nodes gossip preferred routers
to their connected peers, can also have broader applications. The same
mechnism could be used for external IPNS, peer routers, relays, or DNS
willscott marked this conversation as resolved.
Show resolved Hide resolved
resolvers. We point out the label allowing re-use of this mechanism for
other systems in the (protocol design)[#1-content-routing-as-a-libp2p-protocol],
but otherwise leave the concerete design for other systems to subsequent
willscott marked this conversation as resolved.
Show resolved Hide resolved
IPIPs.

## Motivation

There is currently not a process by which IPFS nodes can discover alernative
Expand All @@ -34,10 +42,10 @@ is also insufficient long term because:

This spec is designed for the ability of IPFS nodes to automatically discover
and make use of 'content routers'. Content routers are services which are able
to fulfill libp2p's [ContentRouting](https://github.com/libp2p/go-libp2p/blob/master/core/routing/routing.go#L26)
to fulfill IPFS's [ContentRouting](https://github.com/libp2p/go-libp2p/blob/master/core/routing/routing.go#L26)
API. These routers currently are considered to directly support queries using
the protocols specified by
[IPIP-337](https://github.com/ipfs/specs/pulls)
[IPIP-337](https://github.com/ipfs/specs/pulls/337)
and/or
[IPIP-327](https://github.com/ipfs/specs/pull/327).

Expand Down Expand Up @@ -77,15 +85,15 @@ nodes with high connectivity in the network.
### 1. content-routing as a libp2p protocol
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the expected plan for this to work with browser-based nodes? Are they supposed to fallback to one of your rejected alternatives (e.g. hardcoded nodes, hardcoded bootstrap nodes, advertising in the DHT, advertising in the Indexers, ...)?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect the idea is for /dnsaddr/bootstrap.libp2p.io (or any other bootstrapper set by JS user, as long its /webtransport or /wss) to speak this new protocol, avoiding hardcoding anything new.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what prevents them from participating in this protocol as described?
browser nodes will need to contact to other existing nodes, as they do today. they would learn about the existence of content routers through those same channels via the new protocol, and could then make use of them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what prevents them from participating in this protocol as described?

CORS. If the only type of router this protocol returns is HTTP URL, then by default JS-IPFS running on a website won't be able to read data via cross-origin requests to the discovered router due to CORS limitations.

We have two ways of solving the problem:

  1. (easy spec fix) Add a paragraph that requires https:// servers returned by this discovery protocol to to ALWAYS have Access-Control-Allow-Origin: * etc set up
  2. (more involved) Create libp2p version of IPIP-337: Delegated Content Routing HTTP API #337 that browser peers could use over existing /wss or /webtransport listeners. Another argument Why IPFS needs Delegated Routing over libp2p.


IPFS nodes will advertise and coordinate discover of content routers using a
new libp2p protocol advertised as "/ipfs/content-router-discovery/1.0.0".
new libp2p protocol advertised as "/ipfs/router-discovery/1.0.0".

The protocol will follow a request-response model.
A node will open a stream on the protocol when it wants to discover new
content routers it does not already know.
The node wants to request the best set of known content routers from it's peer
that it does not already know. The query will make use of a bloom filter to
support this prioritization without leaking the exact list of known content
routers that the client already knows.
The node will request routers from the peer that it does not already know.
To express what it does know, it will query with a bloom filter. The
statistical data structure provides a minimal amount of deniability around
the routers that the client already knows.

* The size of the bloom filter is chosen by the client. It is sized such
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately GitHub doesn't allow threads not tied to a line, but wanted to add some thoughts to this discussion #342 (comment) in a way that responses would be easy to trace.

  1. Per @ajnavarro's comment IPIP-342: Ambient Discovery of Content Routers #342 (comment) I too find it a little hard to believe that there will be so many routers each providing full replicas of all data tracked by IPNI that a bloom filter would be required given that running these servers is expensive and incentivization is IIUC mostly TBD (I think @guseggert had some napkin math here showing the large costs around storing 10^15 CIDs even if we exclude bandwidth costs). That being said this is #not-this-ipips-problem. If the IPNI team thinks thousands of nodes all over the world will spring up hosting PBs of data and that lack of consistency between replicas isn't going to cause problems with the evaluation criteria that clients use that problem seems to live elsewhere.
  2. Whether or not IPIP-322: Content Routing Hints #322 is a good/bad idea is also #not-this-ipips-problem since this describes how to find routers for a given content routing system (i.e. IPNI) not whether it should be passable as a hint.
    • As an aside my 2c is that you've got to be careful here to not break IPLD properties if you go this route as I've flagged in IPIP-322: Content Routing Hints #322, however it's potentially useful to add hints as long as they're not mandatory.

that it has a greater than 99% certainly that it will receive a useful
Expand All @@ -99,12 +107,50 @@ to content discovery queries. By default this will be 10. (This default is
picked as the result of modeling router propagation). It will iterate through
it's list of known content routers, hashing them against the bloom filter and
selecting the top routers that are not already known to the client. It will
return this list, along with it's reliability score for each. This response
is structured as a list, conceptually:
return this list, along with it's reliability score for each.

#### protocol messages

Protocol messages are encoded using *cbor*. The following protocol examples demonstrate
the schemas of requests and responses if they were to be encoded with JSON.

A query on the "/ipfs/router-discovery/1.0.0" protocol will look like:
```json
{
"router": "string",
"filter": "bytes of the bloom filter"
}
```
Copy link
Member

@lidel lidel Nov 21, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this protocol for discovering routers could be useful for some libp2p users (we could have a separate type for discovering routers that support peer routing). Indexers already have the peer data (mapping from peerid to multiaddrs), could be useful for reducing peer routing on light clients (use DHT as fallback / only when necessary).

@mxinden @marten-seemann thoughts on the use case and the wire format here?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(we could have a separate type for discovering routers that support peer routing).

Thus they would serve the same use-case as a rendezvous server?

thoughts on the use case and the wire format here?

I can not think of a project outside of the IPFS realm that is in need for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thus they would serve the same use-case as a rendezvous server?

It extends the rendezvous protocol in two ways:

  1. not requiring the need for a single hard-coded rendezvous point
  2. adding reputational gossip in addition to just directory listing in the rendezvous protocol


A concrete example would be:
```json
{
"router": "content-routing",
"filter": {"/": {"Bytes": "xhCakxnfIHbzeOjqlbZjawUKf7uvCXAkp0L5z9jF3actECFyCzriAuS1xiyhBCailtsYEwoy/hanhiIHqTZgnA=="}}
}
```

A response is a list of entries, which looks like:
```json
[
{
"peer": "multiaddr.MultiAddr",
"score": float
}
]
```

A concrete example would be:
```json
[
["https://cid.contact/", 0.95],
["https://dev.cid.contact/", 0.90],
{
"peer": "/dns4/cid.contact/tcp/443/https",
"score": 0.95
},
{
"peer": "/dns4/dev.cid.contact/tcp/443/https",
"score": 0.90
},
]
```

Expand Down