Ooh, very clever idea. I agree, if you're going to go pure decentralized, a good way to do it is start centralized and than remove the central components one by one.
That way you get the benefit of centralization when you need it most (just getting something up and running that works and solves some user problem), and then you can gradually replace each central component with a decentralized alternative once they're up to snuff. Great idea. -david Serguei Osokine wrote: > On Sunday, May 31, 2009 David Barrett wrote: >> Basically, if you plan on having even one critical component -- and >> Leviant suggested he was going to use it for "crypt key enrollment >> and user authentication" -- then you might as well have as many >> central components as are helpful. > > True enough. > > Though there is always also another approach - gradual P2P rollout. > Once you deploy your system with centralized components, you might > as well utilize your now-relatively-idle programmers to deploy the > fully decentralized solution during the regular software upgrades. > > That will keep them busy and happy, and since you probably won't be > shut down immediately after launch, it will give you a time window to > get prepared to the eventualities without compromising the initial > deployment schedule. As a matter of fact, I seem to recall some P2P > service (Kazaa?) doing that: it was using the central server for some > purpose (upgrades or whatever), but if it was down for some extended > period of time, the clients regarded this as an attack on the network > and irreversibly switched themselves to a fully autonomous mode, not > accessing the central server ever again. At that point they lost the > functionality provided by this server, whatever it was - I could not > quickly find the source of this info as I was typing this answer - > but the network itself stayed intact, albeit with some functionality > limited or fully switched to P2P at that point. > > Though my memory is shaky on this subject - I cannot even recall whether > it was Kazaa or some other network. Maybe someone can remember what I'm > talking about and provide a better description... > > Best wishes - > S.Osokine. > 31 May 2009. > > > > -----Original Message----- > From: David Barrett [mailto:dbarr...@quinthar.com] > Sent: Sunday, May 31, 2009 6:03 PM > To: oso...@osokin.com; theory and practice of decentralized computer > networks > Subject: Re: [p2p-hackers] Question on VoIP Kademlia based solution > > > Agreed, if you're really concerned about not being shut down, pure > decentralized is the way to go. > > But unless you are *absolutely devoted* to decentralization, for *every > layer* -- authentication, bootstrapping, distribution of your binary, > DNS, upgrades -- everything, there's virtually no value in avoiding > centralization *everywhere* it's helpful. > > Basically, if you plan on having even one critical component -- and > Leviant suggested he was going to use it for "crypt key enrollment and > user authentication" -- then you might as well have as many central > components as are helpful. > > Because once the feds come and shut down enrollment and key generation, > they've dealt a fatal blow to your network, rendering all the fancy > decentralization (which takes hundreds if not thousands more hours to > build than a central server, and will *never, ever* be as good) a big > waste of time and energy, and honestly, a disservice to your users. > > -david > > Serguei Osokine wrote: >> On Friday, May 29, 2009 David Barrett wrote: >>> The only practical benefit I can see to a "pure" decentralized design >>> is protecting yourself from forced shutdown. But even that can be >>> mitigated by having servers in different jurisdictions. >> Shutdown is not an only unreasonable request that one could imagine. >> Craigslist had to endure all these sex ad removal requests from the >> other state attorney. Microsoft Messenger had to selectively black >> out Cuba, Iran, Sudan, etc. I fail to see how having some servers >> in Europe or wherever would allow Microsoft to avoid doing that. As >> a matter of fact, I fail to see how having such extra servers would >> have protected Napster 1.0 from shutdown, either. >> >> Of course, you can design your system in such a way that the servers in >> different jurisdictions would be operated by different legal entities. >> But that is quite an endeavor - setting up multiple legal entities >> across the globe is not for the weak of heart. If you as much as even >> suspect that someone might dislike what you are doing, going fully >> decentralized might be a pretty reasonable choice from the business >> standpoint - it might prove to be a deterrent for the lawyers who have >> nothing better to do. Plus, you don't have to pay the hosting costs >> for the central servers in that case :-) >> >> Best wishes - >> S.Osokine. >> 30 May 2009. >> >> >> -----Original Message----- >> From: p2p-hackers-boun...@lists.zooko.com >> [mailto:p2p-hackers-boun...@lists.zooko.com]on Behalf Of David Barrett >> Sent: Friday, May 29, 2009 2:33 PM >> To: theory and practice of decentralized computer networks >> Subject: Re: [p2p-hackers] Question on VoIP Kademlia based solution >> >> >> leviant Leviant wrote: >>> I do not want (at least yet) to implement any central component for such >>> purposes. >> I guess I'd ask: why this design constraint? The only practical benefit >> I can see to a "pure" decentralized design is protecting yourself from >> forced shutdown. But even that can be mitigated by having servers in >> different jurisdictions. >> >> Basically, if you're saying "I just want to build cool tech and that >> sounds fun", that's a totally valid reason. But if you're trying to >> build a scalable, secure, high-performance, real-world usable system, I >> see no reason to avoid central components. >> >> -david >> >> _______________________________________________ >> p2p-hackers mailing list >> p2p-hackers@lists.zooko.com >> http://lists.zooko.com/mailman/listinfo/p2p-hackers >> >> _______________________________________________ >> p2p-hackers mailing list >> p2p-hackers@lists.zooko.com >> http://lists.zooko.com/mailman/listinfo/p2p-hackers > _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
