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 > <[email protected]> > 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: [email protected] > > -- Nathan of Guardian [email protected] _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
