distributed bootstrapping with IPNS

Current bootstrap approach

We have a config file that contains either addresses or DNS names with public keys.

We use DNS to resolve addresses, then we connect to the fixed list of predefined nodes with known public keys and ask them for (somewhat) random nodes of the network, to spin up the DHT of the node.

The nodes are run by a trusted entity and we do this on each startup.

The problem

There are several problems with this approach:

• It consumes many resources on the trusted entity side because all nodes do this on every reboot/restart.
• The bootstrap node definition isn't dynamic, the default config will always contain the same entries and cannot be updated over the network (without updating the software).
• The bootstrapping isn't distributed, there is only one trusted entity.
• it's a centralized structure and prone to
• • blocking
• • outages
• • DDoS attacks

I think we should do something about that (as discussed in other places, like https://github.com/libp2p/go-libp2p-kad-dht/issues/574).

Concept

I propose to change this very basic approach with a trust-network. It allows the users to configure their trust for projects, orgs and individuals. Thus allowing to do decisions based on those data how reliably received informations are.

Trust-DB

The trust-db is stored in the node-database, not in the config file and the bootstrap field in the config file will be ignored.

• We define a JSON format to list nodes, with either domain names or addresses, public keys etc.
• Those JSON files can be published with an IPNS record.
• Other nodes can add these IPNS records to their storage and set a level how much they trust this entity.
• The IPNS records will be refreshed and the new JSON files will be fetched and processed - when the TTL does expire.
• By default we import a list of standard nodes, like we peers to the bootstrap list, with an IPNS public key to update it, as soon as the node is connected to the network.

This allows us to:

• define trusted entities, like companies, projects, or individuals
• trusted entities can update their list of nodes, as soon as they install new ones or remove old ones

Additionally trust levels

After implementing a basic trust level for bootstrapping, we could extend this to support a multitude of functions, using the trust level as ACLs.

Trust entries

Each trust-entry is a IPNS record which points to a trust-file, a trust level and a list of trusted functions as well as text-label and a lifetime. There are also some fields for the status in the end.

An example of a trust entry:

ID	description
label	name of this trust-db entry
pubkey	IPNS record
trustlevel	the trust level of this entry
trusted-functions	array of allowed extended functionalities
trust-lifetime	the time the trust-level validation is valid (="infinity")
fetched	timestamp when this entry was fetched
TTL	time after which this entry is considered stale
cache-lifetime	time after which the cached entry isn't valid anymore

trust functions

is a list of allowed functions, for this specific trust entry which overwrites positively or negatively the standard function matrix.

Trust levels

ID	example
peer	nil trust
marginal	no toughly validation, but a bit more trust than nil
trusted	an organization/individual the user trusts
advanced	e.g. a close friend the user trusts
ultimate	user's own trust file

peer

can be used to save a known peer with a remote or dns entry to the node information.

Trust level matrix

Trust level function matrix (as an example):

Function \ Trustlevel	peer	marginal	trusted	advanced	ultimate
use for bootstrap	🗶	🗶	✔	✔	✔
connect on startup	🗶	🗶	🗶	✔	✔
hold connection and reconnect to	🗶	🗶	🗶	✔	✔
used for autonat detection	🗶	✔	✔	✔	✔
allow graphsync	🗶	✔	✔	✔	✔
allow to query all ipns	🗶	🗶	🗶	🗶	✔
trusted peer exchange w/ ratings	🗶	🗶	✔	✔	✔
offer relay	🗶	🗶	🗶	✔	✔
use as relay	🗶	✔	✔	✔	✔
allow redistribute ipns	🗶	🗶	🗶	✔	✔
remote resolve IPNS	🗶	🗶	🗶	✔	✔
remote put DHT	🗶	🗶	🗶	✔	✔
remote fetch DHT	🗶	🗶	🗶	✔	✔
remote fetch CID	🗶	🗶	🗶	✔	✔

remote fetch

would allow thin clients, like mobile phones, to connect to other nodes and without bootstrapping. Thus allowing to query the DHT and fetch CIDs using them as a proxy. This would reduce the time-to-first-byte massively while reducing the energy consumption since this requires only a single connection that doesn't transfer any data when not actively used.

The thin clients would use and announce a relay connection to receive incoming connections if they are behind a firewall/nat.

remote put DHT

would allow a thin-client to announce content it holds to the DHT, without bootstrapping the DHT.

Trust files

The trust-files are json files with the following fields:

ID	subfield of	type	description	mandatory
description	root	text	field for descriptions	✔
contact	root	array	URIs for contacting	✔
entities	root	array	list of persons/projects/etc.	✔ (="default")
nodes	entities	array	entries for nodes	✔
node	nodes	array	identifiers (label) for node	✔ (="node")
pubkey	node	pubkey of the node	✔
contact	node	array	URIs for contacting	🗶
remotes	node	array	ip/port/protocol etc string	🗶
remotes-strict	node	boolean	should other remotes be omitted for this pubkey?	🗶 (=true if not present)

IPNS record limitations

for the IPNS records there some limitation necessary to avoid malicious entries

• minimal TTL 24h
• maximal cache time 2y

The issue names no repository files, tests, or entry points. Start by reviewing the proposed IPNS bootstrap flow, trust-entry matrix, and trust-file JSON schema, then clarify which part is in scope. Done would require an agreed, bounded implementation target and corresponding validation criteria.