[guardian-dev] Connecting to nearby peers without user interaction

Nathan of Guardian nathan at guardianproject.info
Mon Feb 16 21:48:54 EST 2015



On Mon, Feb 16, 2015, at 08:29 PM, Paul Gardner-Stephen wrote:
> Hello,
> 
> On Tue, Feb 17, 2015 at 11:03 AM, Nathan of Guardian <
> nathan at guardianproject.info> wrote:
> 
> >
> >
> > On Mon, Feb 16, 2015, at 07:10 PM, Paul Gardner-Stephen wrote:
> > > Hello all,
> > >
> > > Just a heads up that we have finally been able to start working on
> > > merging
> > > the GilgaMesh functionality into Serval.  This should within a month or
> > > two
> > > result in the ability to send and receive encrypted, authenticated MeshMS
> > > messages between nearby handsets using the Bluetooth name hack. More news
> > > as we make progress.
> >
> > Excellent. BTW, my proposed verb / name for this activity is "chime"
> > within the wind metaphor I am using. Chime is meant to be an
> > impl-indepedent description of async/broadcast announcing to physically
> > nearby peers that you are available to speak a certain protocol/scheme
> > via a specified hardware address or other radio identifier.
> >
> 
> No problem from our end using "chime" as the name, although the
> implementations will necessarily be incompatible since there will be
> different protocols sitting on top.

Yeah, I think that is a good thing. I am trying to move us away from the
implementation/app/stack as the definition of what we are doing here,
and instead think about the behaviors and conventions at work. It may
end that one implementations ends up becoming dominant down the road,
but considering that this is all about decentralized communication
happening within smaller, somewhat self-selected communities, it may
not.

> 
> 
> > On the net, you ping. On the web, you link. In wind, you chime!
> 
> 
> Sounds good :)


Right now, it really feels like the web before the web, in that there is
a place that we can't all yet see or describe, but it is there, and the
only way we talk about is either "mesh" or "WifiDirect SDP broadcast of
Bluetooth MAC Address followed" or "Bluetooth Namespace Overloading",
and so on... when I tell people "there is a new type of communicating
called chime and it works over nearby wireless broadcast to tell devices
around you that you are interested in connecting" they get it.

Chimes really do sound good, especially in a gentle breeze!

Anyhow, back to the code!

+n

> 
> Paul.
> 
> >
> >
> > >
> > > Paul.
> > >
> > > On Sat, Feb 14, 2015 at 6:07 AM, Michael Rogers
> > > <michael at briarproject.org>
> > > wrote:
> > >
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA256
> > > >
> > > > On 13/02/15 16:33, Nathan of Guardian wrote:
> > > > >> In both cases, the Bluetooth MAC address is published in a DNS
> > > > >> TXT record via Wi-Fi Direct service discovery. Reverse
> > > > >> engineering the rest of the FireChat protocol is left as an
> > > > >> exercise for the reader. ;-)
> > > > >
> > > > > I had a change to speak with the Rangzen team recently
> > > > > (denovogroup.org/main/rangzen-project/) and they are doing the
> > > > > exact same thing.
> > > >
> > > > Cool! Maybe we should put together some docs on how to do this.
> > > >
> > > > > Would it make sense to publish more than the Bluetooth MAC in
> > > > > there? What about public keys, onions or other decentralized
> > > > > identity and routing information?
> > > >
> > > > I think it depends on the use case. If you want to reconnect to the
> > > > same peers via Tor when they're no longer in range, maybe it makes
> > > > sense to publish an onion address here. If you want to build a trust
> > > > system where you prefer to connect to recognised/reputable peers,
> > > > maybe it makes sense to publish identity information here. But my
> > > > instinct is KISS - publish only the information needed for making a
> > > > connection, then handle all the other stuff after you connect.
> > > >
> > > > Cheers,
> > > > Michael
> > > > -----BEGIN PGP SIGNATURE-----
> > > > Version: GnuPG v1.4.12 (GNU/Linux)
> > > >
> > > > iQEcBAEBCAAGBQJU3lKBAAoJEBEET9GfxSfMpoAH/2m03Ba8VLDuf4dgZkHTHUgN
> > > > a6Us0Xam6vir4aDXtBXkdR4hWlXqIQASzTyu88u+mZXRoyB3L9O1QTNdKPItoVry
> > > > wPWxA1y1G7qx1p2qOzkI9mNOI+lG/q3KtgecR+ahnXBbQI4zmICsMzSsAHZUVRaP
> > > > CnnMUht15uNQxXfMY8HX0Y3Fdr9BKlbp5aTfUFBnTdUnHS/CRcbsuSXRHEArYrfE
> > > > qyvUeWLHu6MJyd6Br6ySy4qzdMpwU71bVx8BjOi2BR9AGv1o9PrgOQi9Lws2geMI
> > > > nGppQeDd+SGdfv2HZkY3cotW4NKb3eRW2nURySDysQcWrb4ivim+3Dp8dSRf1Ms=
> > > > =G0VA
> > > > -----END PGP SIGNATURE-----
> > > > _______________________________________________
> > > > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> > > > To unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
> > > >
> >
> >
> > --
> >   Nathan of Guardian
> >   nathan at guardianproject.info
> >


-- 
  Nathan of Guardian
  nathan at guardianproject.info


More information about the guardian-dev mailing list