incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Wrobel <darkfl...@gmail.com>
Subject Re: IRC discussion on P2P waving
Date Sat, 22 Jun 2013 20:34:23 GMT
I certainly very much approve of any moves towards making wave based
communication suitable for many different types of data.
The potential applications are pretty limitless really. My own project
for arbitrary geolocated content  (such as 3d models for AR, or
information billboards over buildings) simply used serialized sets of
key/value pairs in a blip. Very crude and inefficient really, but even
that proved nicely how much varying things wave can be used for.

I can certainly imagine data coming from sensors, fed into blips, and
then available for view by anyone with permission....maybe even view
on future HMDs aligned to the location the data came from. Realtime
city heatmaps, for example.
The ability for people to have data from many waves (and thus
potentially many sources) opens up all sorts of
 mash-up possibilities on the clients too.


On 22 June 2013 22:15, John Blossom <jblossom@gmail.com> wrote:
> Added thought: also think of sensor data gathering. Imagine a field with
> agricultural sensors and a farmer walking through the field. There's a
> robot app that uses a wavelet to collect data from the sensors as the
> farmer walks by them, one blip per reading or series or per time period of
> readings. The robot uses another wavelet to record periodic reports. The
> farmer can share data, reports and commentary as needed with specific
> people via the wave. The regional agricultural governmental agent may use a
> UI to look at this wave and/or multiple waves for regional analysis and
> communication. And so on.
>
> John Blossom
>
> On Sat, Jun 22, 2013 at 4:06 PM, John Blossom <jblossom@gmail.com> wrote:
>
>> Michael,
>>
>> Agreed, we're talking about application and presentation layer P2P at this
>> point.
>>
>> Thomas,
>>
>> The answers to your question are probably open-ended at this time, I would
>> think, but if we work backwards from some of the desirable scenarios then
>> we can think of potential solutions that can work in a well-layered model.
>> Think of the village-market town scenarios that I outlined earlier as one
>> potential paradigm - work from the worst P2P networking conditions on up to
>> the best, perhaps - from sneakernet to Bluetooth/WiFiDirect to Mesh to IP.
>> Ideal scenario - people are "waving" without even knowing it as they walk
>> by people who are in their waves.
>>
>> Food for thought.
>>
>> John
>>
>>
>> On Sat, Jun 22, 2013 at 3:26 PM, Michael MacFadden <
>> michael.macfadden@gmail.com> wrote:
>>
>>> Thomas,
>>>
>>> At the moment we are talking about the OT algorithms, not how the nodes
>>> physically communicate.  As was previously discussed, there very well
>>> could still be one or more servers in the picture.  This is about where
>>> and how the concurrency control occurs.  At the moment a single sever
>>> (even when federating) is in control of all concurrency control.  This is
>>> what we are trying to avoid.  Even if there are still servers, the OT
>>> should be a P2P OT algorithm.
>>>
>>> ~Michael
>>>
>>> On 6/22/13 12:03 PM, "Thomas Wrobel" <darkflame@gmail.com> wrote:
>>>
>>> >Sorry as this has probably been explained - but if client p2p is a
>>> >possibility, how will clients find eachother :?
>>> >Surely everyone would need static external IPs - which simply isn't
>>> >the case with the web today.
>>> >
>>> >This is mostly all over my head - but I have never even seen a web
>>> >based p2p chat program before. I thought it simply wasn't possible to
>>> >communicate between two browsers without a sever between them.
>>> >
>>> >or does p2p mean something different in this context?
>>> >
>>> >On 22 June 2013 18:53, John Blossom <jblossom@gmail.com> wrote:
>>> >> Michael,
>>> >>
>>> >> I like that way that you put it. Hopefully what we wind up with is a
>>> >> protocol that is fundamentally P2P but which interacts with servers as
>>> >> ultra-efficient UI-less peers equipped with some super-powers and
>>> >>services
>>> >> that may not be present in the P2P domain persistently. Call it p2p2P,
>>> >>so
>>> >> to speak. John
>>> >>
>>> >> On Fri, Jun 21, 2013 at 10:04 PM, Michael MacFadden <
>>> >> michael.macfadden@gmail.com> wrote:
>>> >>
>>> >>> MY humble opinion on the P2P issue is as follows.  I think if we
>>> >>>develop
>>> >>> algorithms that can work in a P2P mode, then we can also support a
>>> >>> client/server architecture as well by just controlling who the peers
>>> >>>talk
>>> >>> to.  I think the problem with wave was not the client server
>>> >>>architecture,
>>> >>> but rather the way the servers interacted with each other.  The
>>> servers
>>> >>> themselves implemented something like a client/server relationship
>>> >>>within
>>> >>> federation.  This meant that even if you were connected to your local
>>> >>>wave
>>> >>> server, if that wave server could not communicate with the wave server
>>> >>> that initiated the wave, you were out of luck.
>>> >>>
>>> >>> I am not against having servers at all.  In fact I think that things
>>> >>>get
>>> >>> very complicated if you have no servers what so ever (document
>>> storage,
>>> >>> discovery, users, etc.).  But if we need to make sure servers are
>>> >>>peers.
>>> >>> So we need a P2P style OT algorithm.  Again do not confuse a P2P
>>> >>>network
>>> >>> topology (DHT, etc) with P2P OT Algorithms.  A P2P OT Algorithm  can
>>> >>>also
>>> >>> easily be made to behave like a Client/Server OT algorithm, where as
>>> >>>the
>>> >>> reverse is not feasible.
>>> >>>
>>> >>> ~Michael
>>> >>>
>>> >>> On 6/21/13 5:46 PM, "Sam Nelson" <sohra@orcon.net.nz> wrote:
>>> >>>
>>> >>> >Wow, that was some heavy reading (:
>>> >>> >
>>> >>> >This section raised some questions for me:
>>> >>> >
>>> >>> >*4) Routing p2p messages/events in a pure P2P system (5 parts)*
>>> >>> >How to manage to route all wave-stuff if we want to completely get
>>> >>>rid of
>>> >>> >servers completely, and only use peers.
>>> >>> >The closest way would be to use a DHT, but huge latency is an
>>> unsolved
>>> >>> >problem, and makes it impossible to use for real-time waving.
>>> >>> >No other solution has been proposed.
>>> >>> >
>>> >>> >My question is simply, perhaps naively: why pure p2p?
>>> >>> >Originally when I heard of p2p OT I saw it as a way to
>>> collaboratively
>>> >>> >work offline in a LAN environment, and to sync pairs that are almost
>>> >>> >always offline, by means of a proxy peer that moves between WAN and
>>> >>>the
>>> >>> >offline LAN. The peers would talk in much the same way that two
>>> >>> >federating servers would, using their offline caches as a datasource
>>> >>> >instead I'm guessingthis is like the MESH network John refers to.
>>> >>> >
>>> >>> >When talking about P2P between peers /over the internet/ - could
>>> >>> >somebody please explain to be the purpose of and vision for this? Why
>>> >>> >not just use a server, it seems to simplify things alot? (Firewalls,
>>> >>> >authentication - can do offline like Windows 8 does with Microsoft
>>> >>> >Account)
>>> >>> >
>>> >>> >Is purep2p just for privacy? Or is it really for alternate uses of
>>> the
>>> >>> >protocol - other than the the documents and conversation use cases we
>>> >>> >saw in Google Wave?
>>> >>> >
>>> >>> >Just an idea, in order to "open the eyes" of those drawn to this
>>> >>>mailing
>>> >>> >list, might it be beneficial to build up a wiki page of accepted use
>>> >>> >cases so that everyone can read them and take them into account when
>>> >>> >considering different ideas? That'd facilitate discussions like "well
>>> >>> >this works for all our use cases except #13.... <discussion ensues
>>> >>>about
>>> >>> >this case>"
>>> >>> >
>>> >>> >Sam
>>> >>> >
>>> >>> >
>>> >>> >On 22/06/2013 01:06, John Blossom wrote:
>>> >>> >> Bruno,
>>> >>> >>
>>> >>> >> Thanks, this is an excellent summary. It helps me to get the gist
>>> of
>>> >>> >>things
>>> >>> >> more clearly.
>>> >>> >>
>>> >>> >> On the P2P latency, I don't think that it would be unacceptable to
>>> >>>draw
>>> >>> >>a
>>> >>> >> line and say that P2P provides limited, non-guaranteed realtime OT
>>> >>>or
>>> >>> >>that
>>> >>> >> it's not realtime OT and more of a syncing mode than a conversation
>>> >>> >>mode.
>>> >>> >> That would probably be sufficient for what needs to be done,
>>> >>>especially
>>> >>> >> since in some instances P2P-enabled Wave sessions may be using MESH
>>> >>> >> networks for transport - a key factor in how a lot of experimental
>>> >>> >> communications services are being deployed in developing nations
>>> >>>(not
>>> >>> >>just
>>> >>> >> the Project Loon concept). In the MESH model, you're likely to have
>>> >>>one
>>> >>> >> node within range of another temporarily, which may sync with it,
>>> >>>and
>>> >>> >>then
>>> >>> >> pass along data to another node when it comes in range of it.
>>> >>>That's the
>>> >>> >> most probable scenario for P2P in many instances, I would think.
>>> The
>>> >>> >>other
>>> >>> >> potential scenario: two people in a remote location, for the sake
>>> of
>>> >>> >> argument two movie script-writers who have holed themselves up in a
>>> >>> >>remote
>>> >>> >> location to collaborate on a common script. They're on two devices
>>> >>>that
>>> >>> >>are
>>> >>> >> very proximate to one another, so perhaps the latency issues will
>>> >>>not
>>> >>> >>be so
>>> >>> >> severe.
>>> >>> >>
>>> >>> >> Things to think about, I will look at this more carefully later
>>> >>>today.
>>> >>> >>
>>> >>> >> All the best,
>>> >>> >>
>>> >>> >> John Blossom
>>> >>> >>
>>> >>> >> On Fri, Jun 21, 2013 at 8:05 AM, Bruno Gonzalez (aka stenyak) <
>>> >>> >> stenyak@gmail.com> wrote:
>>> >>> >>
>>> >>> >>> Following Joseph's "A Very Wavey Plan (P2P!)" thread, a couple of
>>> >>> >>> discussions have taken place at the irc.freenode.net #wiab
>>> channel,
>>> >>> all
>>> >>> >>> related to P2P.
>>> >>> >>>
>>> >>> >>> I've taken the liberty to restructure the IRC logs, remove some
>>> >>> >>>chitchat,
>>> >>> >>> and divide it into sub-discussions. Feel free to reply to any part
>>> >>>of
>>> >>> >>>this
>>> >>> >>> email to continue a discussion.
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> *Summary of discussions:*
>>> >>> >>> *====================*
>>> >>> >>> *1) Underlying protocol for P2P federation*
>>> >>> >>> Currently XMPP is used. HTTP and raw TCP are two suggested
>>> >>>candidates
>>> >>> >>>(HTTP
>>> >>> >>> allowing to much more easily reach restricted networks).
>>> >>> >>>
>>> >>> >>> *2) Message/event types needed for P2P federation to work*
>>> >>> >>> We'd need something similar in concept to certain git operations
>>> >>>(git
>>> >>> >>> clone, git push...). All will be based on hashes (not incremental
>>> >>> >>> integers).
>>> >>> >>>
>>> >>> >>> *3) Routing p2p messages/events in a server-aided network*
>>> >>> >>> One option is to somehow detect server clusters, send data to one
>>> >>>of
>>> >>> >>>them,
>>> >>> >>> and let the rest of the cluster servers synchronize to it
>>> >>>(locally).
>>> >>> >>> Alternatively, the originator server can naively send stuff to all
>>> >>> >>>possible
>>> >>> >>> destination servers, regardless of the cost.
>>> >>> >>>
>>> >>> >>> *4) Routing p2p messages/events in a pure P2P system (5 parts)*
>>> >>> >>> How to manage to route all wave-stuff if we want to completely get
>>> >>>rid
>>> >>> >>>of
>>> >>> >>> servers completely, and only use peers.
>>> >>> >>> The closest way would be to use a DHT, but huge latency is an
>>> >>>unsolved
>>> >>> >>> problem, and makes it impossible to use for real-time waving.
>>> >>> >>> No other solution has been proposed.
>>> >>> >>>
>>> >>> >>> *5) Implementing "undo": invertibility, tombstones, edge cases,
>>> >>>TP2*
>>> >>> >>> No server means no canonical order of commits, which means that
>>> >>>undo is
>>> >>> >>> hard to do correctly.
>>> >>> >>> (uhm... not sure if that's a good summary, some stuff went over my
>>> >>>head
>>> >>> >>> :-D, please read the log instead)
>>> >>> >>>
>>> >>> >>> *6) Usability of a pure p2p system in Real Life (tm)*
>>> >>> >>> Being pragmatic, pure P2P is probably only usable in peers with
>>> >>>good
>>> >>> >>> connectivity. Rest of peers will need to rely on a server/proxy
>>> >>>that
>>> >>> >>>*does*
>>> >>> >>> have good connectivity.
>>> >>> >>>
>>> >>> >>> *7) Comparison with BitTorrent and P2P-TV technologies*
>>> >>> >>> Both technologies are much less restricted than wave with regards
>>> >>>to
>>> >>> >>> real-time responsiveness. So none are really a good reference for
>>> >>>our
>>> >>> >>> purposes.
>>> >>> >>>
>>> >>> >>> *8) Identifying participants (3 parts)*
>>> >>> >>> Pure p2p means many peers don't have a
>>> >>>name@centralized-server.comuser
>>> >>> >>> handle, so an alternative has to be used.
>>> >>> >>> However, it's easy to provide a traditional friendly handle, if
>>> the
>>> >>> >>>user
>>> >>> >>> prefers the tradeoff of having to often rely on a permanent
>>> server.
>>> >>> >>>This
>>> >>> >>> tradeoff can be mitigated by using a sort of userhandle cache.
>>> >>> >>>
>>> >>> >>> *9) P2P anonymity (lurking in a wave) (2 parts)*
>>> >>> >>> In a pure p2p wave network, anonymous peers may want to read a
>>> >>>public
>>> >>> >>>wave,
>>> >>> >>> without other peers knowing. A solution could be to make private
>>> >>>the
>>> >>> >>> required wavelets (where the anonymous participants IDs are
>>> >>>stored).
>>> >>> >>>
>>> >>> >>> *10) Encryption of waves*
>>> >>> >>> It's been proposed to use an AES key to encrypt all the wave data,
>>> >>>and
>>> >>> >>>only
>>> >>> >>> allow participants to decrypt it.
>>> >>> >>>
>>> >>> >>> *11) Addition and removal of participants, and their ability to
>>> >>>read
>>> >>> >>>past
>>> >>> >>> and future wave versions/deltas*
>>> >>> >>> The aforementioned AES key can change over time, allowing a
>>> >>> >>>finer-grained
>>> >>> >>> restriction of what deltas new/removed participants can read.
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> *
>>> >>> >>> *
>>> >>> >>>
>>> >>> >>> *Actual conversations:*
>>> >>> >>> *====================*
>>> >>> >>> *
>>> >>> >>> *
>>> >>> >>> *1) Underlying protocol for P2P federation:*
>>> >>> >>> [in response to Joseph's email]
>>> >>> >>> [23:42] <alown> I [...] agree with option 2 (make every root a
>>> JSON
>>> >>> >>>blob)
>>> >>> >>> [23:43] <alown> You haven't really detailed (at all) how the P2P
>>> >>> >>>federation
>>> >>> >>> is actually going to work (beyond 'not like IRC')
>>> >>> >>> [23:44] <josephg> Personally, I'd love some raw TCP action
>>> >>> >>> [23:44] <alown> I agree using KISS principle.
>>> >>> >>> [23:44] <josephg> a few years ago (not long after wave was
>>> >>>cancelled)
>>> >>> >>>there
>>> >>> >>> was a 'wave summit'
>>> >>> >>> [23:45] <josephg> - and a few of us chatted about how we could
>>> >>>make the
>>> >>> >>> federation protocol simpler
>>> >>> >>> [23:45] <josephg> we ended up (somehow) deciding that doing it
>>> over
>>> >>> >>>http
>>> >>> >>> woul dbe a good idea
>>> >>> >>> [23:45] <josephg> because then we could sneak it into companies
>>> >>>past
>>> >>> >>>their
>>> >>> >>> corporate HTTP firewalls, etc
>>> >>> >>> [23:45] <josephg> but in any case, I'd like to figure out the
>>> >>>protocol
>>> >>> >>>and
>>> >>> >>> (at least) have a TCP version
>>> >>> >>> [23:46] <josephg> it should be pretty easy to wrap the same
>>> >>>messages in
>>> >>> >>> websockets if we want
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> *2) **Message/event types needed for P2P federation to work:*
>>> >>> >>> [23:46] <alown> Do we need anything more complicated than the
>>> >>> >>> waveletSubmit/Commit messages used currently?
>>> >>> >>> [23:46] <alown> (Replace wavelet with 'abstract p2p ot container
>>> >>>name)
>>> >>> >>> [23:46] <josephg> um, yeah.
>>> >>> >>> [23:47] <josephg> we'll also be able to rip out all the code that
>>> >>>deals
>>> >>> >>> with managing the tree of servers per wave
>>> >>> >>> [23:47] <josephg> but yeah - the protocol will get a bit more
>>> >>> >>>complicated
>>> >>> >>> [23:47] <josephg> ... because we'll lose our beautiful integer
>>> >>>version
>>> >>> >>> numbers
>>> >>> >>> [23:47] <josephg> so we'll need a protocol for syncronizing ops
>>> >>> >>> [23:48] <josephg> yeah - ops will each have a hash
>>> >>> >>> [23:48] <josephg> and two servers could each have ops the other
>>> >>>server
>>> >>> >>> doesn't have
>>> >>> >>> [23:48] <josephg> so we have to be able to deal with that
>>> >>> >>> [23:47] <alown> What other 'events' are cared about by any
>>> >>>particular
>>> >>> >>> server?
>>> >>> >>> [23:47] <alown> For a SHA hash?
>>> >>> >>> [23:48] <josephg> -> we'll need something like git's sync protocol
>>> >>> >>> [23:48] <alown> So, initial server contact is 'git clone', and
>>> then
>>> >>> >>>some
>>> >>> >>> form of 'git push' on changes?
>>> >>> >>> [23:49] <josephg> yep.
>>> >>> >>> [23:49] <josephg> push on changes is easy - its basically the same
>>> >>> >>>thing we
>>> >>> >>> have now
>>> >>> >>> [23:49] <josephg> just instead of saying "This should be applied
>>> at
>>> >>> >>>version
>>> >>> >>> 10" we say "This op has parents [abc123, def456]"
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> *3) **Routing **p2p **messages/events in a server-aided network:*
>>> >>> >>> [23:49] <alown> With P2P do we have to broadcast to all peers? How
>>> >>>do
>>> >>> >>>we
>>> >>> >>> coordinate that between them?
>>> >>> >>> [23:50] <josephg> between servers? I dunno.
>>> >>> >>> [23:50] <alown> How does BT handle this?
>>> >>> >>> [23:50] <josephg> should we just connect every server to every
>>> >>>other
>>> >>> >>> server? That'd work fine...
>>> >>> >>> [23:50] <josephg> I guess every server can address every other
>>> >>>server
>>> >>> >>> [23:50] <josephg> beacuse the wave will have alown@a.com and
>>> >>> >>> josephg@b.comand so on on it
>>> >>> >>> [23:50] <alown> This feels very inefficent...
>>> >>> >>> [23:51] <josephg> so if you submit an op to your server, your
>>> >>>server
>>> >>> >>>can go
>>> >>> >>> "Oh, I need to tell b.com about this too"
>>> >>> >>> [23:51] <josephg> well, if there's 10 servers, presumably all 10
>>> >>> >>>servers
>>> >>> >>> need to find out about ops somehow.
>>> >>> >>> [23:51] <josephg> - assuming we stick with the current model of
>>> >>>having
>>> >>> >>> servers store all your operations
>>> >>> >>> [23:51] <josephg> .. and documents for all the users at their
>>> >>>domain
>>> >>> >>> [23:51] <alown> But server 'b' and 'c' might both be part of a
>>> >>>wave,
>>> >>> >>>but
>>> >>> >>> also know each other, and know that they are 'closer' to each
>>> other
>>> >>> >>>than
>>> >>> >>> 'a' is. So, we would want a->b/c then b<->c
>>> >>> >>> [23:52] <josephg> so actually, having the server which originates
>>> >>>an
>>> >>> >>> operation send it to all the other servers on that wave is
>>> actually
>>> >>> >>>close
>>> >>> >>> to ideal.
>>> >>> >>> [23:52] <josephg> yeah maybe.
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> *4) **Routing **p2p **messages/events in a pure P2P system (part
>>> >>>1):*
>>> >>> >>> [23:54] <alown> BT uses DHT for its P2P stuff...
>>> >>> >>> [23:54] <josephg> ...I guess we could use a DHT storing all the
>>> >>>ops,
>>> >>> >>>but
>>> >>> >>> thats pretty slow
>>> >>> >>> [23:55] <josephg> and you still need to notify all servers with
>>> >>>users
>>> >>> >>>on
>>> >>> >>> the wave that the wave was updated.
>>> >>> >>> [23:55] <alown> Maybe, or perhaps only notify those within a
>>> >>>certain
>>> >>> >>> 'distance', with each server doing that. (Though could mean some
>>> >>> >>>servers
>>> >>> >>> are never updated)
>>> >>> >>> [23:58] <alown> Perhaps we could make the network setup
>>> >>>'SuperWaves'
>>> >>> >>>which
>>> >>> >>> broadcast to all peers, and carry all information, but normal wave
>>> >>> >>>servers
>>> >>> >>> do not reach this status?
>>> >>> >>> [23:58] <alown> By having it decide itself based on how
>>> >>>'connected' a
>>> >>> >>> server is, this could find the most efficent ways to route it.
>>> >>> >>> [00:01] <josephg> Do you think it'll really be a problem?
>>> >>> >>> [00:01] <josephg> I mean, thinking about it - how many servers
>>> >>>will be
>>> >>> >>>on a
>>> >>> >>> given wave?
>>> >>> >>> [00:01] <alown> Depends.
>>> >>> >>> [00:01] <alown> No idea.
>>> >>> >>> [00:01] <josephg> If it were a public wave, I can imagine clients
>>> >>>just
>>> >>> >>> connecting to one (or more) centralized servers
>>> >>> >>> [00:01] * josephg nods
>>> >>> >>> [00:02] <josephg> ... But say if we were having a conversation on
>>> >>> >>> wave-dev@apache, there's like, at most 20 people in a discussion
>>> >>>from
>>> >>> >>>5 or
>>> >>> >>> so domains
>>> >>> >>> [00:03] <josephg> ... I think we can deal with that kind of load.
>>> >>> >>> [00:04] <josephg> but if the protocol lets any server tell any
>>> >>>other
>>> >>> >>>server
>>> >>> >>> about an operation, then it should be pretty easy to set up
>>> >>>something
>>> >>> >>>like
>>> >>> >>> that.
>>> >>> >>> [00:04] <josephg> maybe.
>>> >>> >>> [00:04] * josephg thinks
>>> >>> >>> [00:05] <josephg> hm - you're right. I think I've just gotten used
>>> >>>to
>>> >>> >>>the
>>> >>> >>> crappy state of doing routing for broadcasting messages to a
>>> >>>network
>>> >>> >>> [00:05] <josephg> if you can find / think of a better solution,
>>> >>>I'm in.
>>> >>> >>> [00:12] <alown> Heh, anyway replacing the network layer code
>>> >>>SHOULD be
>>> >>> >>> easy, since it SHOULD be cleanly seperated.
>>> >>> >>> [00:13] <alown> Getting an initial implementation up using
>>> >>>broadcast is
>>> >>> >>> fine.
>>> >>> >>> [00:13] <alown> (I was thinking of Wave's use in other apps as a
>>> >>> >>>reason you
>>> >>> >>> could have a lot of different participant domains)
>>> >>> >>> *...4) Routing **p2p **messages/events in a pure P2P system (part
>>> >>>2):*
>>> >>> >>> [08:53] <stenyak> as for the "how to *really* do p2p", i see two
>>> >>> >>>options:
>>> >>> >>> a) use a dht-like algorithm and/or b) use a helper server to route
>>> >>> >>>stuff
>>> >>> >>> for you
>>> >>> >>> [08:54] <stenyak> a) can be pretty slow if you want all OPs to
>>> >>>reach
>>> >>> >>>all
>>> >>> >>> peers (if I'm not mistaken)
>>> >>> >>> [08:54] <stenyak> and b) is essentially makes it not-p2p
>>> >>> >>> [08:55] <stenyak> additionally, using p2p, how are we going to
>>> deal
>>> >>> >>>with
>>> >>> >>> routing problems (such as firewalls on both sides, etc)?
>>> >>> >>> [08:56] <stenyak> in my mind, the only universal solution is to
>>> >>>have a
>>> >>> >>> third party server available to go through if we want speed or if
>>> >>>we
>>> >>> >>>want
>>> >>> >>> to work on all edge cases
>>> >>> >>> [08:56] <stenyak> and wave being advertised as realtime, i don't
>>> >>>see
>>> >>> >>>how
>>> >>> >>> something like dht can ever fly
>>> >>> >>> [11:20] <alown> stenyak: This is why I was wondering about a DHT
>>> >>>system
>>> >>> >>> with 'Superwave' servers (to act as a first point of contact).
>>> >>> >>> [11:59] <stenyak> that would be like skype dynamic supernode list?
>>> >>> >>> [11:59] <alown> The original system, yes.
>>> >>> >>> [12:02] <stenyak> so we would devise a method to identify
>>> >>>candidates to
>>> >>> >>> being a supernode, in order to prevent cellphone wave peers from
>>> >>> >>>becoming
>>> >>> >>> one, and in order to promot certain other nodes (like major peers
>>> >>>that
>>> >>> >>>have
>>> >>> >>> 99% uptime, e.g. wave.google.com or whatever)  to become one
>>> >>> >>> [12:03] <stenyak> bandwidth, latency, open ports, uptime...
>>> >>> >>> [12:04] <alown> Once a network has been bootstrapped using
>>> >>>something,
>>> >>> >>>it is
>>> >>> >>> relatively easy to identify the hosts which are most densely
>>> >>>connected
>>> >>> >>>(and
>>> >>> >>> would be good supernode candidates)
>>> >>> >>> [12:05] <stenyak> what do you mean with "using something"?
>>> >>> >>> [12:06] <alown> Somehow the network has to initially be able to
>>> >>>make
>>> >>> >>> contact with other nodes (before it knows anything about them)
>>> >>> >>> [12:07] <alown> For a LAN you could get away with a broadcast
>>> >>> >>>'announce',
>>> >>> >>> but it is a bit less clear on an internet-sized scale.
>>> >>> >>> [12:08] <stenyak> bittorrent sync uses a broadcast for LAN. for
>>> >>> >>>internet it
>>> >>> >>> uses a tracker server for fast discovery of peers, or you can
>>> >>>disable
>>> >>> >>>that
>>> >>> >>> and force to use DHT (with the long wait that means)
>>> >>> >>> [12:09] <stenyak> the tracker can also act as a meeting-point for
>>> >>> >>> firewalled peer pairs (which in my experience is a lot of them)
>>> >>> >>> [12:09] <alown> Precisely the problem, because we don't really
>>> want
>>> >>> >>>long
>>> >>> >>> waits or trackers.
>>> >>> >>> *...4) Routing **p2p **messages/events in a pure P2P system (part
>>> >>>3):*
>>> >>> >>> [12:42] <stenyak> hmmm... i'm not sure how a peer gets a list of
>>> >>>waves
>>> >>> >>>in
>>> >>> >>> which he's a participant of
>>> >>> >>> [12:43] <alown> Having a canonical source makes it all so much
>>> >>>easier.
>>> >>> >>>:P
>>> >>> >>> [12:44] <stenyak> for pure p2p peers to "receive" new waves,
>>> >>>either the
>>> >>> >>> FROM or the TO peer (or both) would need to try to find their way
>>> >>>to
>>> >>> >>>the
>>> >>> >>> other
>>> >>> >>> [12:44] <stenyak> and we're assumign here that each person only
>>> >>>runs
>>> >>> >>>one
>>> >>> >>> peer
>>> >>> >>> [12:45] <stenyak> e.g. my privatekey may be used by 5 wave peers
>>> >>>at the
>>> >>> >>> same time, and we must make sure the new wave reaches all of them
>>> >>> >>> [12:46] <alown> Looks like we may need to have mulitple DHTs then
>>> >>>(one
>>> >>> >>>for
>>> >>> >>> ops, one for waves)
>>> >>> >>> [12:46] <stenyak> in BT, it's the receiver end who actively looks
>>> >>>for
>>> >>> >>>peers
>>> >>> >>> to receive from. in wave, it's not like that..
>>> >>> >>> [12:46] <alown> Or could we have a pubkey->wave mapping in one?
>>> >>> >>> [12:46] <stenyak> and in BT, you can assume *many* people has the
>>> >>>data
>>> >>> >>>you
>>> >>> >>> want
>>> >>> >>> [12:46] <stenyak> in wave, its possible and probably that only one
>>> >>> >>>other
>>> >>> >>> peer in the universe has the wave
>>> >>> >>> [12:46] <stenyak> (because it's a personal wave sent to you)
>>> >>> >>> [12:47] <alown> I would expect any long-running supernodes to be
>>> >>> >>>implicitly
>>> >>> >>> part of all waves they know about.
>>> >>> >>> [12:47] <alown> Though on second thought, this seems like it would
>>> >>>add
>>> >>> >>>its
>>> >>> >>> own problems to authentication, storage, promotion of supernodes
>>> >>>etc.
>>> >>> >>> *...4) Routing **p2p **messages/events in a pure P2P system (part
>>> >>>4):*
>>> >>> >>> [12:51] <alown> Does it make sense for a peer to have your
>>> privkey,
>>> >>> >>>since
>>> >>> >>> you could be logged in anywhere, so it would be down to the place
>>> >>>you
>>> >>> >>>are
>>> >>> >>> logged in, to 'subscribe' to that wave on the network, and attempt
>>> >>>to
>>> >>> >>> retrieve all data from it...
>>> >>> >>> [12:55] <alown> I was expecting the network as a whole to act like
>>> >>>a
>>> >>> >>> WaveBus pubsub system, whereby once 'logged in' at some server
>>> >>>(which
>>> >>> >>>means
>>> >>> >>> it gets your privkey from the authentication system), that server
>>> >>>then
>>> >>> >>> 'subscribes' to your waves on the 'network'. If somebody else at
>>> >>>some
>>> >>> >>>other
>>> >>> >>> server changes it, then that server would be announcing to the
>>> >>>network
>>> >>> >>>of a
>>> >>> >>> change (doesn't necesserily have to be a broadcast), which your
>>> >>>server
>>> >>> >>> would 'hear'.
>>> >>> >>> [12:56] <alown> You could do this from any server where you logged
>>> >>>in
>>> >>> >>> (hence the concept of a domain is lost).
>>> >>> >>> [12:57] <stenyak> by "server" you mean supernodes?
>>> >>> >>> [12:57] <alown> Not necessarily.
>>> >>> >>> [12:59] <stenyak> this pubsub network must be aware of nodes that
>>> >>>are
>>> >>> >>>in
>>> >>> >>> it, in order to directly route wave updates to them, correct?
>>> >>> >>> [12:59] <stenyak> and also, this network wouldn't be very
>>> >>>volatile, but
>>> >>> >>> would rather ideally be long-lived peers?
>>> >>> >>> [13:00] <alown> It has no reason to have to directly route
>>> updates,
>>> >>> >>>(though
>>> >>> >>> it would hopefully be able to identify the best routes
>>> >>>automatically).
>>> >>> >>> [13:00] <alown> Yes it would require a few long-lived peers (which
>>> >>> >>>would be
>>> >>> >>> part of the requirement to be a supernode).
>>> >>> >>> [13:01] <stenyak> so let's say i connect my laptop wave peer to
>>> the
>>> >>> >>> "server" in the living room, at my firewalled home. this "server"
>>> >>> >>>would be
>>> >>> >>> already subscribed to the pubsub network, and in this specific
>>> >>>case it
>>> >>> >>> would route all wave updates to me
>>> >>> >>> [13:02] <stenyak> in other cases (let's say, ipv6-enabled nodes
>>> >>> >>>everywhere,
>>> >>> >>> no firewall at home), the living room server could simply notify
>>> >>>the
>>> >>> >>> original "FROM" peer to send stuff to my laptop ipv6 ip, right?
>>> >>> >>> [13:03] <alown> That sounds right. Supernodes are really only
>>> >>>needed
>>> >>> >>>for
>>> >>> >>> getting the routing right.
>>> >>> >>> [13:05] <stenyak> ok. in both these theoretical cases, the
>>> "server"
>>> >>> >>>hasn't
>>> >>> >>> necessarily been a wave node per se (nor a supernode either), but
>>> >>> >>>rather a
>>> >>> >>> second type of wave node that helps get stuff quickly wherever
>>> it's
>>> >>> >>>needed
>>> >>> >>> [13:05] <alown> Yes.
>>> >>> >>> [13:05] <alown> I am not even sure where OT should be happening in
>>> >>>this
>>> >>> >>> picture...
>>> >>> >>> [13:05] <stenyak> if OT happens, the "server" is a blind proxy i
>>> >>>think
>>> >>> >>> [13:06] <stenyak> so does not need the privkey to work
>>> >>> >>> [13:07] <stenyak> unless we're also using OT in the wavebus pubusb
>>> >>> >>>network
>>> >>> >>> for some reason?
>>> >>> >>> [13:07] <alown> Supernodes can be blind (though they might also
>>> >>>just be
>>> >>> >>> normal well-connected wave servers). I would expect normal servers
>>> >>>to
>>> >>> >>>still
>>> >>> >>> be doing OT. The question is whether the 'client' (whatever that
>>> >>>means)
>>> >>> >>> should be doing it also.
>>> >>> >>> [13:08] <alown> The network shouldn't need OT. (Algorithms exist
>>> >>>that
>>> >>> >>>allow
>>> >>> >>> the incoming ops to be arbitarily queued and only processed when
>>> >>> >>>needed).
>>> >>> >>> [...]
>>> >>> >>> [21:21] <josephg> alown: the client always needs to do OT because
>>> >>> >>>otherwise
>>> >>> >>> they can't both edit a document live and receive operations from
>>> >>> >>>people who
>>> >>> >>> didn't have their ops.
>>> >>> >>> [21:22] <josephg> the server doesn't need to do OT, although if it
>>> >>> >>>doesn't
>>> >>> >>> do OT, it'll punt the OT work to its clients - which will result
>>> >>>in a
>>> >>> >>> higher CPU utilization on mobile devices.
>>> >>> >>> [...]
>>> >>> >>> [13:08] <stenyak> i pictured this "server" as being an optional
>>> >>>item
>>> >>> >>>that
>>> >>> >>> shortcuts the long waits of DHT, rather than something necessary
>>> >>>for
>>> >>> >>> "clients"?
>>> >>> >>> [13:08] <alown> Hmm.
>>> >>> >>> [13:08] <alown> I suppose we should define what a 'client' is
>>> >>>then...
>>> >>> >>> [13:09] <alown> We have at least 2 layers of stuff going on here:
>>> >>>1)
>>> >>> >>>Wave
>>> >>> >>> OT/operation layer 2) Network routing/P2P layer
>>> >>> >>> [13:13] <alown> But it is quite plausible something might be doing
>>> >>> >>>both of
>>> >>> >>> those
>>> >>> >>> [13:10] <stenyak> with your pubsub net suggestion, i was picturing
>>> >>>2
>>> >>> >>>kinds:
>>> >>> >>> a regular pure p2p peer, and a helper kind of node to route stuff
>>> >>> >>>quickly
>>> >>> >>> when a peer is connected to it
>>> >>> >>> [13:13] <stenyak> so with that picture in mind, layer 1 stuff
>>> >>>could go
>>> >>> >>> directly from peer to peer (if connectivity/firewalls allows), or
>>> >>> >>>through
>>> >>> >>> the "helper node" if available
>>> >>> >>> [...]
>>> >>> >>> [13:20] <stenyak> [...] all this discussion looks very similar to
>>> >>> >>> discussing how to design internet+dns, i think the problems are
>>> the
>>> >>> >>>same
>>> >>> >>> really
>>> >>> >>> [13:20] <stenyak> or at least we could take some inspiration from
>>> >>>it
>>> >>> >>>maybe
>>> >>> >>> [13:20] <alown> This was my conclusion last night with josephg.
>>> >>>('The
>>> >>> >>> problmes should already be solved (see The Internet)')
>>> >>> >>> [14:09] <stenyak> and The Internets solved the problem how? By
>>> >>>having a
>>> >>> >>> large set of supernodes (dns servers), that may take a whole day
>>> to
>>> >>> >>> propagate updates. The alternative being having the actual IP
>>> >>>address
>>> >>> >>>in
>>> >>> >>> the first place, or to centralize stuff
>>> >>> >>> [14:10] <stenyak> (aka use servers everywhere)
>>> >>> >>> [14:22] <alown> Maybe, but the internet's design is X (where X >
>>> >>>20)
>>> >>> >>>years
>>> >>> >>> old, so may not represent the most modern thinking of how to make
>>> >>> >>> distributed networks.
>>> >>> >>> [14:59] <alown> (Don't forget that our aim for Wave is at the
>>> >>> >>>cutting-edge
>>> >>> >>> of academic research also).
>>> >>> >>> [...]
>>> >>> >>> [14:50] <stenyak> i just threw the question at some friends who
>>> >>>should
>>> >>> >>>be
>>> >>> >>> more up-to-date with networking technologies than me... hopefully
>>> >>>they
>>> >>> >>> comeback with some revolutionary dns-2 design or something that we
>>> >>>can
>>> >>> >>>copy
>>> >>> >>> [15:18] <stenyak> could give as some ideas: http://openpeer.org/
>>> >>> >>> [15:18] <stenyak> (it's not a solution, but maybe they did the
>>> same
>>> >>> >>> reasoning we're going through)
>>> >>> >>> [15:46] <stenyak> another response i got goes along the lines
>>> of...
>>> >>> >>>hard as
>>> >>> >>> fuck, but if you manage to do it, you are a hero
>>> >>> >>> [...]
>>> >>> >>> [15:02] <stenyak> looking at it from a wider perspective, what we
>>> >>>want
>>> >>> >>>is
>>> >>> >>> similar to having each peer shout at the whole world "here i am,
>>> >>> >>>anything
>>> >>> >>> got something for meeee?" in some way that doesn't clog the
>>> >>>internet
>>> >>> >>>tubes,
>>> >>> >>> and that is so fast as shouting would be. i start to think it's
>>> not
>>> >>> >>> physically possible to do that...
>>> >>> >>> [15:03] <stenyak> if publickeys were handed to people based on the
>>> >>> >>> location, then we could have routing tables similar to how
>>> internet
>>> >>> >>> currently works
>>> >>> >>> [15:03] <stenyak> but pubkeys are... well, random. so that kind of
>>> >>> >>>routing
>>> >>> >>> that allows anyone to connect to an arbitrary IP in a matter of
>>> >>> >>> milliseconds is impossible, i believe
>>> >>> >>> [15:04] <alown> So, we end up with DNS for public keys?
>>> >>> >>> [15:04] <stenyak> something like dns, but much faster [wrt.
>>> >>>propagation
>>> >>> >>> times]
>>> >>> >>> [15:05] <stenyak> so in essence, a tree of servers or whatever
>>> >>>(which
>>> >>> >>>is
>>> >>> >>> similar to how wave currently works, right?)
>>> >>> >>> [15:05] <alown> Heh. But the whole point was to avoid the tree
>>> >>>system
>>> >>> >>> currently (since it is susceptible to netsplits)
>>> >>> >>> [...]
>>> >>> >>> [15:56] <stenyak> maybe the real question could be: how do we make
>>> >>>DHT
>>> >>> >>>much
>>> >>> >>> faster?
>>> >>> >>> [16:14] <stenyak> once the initial discovery process is finished,
>>> >>>the
>>> >>> >>> transmission of data will not have the lag associated with DHT, so
>>> >>> >>>even if
>>> >>> >>> DHT takes 10 seconds, that could be acceptable
>>> >>> >>> [16:15] <stenyak> i.e. a new peer takes 10 seconds to be
>>> >>>discovered by
>>> >>> >>>the
>>> >>> >>> rest of participants collaborating in a wave
>>> >>> >>> [16:16] <stenyak> (or viceversa.. the new peer takes 10 seconds to
>>> >>> >>>discover
>>> >>> >>> the participants)
>>> >>> >>> [...]
>>> >>> >>> [16:25] <stenyak> this could shed some light:
>>> >>> >>>
>>> >>> >>>
>>> >>> >>>
>>> >>>
>>> >>>
>>> http://en.wikipedia.org/wiki/Distributed_hash_table#Algorithms_for_overl
>>> >>> >>>ay_networks
>>> >>> >>> [19:06] <stenyak> http://dsn.tm.kit.edu/english/2936.php
>>> >>> >>> *...4) Routing **p2p **messages/events in a pure P2P system (part
>>> >>>5):*
>>> >>> >>> [21:03] <josephg> [...] For now, I want wave to be p2p in the same
>>> >>>way
>>> >>> >>>that
>>> >>> >>> git is p2p.
>>> >>> >>> [21:04] <josephg> that is, I want the core algorithms & data
>>> >>> >>>structures to
>>> >>> >>> use P2P-capable algorithms, and probably the wave servers will do
>>> >>>p2p
>>> >>> >>> between themselves (this is easy because they'll all be both named
>>> >>>and
>>> >>> >>> accessable)
>>> >>> >>> [21:06] <josephg> as for client-to-client p2p, there's a few
>>> >>>options
>>> >>> >>> depending on what kind of use cases we want to support - but I
>>> >>>want to
>>> >>> >>> worry about getting the algorithms p2p-capable first. If you're
>>> >>>keen
>>> >>> >>>to set
>>> >>> >>> up an anonymous, distributed wave system over a DHT - well, I want
>>> >>>to
>>> >>> >>>first
>>> >>> >>> make that possible
>>> >>> >>> [21:15] <josephg> .... and as for ipv6, network admins _love_ NAT
>>> >>>now
>>> >>> >>>that
>>> >>> >>> we have it
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> *5) Implementing "undo": invertibility, tombstones, edge cases,
>>> >>>TP2:*
>>> >>> >>> [00:17] <alown> I am not sure how an 'undo stack' is going to work
>>> >>>(at
>>> >>> >>>all)
>>> >>> >>> with federation...
>>> >>> >>> [00:18] <josephg> well, you just do undo at the application level
>>> >>> >>> [00:19] <josephg> "submit op which inserts text" ... later "submit
>>> >>>op
>>> >>> >>>which
>>> >>> >>> removes text"
>>> >>> >>> [00:19] <josephg> you don't need OT for that.
>>> >>> >>> [00:20] <josephg> I imagine like, a semantic undo. In the client
>>> >>>you
>>> >>> >>>can
>>> >>> >>> imagine making an undo op (which might not necessarily rollback an
>>> >>> >>> operation (because of tombstones and all that))
>>> >>> >>> [00:20] <josephg> ... but would seem that way as far as the user
>>> is
>>> >>> >>> concerned
>>> >>> >>> [00:21] <josephg> then if the user hits ctrl+z, you can transform
>>> >>>that
>>> >>> >>> operation up to the current version and apply it
>>> >>> >>> [00:21] <josephg> - the fact that its an undo isn't really
>>> >>>relevant.
>>> >>> >>> [00:21] <josephg> the bad thing about losing invertability is
>>> doing
>>> >>> >>> playback
>>> >>> >>> [00:21] <josephg> - because you can't scrub back through time
>>> >>> >>> [00:21] <alown> But you have all the operations since the start,
>>> so
>>> >>> >>>you can
>>> >>> >>> play forward at least?
>>> >>> >>> [00:23] <josephg> yeah exactly.
>>> >>> >>> [00:23] <josephg> ... and make like, keyframes of the document
>>> >>> >>> [00:23] <josephg> - and play forward from them or something.
>>> >>> >>> [00:23] <alown> Hmm, so you can do the step-back without
>>> >>>recalculating
>>> >>> >>>the
>>> >>> >>> entire document?
>>> >>> >>> [00:24] <alown> I don't really like the idea of then having
>>> another
>>> >>> >>> datastructure to have to pass around...
>>> >>> >>> [00:24] <josephg> right - if you have a snapshot at version 1000,
>>> >>>and
>>> >>> >>>the
>>> >>> >>> user is looking at 1010 and they try to step back to 1009, you can
>>> >>>just
>>> >>> >>> replay ops 1001-1009 on that version 1000 snapshot
>>> >>> >>> [00:24] <alown> What was the problem with invertible operations (I
>>> >>> >>>don't
>>> >>> >>> understand OT enough yet to be able to properly comment on that
>>> >>>side).
>>> >>> >>> [00:25] <alown> (Other than it confuses people?)
>>> >>> >>> [00:25] <josephg> hahaha actually people seem to love
>>> invertability
>>> >>> >>> [00:25] <josephg> I don't know why.
>>> >>> >>> [00:25] <josephg> I've been trying to remove it from sharejs, and
>>> >>> >>>everyone
>>> >>> >>> gets sad.
>>> >>> >>> [00:26] <josephg> the problem is that if I make an op which
>>> >>>deletes the
>>> >>> >>> whole document (version 100, say) then I undo that operation
>>> >>> >>> [00:26] <josephg> and you insert in the middle of the document at
>>> >>> >>>version
>>> >>> >>> 100, then your op gets transformed to do that insert at the start
>>> >>>of
>>> >>> >>>the
>>> >>> >>> document instead at version 101 (because the content has
>>> >>>disappeared)
>>> >>> >>> [00:26] <josephg> and it never goes back to the middle of the
>>> >>>document.
>>> >>> >>> [00:27] <josephg> so, with tombstones you can get around that by
>>> >>> >>>having a
>>> >>> >>> 'resurrect' operation
>>> >>> >>> [00:27] <josephg> (so deleting the whole document turns the whole
>>> >>> >>>document
>>> >>> >>> into tombstones, then we can resurrect them all again in the
>>> >>>inverse)
>>> >>> >>> [00:28] <josephg> but you can't invert an insert - because
>>> deleting
>>> >>> >>>leaves
>>> >>> >>> the tombstone there
>>> >>> >>> [00:28] <josephg> and if you have a 'real delete' operation, then
>>> >>>yeah,
>>> >>> >>> you're back in the hole
>>> >>> >>> [00:28] <josephg> also, with wave in particular, inverting is
>>> >>>really
>>> >>> >>> complicated
>>> >>> >>> [00:29] <josephg> - see, if the wave says "<annotation
>>> >>>bold:true>blah
>>> >>> >>> blah<annotation bold:false> not bolded"
>>> >>> >>> [00:29] <josephg> then if you insert at the end of the "blah
>>> blah",
>>> >>> >>>it'll
>>> >>> >>> automatically get bolded.
>>> >>> >>> [00:30] <josephg> ... so if the text isn't bolded, and then you
>>> >>>bold it
>>> >>> >>> while I insert at the end of the text, you need to make sure my
>>> >>>text
>>> >>> >>> _isn't_ bolded or something
>>> >>> >>> [00:31] <josephg> .... and yeah, I can't remember - but there's
>>> >>>these
>>> >>> >>> horror cases that I remember kept me from sleeping when I tried to
>>> >>> >>> reimplement wave's OT code in C
>>> >>> >>> [00:31] <alown> hmm
>>> >>> >>> [00:31] <josephg> and it would have been fine if it wasn't
>>> >>>invertible.
>>> >>> >>> Well, at least it would have been tollerable.
>>> >>> >>> [00:33] <josephg> So yeah. Conclusion: You can make invertability
>>> >>> >>>work, but
>>> >>> >>> its kind of a bitch, and you can't make it work for TP2
>>> >>> >>> [00:33] <josephg> which means it won't work if we're federating
>>> >>> >>> [00:33] <alown> How are we hacking around that currently then?
>>> >>> >>> [00:33] <josephg> well, we don't do TP2
>>> >>> >>> [00:34] <josephg> remember, federation just uses a bad version of
>>> >>>the
>>> >>> >>> current client-server protocol
>>> >>> >>> [00:34] <josephg> - arranged in a tree of servers
>>> >>> >>> [00:34] * alown goes and looks up which one TP2 was again
>>> >>> >>> [00:35] <josephg> ... its the one that says you don't need a
>>> >>>canonical
>>> >>> >>> ordering of operations
>>> >>> >>> [00:35] <josephg> sharejs and wave both use the server to pick the
>>> >>> >>>order of
>>> >>> >>> operations (based on which order they reach the server)
>>> >>> >>> [00:35] <josephg> and then they use incrementing version numbers
>>> >>>based
>>> >>> >>>on
>>> >>> >>> that order
>>> >>> >>> [00:35] <alown> ah yep.
>>> >>> >>> [00:35] <josephg> -> for p2p, that doesn't work because you don't
>>> >>>have
>>> >>> >>>a
>>> >>> >>> centralized server, and anyone can send messages to anyone
>>> >>> >>> [00:36] <josephg> and yeah, you need TP2 for that (which sort of
>>> >>>says
>>> >>> >>>you
>>> >>> >>> can apply ops from 3 different sites in any order and it still
>>> >>>works)
>>> >>> >>> [00:37] <josephg> - and apparently someone proved that if you make
>>> >>>it
>>> >>> >>>work
>>> >>> >>> for 3 sites, it works for any number of sites
>>> >>> >>> [00:43] <alown> Anyhow, I can see leaving inversion out for
>>> >>> >>>simplicity, but
>>> >>> >>> don't yet understand why it can't be made to work with TP2.
>>> >>> >>> [00:59] <alown> Hmm. Seen 'A Sequence Transformation Algorithm for
>>> >>> >>> Supporting Cooperative work on Mobile Devices'?
>>> >>> >>> [01:02] <josephg>
>>> >>> >>>
>>> >>> >>>
>>> >>> >>>
>>> >>>
>>> >>>
>>> http://research.microsoft.com/en-us/um/redmond/groups/connect/cscw_10/do
>>> >>> >>>cs/p159.pdf
>>> >>> >>> ?
>>> >>> >>> [01:15] <alown> The main feature is its use of storing
>>> local/remote
>>> >>> >>> operations and processing them much later than receipt time.
>>> >>> >>> [01:17] <alown> ABT satisfies TP1+2, so looks like this should(?)
>>> >>> >>> [01:19] <josephg> need to read it
>>> >>> >>> [01:19] <josephg> ... I'll go through it later
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> *6) Usability of a pure p2p system in Real Life (tm):*
>>> >>> >>> [12:13] <alown> We also don't know if storing ops in a DHT is
>>> >>>efficent
>>> >>> >>> enough for our use case...
>>> >>> >>> [12:14] <stenyak> in any case, let's say i fire up my wavep2p
>>> >>>android
>>> >>> >>> client and want to check for any new waves
>>> >>> >>> [12:14] <stenyak> i definitely won't put up with a wait of 30
>>> >>>seconds
>>> >>> >>>when
>>> >>> >>> i have "this damn fast 4g connection!" in my cellphone
>>> >>> >>> [12:14] <stenyak> i mean, that's the point of view of six pack joe
>>> >>> >>> [12:14] <stenyak> and joe is definitely right..
>>> >>> >>> [12:15] * alown thinks of the hours it took to download the
>>> bitcoin
>>> >>> >>> blockchain from the p2p system
>>> >>> >>> [12:15] <stenyak> or browse through freenet, or whatever... its
>>> >>>painly
>>> >>> >>>slow
>>> >>> >>> [12:16] <stenyak> in the end, i think that most users won't be
>>> >>>running
>>> >>> >>>a
>>> >>> >>> full blown peer, but will be relying on an external server instead
>>> >>> >>> [12:16] <stenyak> i.e. nobody runs their own email servers
>>> nowadays
>>> >>> >>> [12:16] <stenyak> and the same can happen with wave
>>> >>> >>> [12:16] <alown> Should a mobile client be doing the full p2p
>>> >>> >>>federation, or
>>> >>> >>> simply talking to a server which does it...
>>> >>> >>> [12:16] <stenyak> the few who decide to run a full-blown wave
>>> peer,
>>> >>> >>>should
>>> >>> >>> be aware of the problems
>>> >>> >>> [12:17] <alown> So, this should be less of a problem since the
>>> only
>>> >>> >>>nodes
>>> >>> >>> doing p2p will be proper full-time connected servers?
>>> >>> >>> [12:17] <stenyak> the thing is, we can assume most people wont
>>> >>>fire up
>>> >>> >>> their own xmpp server, but go for jabber.org account
>>> >>> >>> [12:17] <stenyak> and the same thing will presumably happen for
>>> >>>wave,
>>> >>> >>> simply because it's easier to do
>>> >>> >>> [12:18] <stenyak> which doesn't pervent me from running my own
>>> >>> >>>full-blown
>>> >>> >>> wave server
>>> >>> >>> [12:18] <stenyak> but that's a use case in which the user knows
>>> the
>>> >>> >>> limitations
>>> >>> >>> [12:19] <stenyak> [...] you and i will run several full-blown wave
>>> >>> >>>peers at
>>> >>> >>> home, at our parent's house, or whatever, but we'll know and
>>> >>>accept the
>>> >>> >>> problems
>>> >>> >>> [12:19] <stenyak> i think that's the way to think about the
>>> problem
>>> >>> >>> [12:19] <stenyak> heck, most people use github for permanent [git]
>>> >>> >>> connectivity ;-)
>>> >>> >>> [12:19] <stenyak> instead of opening ports to their laptop in
>>> >>>their lan
>>> >>> >>> [12:19] <stenyak> and those are the tech-savvy people...
>>> >>> >>> [12:20] <alown> So, we have a p2p system between wave servers and
>>> >>> >>>superwave
>>> >>> >>> servers, with clients connecting to the server rather than doing
>>> >>>the
>>> >>> >>>p2p
>>> >>> >>> itself...
>>> >>> >>> [12:20] <stenyak> i'm not saying it's the way we should do it. i'm
>>> >>> >>>saying
>>> >>> >>> that's the way it most probably will pan out, because it's already
>>> >>> >>> hapennign in 100% of the existing p2p protocols i know of
>>> >>> >>> [12:20] <alown> Hmm...
>>> >>> >>> [12:21] <stenyak> so we should plan for that instead of a
>>> >>>theoretical
>>> >>> >>>pure
>>> >>> >>> p2p world
>>> >>> >>> [12:21] <stenyak> if we assume there's servers like github,
>>> >>>bitbucket
>>> >>> >>>and
>>> >>> >>> sourceforge, then suddently most of the problems go away, while
>>> >>>still
>>> >>> >>>not
>>> >>> >>> preventing from people to run fully p2p if they want
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> *7) Comparison with BitTorrent and P2P-TV technologies:*
>>> >>> >>> [12:21] <alown> BT doesn't have huge servers (and with magnet has
>>> >>> >>>actually
>>> >>> >>> move in the opposite direction).
>>> >>> >>> [12:21] <stenyak> BT has no real-time needs
>>> >>> >>> [12:22] <stenyak> that's why they can afford DHT
>>> >>> >>> [12:22] <stenyak> dht could be used for simulating a forum-like
>>> >>> >>>discussion
>>> >>> >>> in wave. but we can't force that restriction from the server
>>> >>> >>> [12:22] <stenyak> (i say forum-like, because people don't expect
>>> >>> >>>reaction
>>> >>> >>> within seconds there)
>>> >>> >>> [12:23] <alown> How did iplayer do its live p2p broadcastinºg?
>>> >>> >>> [12:23] * stenyak googles what iplayer is
>>> >>> >>> [12:23] <alown> Sorry, BBC iPlayer is their TV-over-the-internet
>>> >>> >>>system.
>>> >>> >>> [12:24] <alown> Originally it used a p2p system, but got lots of
>>> >>> >>>negative
>>> >>> >>> press (because of assosciation with BT since it used p2p), so it
>>> >>>now
>>> >>> >>>uses a
>>> >>> >>> centralized system instead. (And their bandwidth costs are much
>>> >>> >>>higher).
>>> >>> >>> [...]
>>> >>> >>> [12:25] <stenyak> i seem to recall other [p2p] tv clients
>>> >>> >>> [12:25] <stenyak>
>>> >>> >>>
>>> >>> >>>
>>> >>> >>>
>>> >>>
>>> >>>
>>> http://wiki.xbmc.org/index.php?title=HOW-TO:Play_free_P2P_(peer-to-peer)
>>> >>> >>>_online_streaming_TV
>>> >>> >>> [...]
>>> >>> >>> [12:26] <alown> Found a paper titled "RT-P2P: A Scalable Real-Time
>>> >>> >>> Peer-to-Peer System with Probabilistic Timing Assurances" (google
>>> >>>for
>>> >>> >>>it)
>>> >>> >>> [12:28] <alown> Lookt at the paper I mentioned. It relies on
>>> 'super
>>> >>> >>>nodes'
>>> >>> >>> to enable it to keep low latencies...
>>> >>> >>> [...]
>>> >>> >>> [12:27] <stenyak> but i'd be wary of using this (p2p tv) as an
>>> >>> >>>inspiration.
>>> >>> >>> i know there's delay of 10-30 seconds from my TV Formula1 image to
>>> >>>the
>>> >>> >>> telemetry that comes through HTTP from formula1.com website. this
>>> >>>is
>>> >>> >>> regular TV, and they don't care about 30 seconds of lag
>>> >>> >>> [12:27] <stenyak> the only real problem of p2p tv is avoiding much
>>> >>> >>>jitter
>>> >>> >>> [12:27] <stenyak> as long as the stream arrives and is viewable, a
>>> >>> >>>delay of
>>> >>> >>> a minute doesn't matter that much
>>> >>> >>> [12:28] <alown> True.
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> *8) Identifying participants (part 1):*
>>> >>> >>> [12:09] <alown> I am also no longer sure what an 'account' should
>>> >>>look
>>> >>> >>> like, since it has no reason to be stuck to a domain...
>>> >>> >>> [12:10] <stenyak> current wave discovery works by using the domain
>>> >>> >>>name of
>>> >>> >>> the email-address-like list of participants
>>> >>> >>> [12:10] <stenyak> but here we're talking about hashes, public keys
>>> >>>or
>>> >>> >>> whatever
>>> >>> >>> [12:10] <stenyak> which do not (necessarily) point to an
>>> particular
>>> >>> >>>IP:PORT
>>> >>> >>> or whatever
>>> >>> >>> [12:10] <alown> Exactly the problem...
>>> >>> >>> *...8) Identifying participants (part 2):*
>>> >>> >>> [12:33] <stenyak> would it make sense that, while some
>>> >>>participants are
>>> >>> >>> identified by a pubkey (or whatever), many of them could be
>>> >>>identified
>>> >>> >>>by a
>>> >>> >>> user@domain address, with which any peer can quickly locate
>>> >>> supernodes?
>>> >>> >>> [12:33] <stenyak> i mean some kind of dual "pubkey and optional
>>> >>>domain
>>> >>> >>> email-like addr" for the participants list
>>> >>> >>> [12:34] <stenyak> the optional part being essential in the broader
>>> >>> >>>internet
>>> >>> >>> [12:34] <alown> Isn't that exactly what using Mozilla Persona
>>> >>>would do
>>> >>> >>>(map
>>> >>> >>> user@domain to some public-key we can use)
>>> >>> >>> [12:34] <alown> Removing the need for us to have to roll
>>> >>>yet-another
>>> >>> >>> authentication system.
>>> >>> >>> [...]
>>> >>> >>> [12:38] <stenyak> the idea would be that, for a person to be a
>>> >>> >>>participant
>>> >>> >>> in a wave, you *require* his pubkey. optionally, you may have
>>> >>>acquired
>>> >>> >>>ths
>>> >>> >>> pubkey by asking "wave.google.com" about the user "joe", getting
>>> >>>his
>>> >>> >>> pubkey
>>> >>> >>> as a result.
>>> >>> >>> [12:39] <stenyak> and now that you have the pubkey and one of many
>>> >>> >>>possible
>>> >>> >>> email-like addresses (in this case joe@wave.google.com), then you
>>> >>>can
>>> >>> >>>use
>>> >>> >>> the email-like address for displaying in the UI
>>> >>> >>> [12:39] <stenyak> this means that, whoever wants to run pure p2p
>>> >>>peers,
>>> >>> >>> will have to give his pubkey
>>> >>> >>> [12:39] <stenyak> and whoever uses the more traditional style, can
>>> >>> >>>simply
>>> >>> >>> give his email-like addr
>>> >>> >>> [12:39] <stenyak> and the participants list will show a simple
>>> >>> >>>email-like
>>> >>> >>> address most of the time
>>> >>> >>> [12:40] <alown> Do we then allow anyone to 'log in' to any wave
>>> >>>server
>>> >>> >>> running at any domain, since it should no-longer make any
>>> >>>difference
>>> >>> >>>where
>>> >>> >>> they are in the network...
>>> >>> >>> [12:41] <stenyak> yes, that's needed for world-wide-public waves,
>>> >>> >>>which is
>>> >>> >>> equivalent to a read-only forum on the net
>>> >>> >>> [12:41] <stenyak> then there could be server-public waves, which
>>> is
>>> >>> >>> equivalent to requiring sign-in to view a forum (and
>>> >>>coincidentally the
>>> >>> >>> current implementation of public waves in WiaB, right?)
>>> >>> >>> [12:43] * alown has never tested what happens with public waves in
>>> >>>the
>>> >>> >>> current federation system
>>> >>> >>> *...8) Identifying participants (part 3):
>>> >>> >>> *
>>> >>> >>> [21:35] <josephg> - Who is a user? If a user is
>>> >>>stenyak@example.com,
>>> >>> >>>then
>>> >>> >>> we can put a server at example.com and it can hold operations for
>>> >>>you
>>> >>> >>> [21:36] <josephg> ie, if I add you to a wave, my computer (or my
>>> >>>wave
>>> >>> >>> server or something) can send a message to example.com to say
>>> "Yo,
>>> >>> >>>here's
>>> >>> >>> some ops you should know about"
>>> >>> >>> [21:36] <josephg> that would be similar to a mailbox
>>> >>> >>> [21:37] <josephg> ... and it would work pretty well. Bear in mind
>>> >>>that
>>> >>> >>> there's no reason operations have to go through the wave server at
>>> >>> >>> example.com - if we're both on a LAN together, we could discover
>>> >>>one
>>> >>> >>> another through DNS service discovery and send ops directly
>>> >>> >>> [21:37] <josephg> .. without going through our respective wave
>>> >>>servers
>>> >>> >>> [21:38] <josephg> However - if our identities aren't tied to a
>>> >>>domain
>>> >>> >>>(eg
>>> >>> >>> bitcoin), then we'll need to use a dht or something.
>>> >>> >>> [21:42] <stenyak> the conclussion i've arrived at is that "users"
>>> >>> >>> ultimately are a publickey (for which they have the privatekey).
>>> >>>this
>>> >>> >>>is
>>> >>> >>> inconvenient for people to "add you to a wave", so a possibility
>>> >>>would
>>> >>> >>>be
>>> >>> >>> to have a friendlyname=>pubkey server converter. this way people
>>> >>>can
>>> >>> >>>add "
>>> >>> >>> stenyak@example.com", by first finding out what the pubkey for
>>> >>> >>> stenyak@example.com really is
>>> >>> >>> [21:43] <stenyak> the friendlyname would be optional, and in LAN
>>> >>> >>> environments you could directly use the pubkey (instead of the
>>> >>>friendly
>>> >>> >>> name)
>>> >>> >>> [21:43] <josephg> I think people will be more than happy to use a
>>> >>> >>>frienly
>>> >>> >>> name in a lan environment too
>>> >>> >>> [21:43] <stenyak> discovery in a local network could be done with
>>> >>> >>>bonjour
>>> >>> >>> or something too (not just dns)
>>> >>> >>> [21:44] <josephg> I <3 dns-sd
>>> >>> >>> [21:44] <stenyak> [...] maybe they already have a contact list
>>> >>>(read,
>>> >>> >>>list
>>> >>> >>> of friendlyname<>pubkey equivalences) they can use in the UI (even
>>> >>>if
>>> >>> >>>the
>>> >>> >>> underlying system will use pubkeys anyway)
>>> >>> >>> [21:44] <stenyak> and by contact list, i really mean a cache of
>>> >>>some
>>> >>> >>>sort
>>> >>> >>> [21:45] <stenyak> (not some specific, complex roster system)
>>> >>> >>> [21:45] <josephg> and you can do friendlyname -> pubkey really
>>> >>>easily
>>> >>> >>>by
>>> >>> >>> just storing the pubkey on the user's domain
>>> >>> >>> [21:45] <josephg> so, have the example.com webserver host
>>> >>> >>> https://example.com/.wellknown/stenyak
>>> >>> >>> [21:46] <josephg> = your public key.
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> *9) P2P anonymity (peers that want to anonymously lurk in a wave)
>>> >>>(part
>>> >>> >>> 1):*
>>> >>> >>> [12:48] <stenyak> by the way, what about non-participants that
>>> >>>simply
>>> >>> >>>want
>>> >>> >>> to lurk a wave?
>>> >>> >>> [12:49] <stenyak> e.g. i'm given a wave uri
>>> >>> >>> (wave://look_at_these_kittens_wave), and want to view it
>>> >>> >>> [12:49] <alown> Whilst a wave is  public, as soon as they 'read'
>>> >>>the
>>> >>> >>>wave,
>>> >>> >>> they would have a metadata wavelet created, so would become a
>>> >>> >>>participant
>>> >>> >>> (if read-only).
>>> >>> >>> [12:50] <stenyak> and from then on, whenever the wave changes,
>>> >>>someone
>>> >>> >>>will
>>> >>> >>> try to make the change reach the peers with my privkey
>>> >>> >>> [12:50] <stenyak> supposedly..
>>> >>> >>> *...9) P2P anonymity (peers that want to anonymously lurk in a
>>> >>>wave)
>>> >>> >>>(part
>>> >>> >>> 2):*
>>> >>> >>> [21:18] <josephg> stenyak: interesting point about people who want
>>> >>>to
>>> >>> >>>not
>>> >>> >>> participate but follow a wave anyway - its really bad if other
>>> >>>people
>>> >>> >>>can
>>> >>> >>> tell that they're there (assuming the wave is public).
>>> >>> >>> [21:18] <josephg> I guess we just need to make sure that the
>>> >>>metadata
>>> >>> >>>wave
>>> >>> >>> is invisible, and then its ok..
>>> >>> >>> [21:21] <stenyak> invisible.. to what peer/s? surely those that
>>> are
>>> >>> >>> transmitting deltas to the lurkers will need to know they exist?
>>> >>> >>> [21:21] <stenyak> (maybe some of the algorithms behind freenet can
>>> >>>help
>>> >>> >>> with this)
>>> >>> >>> [21:21] <stenyak> (or even TOR)
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> *10) Encryption of waves:*
>>> >>> >>> [21:47] <josephg> for waves themselves, I'm imagining giving each
>>> >>>wave
>>> >>> >>>an
>>> >>> >>> AES key
>>> >>> >>> [21:47] <josephg> then storing an encrypted version of the key for
>>> >>>each
>>> >>> >>> participant on the wave
>>> >>> >>> [21:48] <josephg> .... anyway, that way anyone who has the AES key
>>> >>>can
>>> >>> >>>read
>>> >>> >>> all ops on the wave
>>> >>> >>> [21:48] <josephg> and can participate (because they can encrypt
>>> ops
>>> >>> >>>for the
>>> >>> >>> wave)
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> *11) Addition and removal of participants, and their ability to
>>> >>>read
>>> >>> >>>past
>>> >>> >>> and future wave versions/deltas:*
>>> >>> >>> [21:48] <stenyak> what about removing a user from a wave?
>>> >>> >>> [21:49] <josephg> worst case, we can just make a new key and
>>> re-add
>>> >>> >>> everyone using the new key
>>> >>> >>> [21:49] <josephg> and keep around the old key too
>>> >>> >>> [21:49] <josephg> so people can still read the old ops as well
>>> >>> >>> [21:49] <stenyak> the user can access their browser cache for all
>>> >>>we
>>> >>> >>>care..
>>> >>> >>> if you ever read it, there will be ways to do it. "download now
>>> >>> >>>wave-spy to
>>> >>> >>> read waves you were removed from!"
>>> >>> >>> [21:49] <stenyak> so providing an official way sounds better
>>> >>> >>> [21:50] <stenyak> the AES key could change at any point in time,
>>> >>>e.g.
>>> >>> >>> whenever a new users is added (to prevent them accessing the
>>> >>>history),
>>> >>> >>>or
>>> >>> >>> deleting them (to prevent them from reading future history)
>>> >>> >>> [22:32] <josephg> um - in wave, we let new users see the whole
>>> >>>history
>>> >>> >>> [22:40] <stenyak> but that use case could be desirable, right? and
>>> >>>if
>>> >>> >>>we
>>> >>> >>> support modification/versioning of the AES key, we might as well
>>> >>>allow
>>> >>> >>>that
>>> >>> >>> too? the equivalent in email world would be to forward an email,
>>> >>> >>>removing
>>> >>> >>> the existing quotes
>>> >>> >>> [23:17] <josephg> Yep definitely.
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> --
>>> >>> >>> Saludos,
>>> >>> >>>       Bruno González
>>> >>> >>>
>>> >>> >>> _______________________________________________
>>> >>> >>> Jabber: stenyak AT gmail.com
>>> >>> >>> http://www.stenyak.com
>>> >>> >>>
>>> >>> >
>>> >>>
>>> >>>
>>> >>>
>>>
>>>
>>>
>>

Mime
View raw message