Geo-Origins (location-based triggering standards)

If you’ve used any location based triggering systems (iBeacons, etc) in practice, you will immediately notice they are fraught with show-stopping UX and a generally terrible, app-centric trust model that prevents wide-scale implementations that provide content from a diverse range of sources. I have a proposal to fix this, let me know what you think: https://github.com/csuwildcat/geo-origins/blob/master/explainer.md

I have to be honest - I’m not entirely sure I get it. You say it would be like the geolocation thing in web pages - would it only apply in web pages?

Yeah, I’ll try to explain again:

If the UA/platform (any UA: web, Android, iOS, etc.) knows that a given area of space is tied to an origin - like a Target store is tied to target.com - we can create an organic system of trust that does not rely on apps to all listen just to do the same thing, or contorted UX flows that are incredibly cumbersome.

Here’s how the user flow works:

1. The user walks into a store and receives a 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. (this all I meant by a geo-location-esque permission prompt). 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”)
3. After the user allows notifications for this entity’s single location (or all of the entity’s locations), the user no longer needs to do anything, they can receive content URLs directly from beacons within the location.
4. All LBT pings in the location are safe, because they adhere to the entity.json file tied to the location. This file specifies the domains that are allowed to activate in the location’s bounds.

Does that help?

Interesting! I like the idea of tying this into the origin model that underlies the web.

I suggest following RFC5785 and defining the well-known location of the geofencing data to be at /.wellknown/, with some more descriptive name.

What prevents malicious (or just stupid) entities from over-claiming space? The location file lets you specify any number of locations; a dumb store could accidentally claim an entire mall, for instance, and override anyone else wanting to do physical pings, or an origin could claim public spaces with addresses.

Do you envision any scoping in the file being necessary? Target has thousands of locations; listing all of them in the one file can easily mean a meg of data being slurped down on first ping.

The base descriptor file must live on root, so it is always accessible cross-origin in an expected place.

As far as claiming space you do not own, that part is a function of the platform and geofencing. The platform must determine which domains pertain to which geo areas. Google already does this in its map product - points and buildings are already associated with the domains of businesses, entities, and organizations. When a location cannot be linked, or has yet to be linked, to a domain by the platform, it reverts to the open model described in Scott Jensen’s Physical Web proposal.

As far as scoping or truncation in the entity.json file, I would love to see any potential size issues handled via JSON-LD.