On Sun, May 31, 2009 at 07:42:13PM -0700, David Barrett wrote: > 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.
Folks, please cut down on all the top-posting. Thanks. > -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 -- Eugen* Leitl <a href="http://leitl.org";>leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
