[zzzcpan]

I think it's the other way around. You don't want to see that bootstrapping depends on the binary to be present on the node somehow and for some reason you think that solving bootstrapping makes sense even if it depends on another completely unsolved problem. It doesn't. You solve the first problem and only after that move on to the one that depends on this problem being solved.

[tzpardi]

<<< you think that solving bootstrapping makes sense even if it depends on another completely unsolved problem >>>

No. The problem of centralized bootstrapping that is an existing and real issue of decentralized networks (see the quoted papers and my above explanation) does not depend on the problem of "binary distribution". In fact it has nothing to do with "binary distribution". If a user builds the software from source - so the user avoids any "binary distribution" - then the user still have the problem of centralized network bootstrapping.

It seems you don't understand that the problem of centralized bootstrapping is a generic information technology problem of all users, regardless what was the method of "binary distribution" if any. That's fine, it was a good discussion, but I exit from this debate with you which is becoming meaningless now :-) Thanks for sharing your view" :-)

[zzzcpan]

> If a user builds the software from source

Again, sources do not emerge out of thin air and have to be shipped to users somehow. No matter what you do, user must get the software first to bootstrap. And since bootstrapping always requires information from the sources it cannot be considered a separate problem until you solve the problem of shipping that information to users in a decentralized way.

All of the so called "decentralized" software is fundamentally broken at the moment.

[tzpardi]

It seems, you are trying to decentralize the who world which I think is a) unrealistic b) doesn't make sense. On the other hand, we are trying to solve specific use cases with decentralized applications. For instance Bitcoin implements a decentralized payment network to address a specific use case and our application Streembit implements a decentralized communication framework for humans and machines.

I am perfectly comfortable with disseminating the source via the centralized Github, though it would be nice to have a decentralized source control system. Users trust me and get the source from my repository. Users who don't trust me can fork the software and modify or distribute for themselves from the repo of a trusted person. The source distribution is centralized, but so be it. Once the users have the source/binary via Github the application addresses several use cases in a decentralized manner. I don't see how the centralized source repository invalidates the runtime soundness and robustness of a decentralized payment or communication P2P app. At the sametime, the runtime soundness and robustness of decentralized payment or communication P2P applications seriously affected by the centralized bootstrapping.

<<< All of the so called "decentralized" software is fundamentally broken at the moment. >>>

Quite true, but it is broken, because of the centralized bootstrapping, and not because of the source code is managed by a centralized repository application. I can drive with my car to your place and give the source code to you in person, which will be the ultimate decentralized source code distribution, but the issue I was talking about (centralized bootstrapping) will still exists once you run the software. I am talking about design and runtime problems of decentralized networks, and you have been talking about something different. Anyhow, thanks for the chat and all the best! :-)

[zzzcpan]

I cannot acknowledge the decentralized bootstrapping problem, I'm sorry. It relies on the information from a centralized authority (i.e. source code) and therefore cannot be solved until the first one is solved.