# Content Router Discovery / Federation Proposal

There should not be a single party controlling an indexer hard coded into IPFS clients. The addition of alternative content routing options should be introduced so as to not unnessicarily increase centralization versus the current DHT / bootstrap subsystem.

## Status

* jan 3 - Initial Draft by @willscott

## Bootstrapping

IPFS nodes upon connection to an IPFS bootstrap node, may query for an active list of known network content routers using the libp2p identifier `/contentrouting/discovery/v1.0.0`

The response will be a sorted list of content routing endpoints.

## Feedback loop

Clients will query multiple content routers in parallel. Responses will be tracked on a 3 point scale:
* 1: this router's response included the provider that the client used to successfully fetch this content.
* 0: This router responded, but the client did not use any of them so can not comment on their usefullness.
* -1: This router failed to respond.

Upon periodic updates to the boostrap nodes, the client may optionally submit a differentially private (noise-injected) update of these tracked aggregate values, normalized to the number of requests.

The bootstrap nodes may use this client feedback, along with their own manual testing, in re-ranking or excluding content routing nodes.

## Listing

Content routers will publish their availability over the `/contentrouting/discovery/v1.0.0` gossipsub topic after connecting to bootstrap nodes as a way of advertising their presence.

Bootstrap nodes may choose to automatically incorporate discovered routers into the list they provide to clients, or may perform automatic or manual testing first. (e.g. waiting for a number of hours and validating that the advertised router remains onlne and at a stable IP, and that it is able to respond to queries for known pieces of content).

## Client Defaults

Clients may eventualy be bundled with current signed snapshots of responses from their existing bootstrap nodes to save the additional roundtrip of first connection.

## Discussion

### Q: What prevents spam advertisement of new content routers?

* The bootstrap nodes when seeing new advertisements should perform checks to make sure routers are working correctly. only as they get positive feedback from a small number of initial users will they rise up the ranking to be used by others.
* Slower routers will get lower ranking than fast routers, because in parallel queries they will be seen as '0' (didn't provide usable data) instead of a '1' (answered the query) signal.

### Q: What prevents sybil'ing of client feedback to manipulate bootstrap rankings?

* bootstraps can choose to use an internal set of controls to filter client feedback. Initial mitigation might be to limit feedback to that of libp2p clients that have been previously seen, or that are seen making queries to the DHT in proportion with the amount queries they report back.

More generally for both of these questions, the answer is that the protocol should allow for extensible policy implemented on a per-bootstrapper basis. Some components of this are useful to share, but not providing a single answer / full information about the signals and policy used in preventing abuse make it much easier to defend against sybil style attacks.