Hans-Christoph Steiner wrote: > > > Michael Rogers wrote: >> On 02/10/14 21:07, Chris Ballinger wrote: >>> However, I think it would be beneficial to utilize other transports >>> for Android<-->Android and iOS<-->iOS for increased overall range / >>> mesh quality. The iOS MultipeerConnectivity framework uses Wifi / >>> Bluetooth in a proprietary/closed way and will never interoperate >>> with Android (by design). Android supports Wifi Direct in a more >>> open fashion, but it will never interoperate with iOS because Apple >>> likes to be stubborn. >> >> Someone reverse-engineered the wifi parts of the Multipeer >> Connectivity Framework - it's a combination of Bonjour for service >> discovery, self-signed X.509 certs for mutual auth, and DTLS with a >> magic byte prepended for data transfer. It should be possible to >> create a compatible Android library. >> >> https://nabla-c0d3.github.io/blog/2014/08/20/multipeer-connectivity-follow-up/ >> >> I don't have time to work on this right now, but it would make a good >> Masters project. > > This sounds like the most promising approach for device-to-device transfer. > If there is a decent chance of making a cross-platform compatibility library, > then we have a proven technology on Android as well. And based on your > summary, it sounds like it is based on open standards (Bonjour, X509, DTLS). > > Anyone seen anything about the WiFi mode it uses? If Apple uses adhoc mode, > which every major OS but Android supports, we're screwed. > > .hc >
Reading through this and other materials, it seems that MultipeerConnectivity works over regular WiFi, like if the devices are on the same WiFi, so that'll work on any platform. Its funny to see how similar this is to what we came up with for FDroid/Bazaar. https://nabla-c0d3.github.io/documents/BH_MultipeerConnectivity.pdf Seems like at the very least, we want to use DTLS as the core communications protocol. Working with X509 certificates is fine, I guess those will never go away ;-). FDroid already handles regenerating an X509 certificate for each new WiFi IP address, while re-using the private key. In this context, I can see using the Bluetooth/Wifi name broadcast for discovering other local devices. The broadcast could have a magic byte to mark it as a discovery broadcast, then include potential channels available for connection: the current wifi access point its on, the current IP address, Bluetooth LE, WiFiDirect, etc. The hard part is the gilgamesh broadcast would compete with the normal Bluetooth and WiFi processes. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 _______________________________________________ Guardian-dev mailing list Post: Guardian-dev@lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: guardian-dev-unsubscr...@lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/archive%40mail-archive.com You are subscribed as: arch...@mail-archive.com
