

Geo-Origins – Fixing Location-Based Triggers (iBeacons, RFID, etc.) - csuwldcat
https://github.com/csuwildcat/geo-origins/blob/master/explainer.md

======
chrischen
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."

~~~
csuwldcat
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.

~~~
chrischen
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.

------
e28eta
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.

~~~
csuwldcat
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.

