Thanks, Bruno, this is initial thinking, so it does require some refinement. Let me try to clarify this a bit.
On your point a), that's definitely part of the idea - provide email-like synchronization with their remote Wave server(s) of choice to enable people to work in offline mode. Offline mode would also enable people to create new waves, add in applets available in the offline environment, which could include applets designed to interact with mobile phone sensors, etc.- in other words, data inputs and outputs not Web-dependent for their functions. When back online, the local cache syncs with the HTML5 offline space. How much of that is truly federation as it exists today at the server level is up for grabs, but that's the idea. The net result is certainly LIKE federation - you're treating the mobile device as a node requiring synchronization. On b), not so much the idea, though as you laid it out it's intriguing, of course. For b), the thought is that we enable mobile devices to federate with one another directly on some limited basis via side-door communications methods such a NFC, bluetooth, mobile hotspot, etc. I know that there are some tricky things in this, but this is the concept - not so much going through the Web but sharing knowledge more in a mode of multiple offline devices, which eventually get to sync with Web servers via a). So, for example. I am a farmer in Ghana, I went to my market town, where FINALLY there was Internet connectivity, and I got syncing for many of my waves into the local device - the ones that matter most to me and my community when I am offline. I return from the market town to my village, and others want to learn about what's happening in those waves. I use Bluetooth or whatever comms are available (even USB or sneakernet, potentially) and other devices in the community can get a copy of what I found. This may include devices in the local school, which may be equipped with a true server node, which can make it available to multiple users via a LAN within the school environment. Now b) is where some of my personal passion lies, but I recognize that for commercialization a) is a far higher priority. I hope that this helps. Many thanks, John On Wed, May 29, 2013 at 10:48 AM, Bruno Gonzalez <[email protected]> wrote: > On Wed, May 29, 2013 at 3:59 PM, John Blossom <[email protected]> wrote: > > > Especially if some form of federation powers peer-to-peer mobile sharing > > for Wave, then basic setup needs to be baked in. Think of email - it's a > > little geekish to input your SMTP and POP addresses, but in general > that's > > all it takes for a user to connect to email - perhaps it needs to be at > > least as simple for default Wave federation. > > > > I feel confused about this point. > > In the GoogleDoc slide #4, it's mentioned that "any device can federate > with any other". Does it refer to: > a) re-using the server-to-server federation protocol for client-to-server > communication, but still having a wave server located between both clients; > or b) deploying a wave server together with each client (e.g. deploying a > server+client in my cellphone connected to the wifi at work, and deploying > a server+client in a laptop connected tomy home ethernet network), and > magically punching through firewalls, nats and the likes in order to > directly connect the two devices without a server? > > > Point a) would be interesting, because the work is mostly done (federation > may be easy or difficult to get working, but it does work), and it could > help a client that has been offline for a while and needs to synchronize > with the wave server, by dealing with all possible conflicts between client > and server operations (which I guess is what current federation > implementation in WiaB may already be doing, merging OT operations coming > from a different, federated, server?). > > Regarding point b), I fail to see how it can work without a dedicated 24/7 > server that bridges firewalled clients. Just like the recently released > BittorrentSync peer software still relies on an official 3rd party server > in order to deal with the (numerous!) cases when clients are behind a NAT > or whatever, even when the software claims to be P2P. > > > Please forgive me if what I said doesn't make sense, i'm not really too > well versed in these matters so maybe I'm seeing obstacles that don't > really exist :-) > > -- > Saludos, > Bruno González > > _______________________________________________ > Jabber: stenyak AT gmail.com > http://www.stenyak.com >
