Have you actually priced out the "costly" centralized infrastructure? I'd recommend doing so. In my experience, you can handle hundreds of thousands of online users (let's say userbase 1M strong, 25% online at any point in time) from a single $40/mo central server. If you can't make $40/mo off of 1M users, you should really reconsider your service.
Alternatively, let's say you bill your time at $5/hr. If your central server saves you 8 hours of work a month, it's paid for itself -- and in practice, problems that are trivially easy to solve with a server take 10-100x longer to solve in a purely decentralized manner. Finally, unless you're so dedicated to decentralization that you would rather dump the project than go central, you should probably accept up front that someday, you'll go central: every hour spent doing something the hard way is probably just a waste of time when the easy way is right there. Basically, unless your project is 100% dependent upon being purely decentralized, there's no practical reason to go that route. It's harder, it takes longer to build, it has lower performance, it's more wasteful of your end user resources, and is worse in every single measurable way. The only reason to go pure decentralized is if you are explicitly attempting to build something that cannot be traced to you, that you cannot turn off, or that serves no other purpose but to be fun. Any of those are fine reasons, but if you actually have a different goal -- such as to make a useful product -- just save yourself the time and go central from the start, everywhere it helps. -david leviant Leviant wrote: > The system of course will have central components which will be used for > crypt key enrollment and user authentication. But I doubt that existing > P2P VoIP systems use these login/authentication servers for tracking > user sessions. If this task can be handled by P2P network why should we > issue additional requests to costly centralized infrastructure? Of > course if it *cannot* then I'll have to implement centralized session > tracking. > > 2009/5/30 David Barrett <dbarr...@quinthar.com > <mailto:dbarr...@quinthar.com>> > > 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 <mailto: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
