how would p2p share the burden? I mean wave isn't like file share. c/s there is less replication of heavy lifting no? I think if anything cloud technology will be involved with wave.
I agree the onus is on the person coming up with the potential technology to demonstrate that it would work. Understanding the nature of the problem is the first step in design. ________________________________ From: Thomas Wrobel <[email protected]> To: [email protected] Sent: Sat, 18 June, 2011 2:45:31 Subject: Re: protocols May I suggest this be split of into a complete separate project? While there may be huge potential in a p2p system that does "wave-ish" things, surely it wouldn't actually be wave? At the very least the vast majority of the code would be different no? The ideas being talked about seem pretty far removed from whats here now. I'm concerned that while trying to pursue ideas for this, development on wave itself - as it stands- will slow down and we might end up with neither. If people here do manage to develop a p2p system that does everything wave does, then of course wave itself will be made redundant - but thats a pretty far goal for now. The more modest (and imho, realistic for the moment) requirement of having wfp more or less as it stands, but with the servers supporting a nice documented c/s protocol is still very usefull in the short term. Making it easy for others to make wave clients will open up lots of cross-platform applications as well as lifting some of the development effort from Apaches wiab web client. -Thomas ~~~~~~ Reviews of anything, by anyone; www.rateoholic.co.uk Please try out my new site and give feedback :) On 14 June 2011 18:00, Nick Lombard <[email protected]> wrote: > I also add my +1 for distributed data and a stern move away from > legacy client - server topology. > > Some thoughts/suggestions that might answer some of the > questions/concerns raised or create more questions, whichever you > like. =) > > It is worth our time to consider that outside of the wave protocol we > have access to other facilities to contact and transfer information to > the contacts/members/contributors of a wave ie. e-mail, sms, tweets, > etc, etc. Therefor in the same fashion as BitTorrent using .torrent > files you could imagine sending a .wave file for example via e-mail as > an invite which can inform the wave client with what it requires. > Using PEX and DHTs, or similar, in stead of a centralized tracker > tracking the swarm/wave members can be located. Where there is a > concern that most if not all members will not be available for periods > long enough to completely sync data sufficiently I could envision the > use of spectators or minutes keeping clients with fixed internet > connections and longer availability to distribute and seed the data to > the contributing members more efficiently. I don't see dynamic IP as a > huge concern since you will be connecting to others when you return to > the discussion and in the event of an address change can then update > that information with them. In the unlikely event that you cannot find > even one member to re-connect with, again the use of alternative > communication protocols will suffice to resolve the panic. > > Security concerns, I would suggest to be addressed via PKC and by > utilizing Onion and/or Garlic routing of packets between members or > other non members of the current wave for that matter, would make > deciphering communications, albeit public, very difficult if not > entirely impossible. There has been a lot of thought put into a secure > messaging protocol http://www.nico.schottelius.org/software/ceofhack/ > which aim to solve just that and might be worth a look at. > > My 2 cents... > > -- > Nick Lombard > footprint: www.jigsoft.co.za >
