incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Blossom - Shore Communications Inc." <>
Subject Re: Moving Wave Forward
Date Wed, 29 May 2013 15:31:04 GMT
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

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,


On Wed, May 29, 2013 at 10:48 AM, Bruno Gonzalez <> wrote:

> On Wed, May 29, 2013 at 3:59 PM, John Blossom <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message