ipfs-docs
ipfs-docs copied to clipboard
ipfs
Include community-managed bootstrap nodes to the Configure a Node page.
We want to add optional community bootstrap nodes that ipfs users can add to their node configs to provide more diversity/resilience in the bootstrapping flow. Since a number of groups already have these nodes, we'd like to add a small section to the bottom of this page to list the additional bootstrap nodes, and what organization they're being run by. I'll add a list here to be merged in as I collect the right IDs from various operators. =]
This sounds like a nice to have P2 task. Can up the priority if you think it's urgent @momack2. The list of nodes can fit into how-to/configure-node/#bootstrap quite nicely.
If the needed input is available @momack2 I am happy to start with this issue.
This is tricky. Updating a list of public and live bootstrap nodes could be costly in terms of time. What would be better is if we had an automated service that observes the DHT and returns a set of stable peers that have been online for ~1 day or more. The docs could then link to that service.
I don't think that was quite the intended approach, @johnnymatthews. This issue came from sourcing/identifying additional mechanisms to heal from hypothetical DOS attacks against the pre-configured IPFS bootstrap node list that ships in go-ipfs. With a community list here in the docs, nodes could re-configure to new bootstrap nodes if those default nodes are ever DOSed in an attack (unable to bootstrap new nodes into the network). The todo items to make this possible are:
- [ ] Request "bootstrap" node addresses from IPFS Operators (ex @andrewxhill, @obo20, @MichaelMure, @bmann, etc)
- [ ] Make a table with those addresses that others can PR to to add their own
- [ ] Add instructions for how to reconfigure your default bootstrap addresses in case of an emergency
Maybe we can just start with this list here (content provider list)? but probably better to have dedicated nodes with higher connection limits to act as potential bootstrap nodes...
Oh I see! So this list of nodes will act as a backup in case the default bootstrap nodes go down for whatever reason. Makes sense.
We could pretty easily make a workflow for users to create a PR to add new nodes. But:
- Should we allow any PR that adds a new node into the list, or only accept PRs from recognised IPFS community members?
- Do regular IPFS users have to trust that these bootstrap nodes won't do anything malicious?
Tasks
- [ ] Get list of alternative bootstrap nodes.
- [ ] Add node addresses to
how-to/configure-node/#bootstrap - [ ] List steps to change the bootstrap nodes your IPFS node looks for.
I think it can be fairly permissive - but some good standing in the ecosystem required (a malicious node could ex be annoying by bootstrapping new nodes into an isolated network and refuse to resolve content / peer them with other nodes).
@johnnymatthews How do I know when I have a complete or at least a largely representative list of IPFS Operators to request "bootstrap" node addresses from? So far we have:
- obo20 at Pinata
- andrewxhill at Textile
- MichaelMure at Infura (Do we need a peer id? Can I find this in Desktop?)
- bmann at Fission-Suite (Do we need a peer id?)
Can you tell me who else (or how I can find out), such as:
- us for Protocol Labs, NFT.Storage, Web3.Storage (who? different operators for each product?)
- who at Cloudflare?
- any other companies?
Hello @andrewxhill, @obo20, @MichaelMure, @bmann, We would like to provide a list of alternative bootstrap nodes in our Configure a node > Bootstrap documentation in the unlikely event of a Denial of Service attack for the sake of risk reduction. Can you provide me with a list for your organization?
Hey @Annamarie2019 thanks for the ping. We could run some community accessible nodes but right now we've turned off routing of non Fission content.
I've reached out to the IPFS team to see if we can get an authoritative list of community-ran bootstrap nodes.