cgewecke
commented
8 years ago Actually above seems somewhat hopeless - astronomical amount of confusion around whether/how this is possible. A second websockets based auth solution is conceivable: Pi broadcasts two beacons - a fixed 'identity' beacon that is also the address of a partitioned websocket channel, AND a variable auth beacon that randomly changes its major and minor. iOS device hears the ID and then checks the auth and passes the auth major/minors through the appropriate websocket. If they match it's confirmation that device is hearing beacon in real space and time. Only unknowns here are about broadcasting two signals from the PI and coordinating w/in the the server.
Answers are: They need to be separate node processes driving separate dongles, and they can communicate using messenger.js.
The main weakness of this system is that a relay could be placed near the node and connect to another node that fired the same numbers at the app somewhere else. . . .
Other security stuff to consider is signing the websocket exchabge with a secure key known to the system only, but unique to each instance of the app.
https://github.com/don/cordova-plugin-ble-central
Basic strategy at present is to listen for iBeacon signal from whale-island and then either:
a) Begin advertising over BLE as a peripheral. Whale island will be able to read a user's public key, an application id, possibly an app instance id, and the event that triggered the exchange. Pi can write to a peripheral to confirm a tx, status change, or failures. (Super unclear from the Apple docs and online whether a non-iOS device can connect to an iOS device acting as a CB Peripheral in the background.) This suggests a possible approach.
b) The reverse: have the app scan for a specific uuid, connect and write its data into the relevant characteristics.
Ultimately some kind of websocket solution is necessary as well, where the Pi looks up the client account address in a DB, maybe establishes a connection to the client through the cloud to receive exit events, and probably to figure out what contracts to execute.
We'll try to do as much BLE data transfer as possible in the interests of getting close to full decentralization, pending a realistic method of searching a blockchain name registry for contracts linking the node and the client. Maybe the app should just sign the tx and the pi can approve it.
This whole process is necessary because:
a) A bluetooth connection means the mobile device can physically connect to the island, it's a strong indication that spoofing isn't happening. b) Treating the PI as a peripheral is problematic - only one device can connect over the channel at a time under GATT. Opening multiple channels . . . etc . . .
Current unknowns include whether this stuff can be done programmatically - e.g. without triggering a pairing request.