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

[Nathan of Guardian]

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.

On the net, you ping. On the web, you link. In wind, you chime!



> 
> 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