On 18 June 2011 11:10, Paul Thomas <[email protected]> wrote:
> how would p2p share the burden?

It wouldn't - I meant that a standard c/s for the existing wave
standard would share the burden because many people could make clients
for it. (rather then at the moment, where it takes a fair bit of
server knowledge to make anything that interfaces with wiab)

I see p2p as a complete separate project. Like "futurewave" or
"bluesky super protocol" or something. But not really wave at all.
I'm advocating merely that traditional wave development, specifically
standardising and documenting the c/s, continues separately to any
discussions and future plans regarding new server protocols.

-Thomas


 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
>>
>

Reply via email to