On Tue, Jun 11, 2013 at 11:08 AM, Bruno Gonzalez (aka stenyak) <sten...@gmail.com> wrote: > Please excuse the slightly offtopic question. I need to read more about OT > to completely understand your discussion, however I have a question which > is somewhat related to your P2P suggestions: > > Currently, WiaB federation is assumed to work using signed certificates in > order to prevent security issues (MITM attacks, etc). In the P2P system > you're all suggesting, I'm assuming we wouldn't be requiring every peer to > also use ca-issued certificates. Which means that, however the P2P > OT/federation system works, it would rely on "something else" than these > certificates; and which would hopefully be easier to set up (1). > > Additionally, I'm guessing that domains wouldn't be required, but instead a > simple ip+port pair could be used somehow (stenyak@192.168.0.15:5671 or > something?)
First, we don't need peers to be globally addressable. They can just connect to servers or other peers on local network (or whatever). Secondly, we won't tie your identity to the IP of the computer you're on - your identity doesn't change when you move between devices or when your computer's IP changes. We probably want some method of signing / encryption where your local node stores your private key so other peers can verify the authenticity of your operations. > Is it possible to use this "something else" (both the certificate > alternative, and the domain alternative) for federation in current WiaB, > and if so, is there any reason (other than lack of resources) for not > having it in WiaB already? Personally, I'm a big fan of mozilla persona for WIAB. That would remove heaps of the sign in flow and remove the need to store user accounts. http://www.mozilla.org/en-US/persona/ > (1) For example, when creating my ca-issued certificate, I was asked to > provide an address and phone number. Even if I could maybe provide fake > data, and even if I could follow the wiki instructions and make my server > federable, it's still yet another barrier that some people (like > myself-a-year-ago) may not want or have the will to go through. We might be able to use self-signed certs + key pinning + TACK, but its a bit of a diversion here. > On Tue, Jun 11, 2013 at 7:44 PM, Joseph Gentle <jose...@gmail.com> wrote: > >> The biggest benefit to a P2P-capable system is federation. Currently, >> the wave federation algorithms create a distributed tree of servers, >> and they're vulnerable to netsplits if one of the root servers goes >> offline. Maintaining that tree is complex and unnecessary - there are >> better algorithms we can use instead. >> >> I imagine most devices will (most of the time) still connect to a >> single server. But if our OT system can manage P2P anyway and our >> system supports OT over arbitrary JSON blobs, there's a few really >> neat things we can do with that. >> >> So, this is something I've been wanting for ages - Imagine you're >> working on a software project. You put all the source code inside a >> JSON wave object and you edit it there. Because its a shared OT >> document, your compiler can join in on the document and annotate your >> code (live) with syntax highlighting, errors and autocomplete >> suggestions. It would know at a very granular level which functions >> need to be recompiled as you edit. Your unit tests could rerun >> themselves automatically and mark in your source code which tests >> failed and where. Its like a lego set for IDEs - your editor doesn't >> have to understand your programming language, your compiler doesn't >> have to know what editor you're using and where, and all the pieces >> can be on whatever computers are most convenient for you. And of >> course, you can pair program for free. >> >> You could build stuff like that on top of ShareJS today, but it would >> require a centralized server - and you have to put that somewhere. If >> the server is on your local machine, you can't upload the edits you're >> making to another OT server (like your private wave server). If its a >> remote server, you'll get terrible latency between making a change in >> your editor and your compiler finding out about it. With a system that >> supports P2P OT, we can make servers connect any way we want and It'll >> all just work. >> >> -J >> >> On Mon, Jun 10, 2013 at 1:38 PM, Dave <w...@glark.co.uk> wrote: >> > [John B - I wasn't sure where else it would be appropriate to ask this >> > question, but please forward on anywhere you think it appropriate] >> > >> > There are many things about Wave and WIAB that I would like to see >> improved >> > / changed, but based on my readings I've been content with the TP1 OT >> > approach chosen by google (not that I'm even close to an expert) - even >> if >> > the WIAB implementation would benefit from some love. >> > >> > But one of the things mentioned in the recent wave-forward hangout was >> the >> > weakness in Wave's OT implementation for a required canonical version of >> a >> > given wave (providing absolute ordering of changesets). Specifically, >> this >> > effectively prevents 3 party P2P messaging where there isn't guaranteed >> to >> > be that one canonical ordering. My understanding is that Joseph is >> playing >> > with some alternative OT algorithms that are TP2, and therefore don't >> > require arbitration of changeset order. This was specifically called out >> as >> > an advantage to support P2P messaging and running the full stack on a >> phone. >> > >> > That got me thinking - why would you want to do that? What are the >> benefits >> > of P2P messaging, and are there other reasons to need TP2? >> > >> > Most of the messaging and collaboration systems I could think of are >> > client-server (some with federated servers) and Wave/WIAB support this >> with >> > TP1. Most networked phone apps that I'm aware of are also client/server, >> > and at first glance this seems a good thing - it makes addressing easier >> and >> > avoids issues with intermittent connectivity. The ability to have a >> simple >> > "wavelike" server (and detached clients) >> > >> > I suspect I'm missing something, and I wondered if I'm alone? >> > >> > My understanding is that technical interop between the various wave-like >> > communities will need us to use the same OT alogrithm (eventually), so >> > clarity on the pros/cons of keeping or changing the wave OT approach >> would >> > be a good first step in that direction! >> > >> > Dave >> > > > > -- > Saludos, > Bruno González > > _______________________________________________ > Jabber: stenyak AT gmail.com > http://www.stenyak.com
