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

[Hans-Christoph Steiner]

Michael Rogers:
> 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.

For F-Droid advertising local "swap" repos, we plan on advertising the public
key fingerprint that represents the local repo.  That key is used for signing
the local repo metadata and generating the HTTPS certificate.  This public key
fingerprint functions as the unique ID for the repo itself, outside of the
data connection, IP address, etc.  This then allows FDroid to scan the locally
available repos, and only automatically connect to those that have
fingerprints that are recognized.

For advertising via bluetooth name and WiFi AP name, I imagine that FDroid can
just use the public key fingerprint as the name itself.  In Bonjour, I think
it'll probably be better to include the public key fingerprint in a DNS TXT
record.

.hc


-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20150217/d5b58891/attachment.sig>