Add BD_ADDR

[decanus]

Bluetooth devices have unique identifiers known as BD_ADDR, these should be added to multiformats and may be useful especially if libp2p adds a bluetooth specific transport. Another thing to consider is the addition of a Mac address identifier.

[raulk]

Pinging @tomaka and @moul, as they both have made headway bringing in bluetooth support for libp2p (rust and go, respectively). I'm curious if a BD_ADDR atom in the multiaddr is sufficient to express all that is needed to form a capable full-duplex Bluetooth connection.

[decanus]

@raulk it's probably not sufficient as it doesn't express the capabilities of a bluetooth device, but its a way to have unique identifiers in bluetooth first networks.

[tomaka]

For my bluetooth experiments, I went for /bluetooth/xx:xx:xx:xx:xx/l2cap/2/rfcomm/N (where the xx thing is the BD_ADDR and N is the RFCOMM port).

[decanus]

@tomaka do you think it makes sense to add a devices characteristics or services to a multiaddr too?

[tomaka]

I think that there should be a "libp2p Bluetooth" specs, just like there's a "libp2p mDNS" specs for example.
It should notably contain how devices discover each other (I went for SDP and transmitting the PeerId over an attribute) and how they can talk to each other (RFCOMM? Something else?).

[decanus]

So RFCOMM won't work for bluetooth on iOS, which is something to consider with libp2p.

[tomaka]

So RFCOMM won't work for bluetooth on iOS

Is it because iOS only gives you access to Bluetooth Low Energy?
If so, as far as I know, streaming bytes in a TCP/IP-like fashion isn't possible with BLE.

I might be wrong, but RFCOMM is specifically advertised as the Bluetooth equivalent of TCP, and if it's disabled then there has to be a reason.

[decanus]

@tomaka iOS exposes the L2CAP packet based protocol but not RFCOMM streaming protocol. RFCOMM is built on top of L2CAP.

[moul]

cc @aeddi @gfanton (both worked on low-level go-libp2p to integrate BLE)