what? On Mon, Jun 1, 2009 at 2:05 AM, Eugen Leitl <eu...@leitl.org> wrote:
> 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 > -- Tony Arcieri medioh.com
_______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
