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

Reply via email to