eddystone

I fail to see a reason where it would be a violation because of the following reasons: 1) it's a response to a user's request, i.e., not initiated by the repo author 2) it depends on consensus of the user. 3) it's not automated (most of the items from the policy are related to automation). 4) the repo author has no obligation whatsoever of maintaining the project. He is not paid or forced to do it. 5) if the user really wants to apply this change or disagrees with this practice, he/she can always fork it. That said, I understand that it may still not feel "fair" compared to other projects that don't follow this practice. Or the feeling of "wanting to help but you're asked to do some things first". Companies already do that to accept your pull requests though [0], which takes way longer than giving a star - and I didn't see a complaint abo

Here's the spec, in case anyone is interested: https://github.com/google/eddystone/tree/master/eddystone-ei...

Eddystone has a couple different modes. One of them is to transmit a URL, but beacons can also be configured to transmit a UID. Not all Eddystone beacons will be transmitting a URL. That said, I believe Physical Web does use the Eddystone-URL mode. Spec: https://github.com/google/eddystone/blob/master/protocol-spe...

> information about users won’t be saved until they click a link, so the beacon owner will not know anyone was nearby until they visit the website It sounds like the metadata is sourced from the bluetooth-broadcast, not via a separate request. However, the specification itself[0] only has room for the URL and the telemetry data, so how they achieve this in practice is questionable. [0] https://github.com/google/eddystone/blob/master/protocol-spe...

As others noted, the packet format is documented. But this: > I really dislike the decision to make it part of the Play API (as opposed to standard Android), as it ends up not being really open after all. doesn't really make sense. How do you open source storing data associated with a beacon in the cloud? The beacon is dumb so it's the client program that associates the broadcast with some action. The only way to open source that is to document the format of the beacon broadcast and release tools to let anyone receive them and parse them, after which any action can be taken. Which is exactly what was open sourced. The Play Services support seems to just be that you don't have to do it yourself if you don't want to on Android™ devices, because play services already has support. If they really want this to take off in iOS apps, though, the

It looks like they've documented the packet format here: https://github.com/google/eddystone For example URLs: https://github.com/google/eddystone/tree/master/eddystone-ur..., UIDs: https://github.com/google/eddystone/tree/master/eddystone-ui..., and telemetry: https://github.com/google/eddystone/tree/master/eddystone-tl...

isn't the link on their github to the packet format? https://github.com/google/eddystone/blob/master/protocol-spe... I love this release Google needed to take a direction there are so many use cases for this sort of micro proximity I cannot wait to see what folks can do without freaking people out over privacy..