Reweaving the web: A slew of startups is trying to decentralise the online world

It requires root or user-namespace shenanigans to assign the v6 address needed by the p2p client.

And access to BGP tables.

And they don't estimate how long such a bootstrap process would take, since for small networks it would potentially have to scan millions of candidate addresses.

A bigger problem is how software is developed. The development itself is centralized, but even worse, traditional software development approaches cannot predict all future problems, but rely on fixing them to keep the software working, which means it must be delivered to users in a centralized way too.

http://ryandoyle.net/assets/papers/Distributed_Bootstrapping...

http://grothoff.org/christian/dasp2p.pdf

http://www.net.in.tum.de/fileadmin/TUM/NET/NET-2014-08-1/NET...

You say: "i.e. changing hardcoded bootstrapping data every N minutes, so new users could bootstrap from different nodes"

The fundamental issue is, changing the data where? The node who wants to connect to the peer network, obviously cannot obtain the information from the peer network itself (as node is not connected), so obtain the information from where? Currently, all decentralized applications, including my system Streembit use the techniques of obtaining the information from a centralized source - which is the oxymoron of decentralization. If a web services or other centralized applications provide the new node with the list of existing listening/connected nodes then the solution is surely not decentralized. Government agencies or cyber-criminals only need to attack the hard coded, listening seed nodes and then the network is done and never can be back again until a new list of hardcoded seed nodes is published via the application source code or via other channels.

As I said above, Satoshi's original idea to obtain the seed info from IRC was the closest to decentralization, but since IRC is centralized itself I am sure you can see how far that is from the a decentralized bootstrapping.

We have the solutions on local decentralized networks such as mDNS and UDP multicasting which uses protocol level solutions, and we are investigating to solve the problem at Streembit with IPv6 anycasting.

>>

I disagree. Open source software can be forked and then you can adopt as much democratic development methods and governance as you want.

It's a relatively easy problem to solve, but I'm not sure that hardcoding IP addresses into programs is the best solution for users who do not compile from source.

Out of curiosity I once reviewed the source code for a certain "onion router" program and found a handful of hardcoded IP addresses. Servers at MIT if I recall correctly. If these servers are inaccessible, what is the effect?

Perhaps "bootstrapping" is simply a matter of voluntarily downloading a trusted file, containing some reachable IP addresses.

Can millions of people all download the same file? If no, then how does Firefox, Adobe Flash or Chrome get installed on so many computers?

I consider the web (cf. internet) as more or less "bootstrapped". This is because of the preference for domain names versus IP addresses. It necessitates lookups.

Bootstrapping all starts with one file: root.zone.

Since 1993, this file has not changed very often. The IP address for the server where one can download it does not change very often either.

Once I have that file, whether the root servers are working is irrelevant. Don't need them. Only need TLD nameservers, .com, etc. to be working. And of course one can download a local copy of the .com zone, etc., as a backup.

But assuming those root servers are working I do not even need this file. Long ago I memorized the IP addresses for one root server and one com nameserver.

As long as I have a means to send DNS packets[1] I can look up the IP address for any domain name and I can "surf the web". Or at least get myself out of a jam without the use of recursive DNS servers.

1. Even netcat will work, as explained in its tutorials. I do not use "dig" or BIND libraries. Nor do I ever need to set the recursive bit. I can do the resolution using non-recursive requests, using some helper scripts/programs I wrote. Interestingly, using this method beats the speed of a cold cache in nearly all cases.

For the newly decentralized web, we will need supernodes that do not pass traffic but only provide port information to allow users to connect with each other through NAT.

The IP addresses of these supernodes will be the "bootstrap". There could be millions of supernodes.

Today, the "web" is addresses of servers controlled by companies pandering to advertisers.

The "decentralized web" is addresses of users that can connect with each other to form communities. Those communities can be connected with each other, and so on.

The "content" being served to users by today's web is largely "user-generated". But overrun with advertising and "analytics". The content is served indiscriminantly to the open internet. And even if there are access controls, because the data is centralized with a handful of companies it's an easy target for third parties who want access to it.

Tomorrow's decentralized web allows user to selectively exchange their content with each other, without the companies and advertisers in the middle. Third parties wanting access may have to be more clever and more selective.