On Tue, Feb 17, 2015 at 1:18 PM, Nathan of Guardian < [email protected]> wrote:
> > > 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 < > > [email protected]> 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! Indeed :) But we should probably think about writing a paper about Chime as the enabling foundation, once we get our respective implementations to an interesting point. Paul. > > +n > > > > > Paul. > > > > > > > > > > > > > > > > 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] > > > > > > -- > Nathan of Guardian > [email protected] >
_______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
