What would happen if default bootstrap peers provided by ProtocolLabs shut down ?
When your node boot, it tries to connect to them, fail and your DHT routing table is empty and you cannot request / serve any content via internet.
Consideration
BitTorrent clients can discover peers via DHT without requiring of a bootstrap server.
Question
Why is this not implemented for IPFS?
Danger
(Centralized) servers are prone to hijacking.
Most of the defunct torrent trackers are purchased by a company which is notorious for data mining, and it further monitoring and “fingerprinting” activity of BitTorrent sharers that unknowingly use obsolete tracker URLs.
P.S. Please do not write the name of that notorious company if you guessed it. This is not a post to promote that bad company.
What if the owner of the node eliminates it and then establishes a new node?
What if there is no bootstrap server?
Suppose, that the IPFS organization is dissolved, and no official nodes are provided.
Suppose, that later, after IPFS dissolves, no IPFS related project provides bootstrap servers.
What would happen then; that is, how would it be possible for two people who have installed different and identical IPFS software would find each other when none of their IPFS software is linked to a bootstrap server to intermediate them?
How do you expect it to happen? Two people have installed software X and know nothing about each other and there is no one to intermediate. Tell, me, how do they connect to each other? You always need a third party that is hardcoded on the software or on the configuration/storage to bootstrap.
You always need a third party that is hardcoded on the software or on the configuration/storage to bootstrap.
Is that really so?
By observing BitTorrent, I thought that bootstrap has been solved by DHT.
I utilize Deluge, qBitTorrent, RTorrent, Shareaza and Transmission, and excpt for Deluge, with which I share a couple of “private” torrents (DHT and PEX are disabled for private torrents), none of these clients utilize any BitTorrent tracker whatsoever.
Note: PEX means Peer Exchange.
Edit: You are correct.
DHT of BitTorrent does indeed require bootstrap.
Why can not BitTorrent Mainline connect to any DHT nodes?
The problem most likely occurs because something is blocking BitTorrent Mainline from contacting other nodes. Try the following suggestions to see if they help:
Make sure that when you forwarded your port, you forwarded it for UDP connections in addition to TCP connections, since DHT makes heavy use of UDP.
If you are using PeerGuardian (or an equivalent IP blocker), you might need to stop using it, or make an exception in the software for BitTorrent Mainline’s DHT bootstrap nodes at router.utorrent.com and router.bittorrent.com, as BitTorrent Mainline makes use of DHT nodes at those addresses to get the IP addresses of other nodes in the DHT network.
Try adding a .torrent file from Depthstrike.com’s mirrors for open-source/freeware projects to BitTorrent Mainline’s torrent jobs list. These .torrent files contain other DHT nodes that BitTorrent Mainline can use to bootstrap onto the DHT network.
Try removing dht.dat and dht.dat.old from the settings directory, as these files might have been corrupted.
We also have a PEX equivalent using MDNS this is from even before my time. This however only work over one multicast domain so in the realworld almost always one LAN (or less).
We can also use MDNS peers for DHT bootstrapping (idk if bittorrent does).
Edit: We don’t have PEX equivalent but LocalDiscovery.
This question and your request to have a c-based IPFS implementations are multi-year projects.
Or put differently, provide the patches and i’m sure some people would absolutely love to look at it If you can’t then that’s the answer to your questions too.
If you can’t then that’s the answer to your questions too.