Geo-Origins – Fixing Location-Based Triggers (iBeacons, RFID, etc.) | Hacker News Reader

Geo-Origins – Fixing Location-Based Triggers (iBeacons, RFID, etc.)

github.com

22 pointscsuwldcat5 comments

I don't know why it's not implemented like traditional Bluetooth, by pairing. Each beacon vendor could generate a 6 digit code from a private key implemented like 2-factor auth. A corresponding iPad or device in a physical location could show the same code so users know they're pairing to the beacons in a store or location.

Then they proximity-fence these pairing requests so it only activates when they tap a device on a "pairing beacon."

I'm not quite sure why you'd need all those layers of misdirection, this eliminates all of the complexity. If the platform knows a region in space is tied to an origin - like a Target store is tied to target.com - you have everything you need to enable seamless push notifications directly from the beacons.

Here's how the system works:

1) User walks into the store and receives the first ping from a beacon (or other location-based trigger)

2) The platform/UA shows a bit of UI asking the user if they would like to receive LBT content from the entity - for example, Target.com.

3) There are 3 options: disallow, allow for this location (aka: "Just this Target store location"), or allow for all locations (as in: "Allow notifications from all Target store locations"

4) After selecting to see notifications for the location, or all the entity's locations, the user no longer needs to do anything, they just receive content directly from beacons within the location.

This eliminates the need for every app to listen for beacons, and beacons can now pass content URLs, which the platform/UA can open directly. This way, there is no vendor or walled garden dependencies. The system grows organically, and scales without micromanagement.

Do you understand how that works? I can try to answer any other questions you may have.

That would not work because someone could throw a bunch of third party beacons in the target store constantly asking for permission requests.

And in a more likely scenario, walking down a crowded street would trigger endless pairing requests.

Using a geofence for LBT permissions ignores the fact that BLE is being used for its low power properties. If a LBT needs to trigger a GPS lookup, we're going backwards.

GPS need not be always on, the platform can minimize activation of GPS in a variety of ways. All current systems for location-based triggering are non-starters - they each fail in one or more of the following ways:

- Forces apps to be the trust layer, which prevents wide-scale, predictable content delivery

- Eliminates the ability to do seamless, proactive push content from LBTs

- Requires the existence of walled gardens and vendor-dictated management layers that encumber the system and creates gatekeepers

This system solves all of these things for locations that can be tied to their owning origins.

Please continue the debate, I want to hear everyone's feedback.

Reply on news.ycombinator.com