Additional transports

[eira-fransham]

• [ ] IPC
• [ ] Bluetooth
• [ ] NFC

These are all interesting because they have their own discovery mechanisms that don't require Kademlia and in fact discovered addresses should not be propagated over "globally addressable" transports like IP since they would be almost entirely false positives. We could propagate bluetooth addresses to other bluetooth devices (to prevent an identify call) but I don't think that's necessary since we already narrow down the number of devices that we need to connect to by having the concept of "pairing", where the user selects which devices to trust.

I think that a good API would be for these to each have a Controller struct that has a fn scan taking a Fn(impl Stream<Item = Client>) -> impl Stream<Item = Client>, where Client is a struct containing information on a discovered client and the output is a list of clients to attempt connection to. For a chat app, this function could hand off control to a UI dialog and then return the clients that the user has chosen.

[tomaka]

Bluetooth: https://people.csail.mit.edu/rudolph/Teaching/Articles/BTBook-march.pdf chapter 3.2

[thomaseizinger]

NFC would be pretty cool!

Combined with libp2p compiled to WASM, I guess you could then somehow pair two mobile phones via NFC and use bluetooth as the transport?

[YoshieraHuang]

I think ipc is a good idea.

[TheRook]

LoRA is becoming a lot more useful IoT, it is able to achieve very large ranges on free bands, and LoRAWAN is designed for an entire city.

[thomaseizinger]

Closing to tidy up the issue board. More transports are still welcome.