Using the physical web with beacons and Eddystone URLs.

I was hanging out at the Nashville Game Jam when I noticed several unrecognized notifications for websites pop up on my phone. Not something I’d seen before, I had to look into this interesting new (to me) thing. These turned out to be Bluetooth beacons configured with Eddystone URLS. On recent Android phones, the default Google software includes something called “Nearby” which, if Bluetooth and locations are enabled on your phone (which I guess they probably are for most), if it picks up the appropriate broadcast code, it will display a notification with an icon, a link and a short description. With a little work, I was able to get this working for my own needs and I will describe how.

I was already a little familiar with Bluetooth beacons from a locating project at a previous place of employment but this was a new thing on me. A Bluetooth beacon transmits (and potentially receives) specific data packets. There is a variant of this which is called an Eddystone URL which is a format which slightly condenses a URL in order to fit it into a data packet.

If you want to dip your toes into the water and you have a Raspberry Pi, you’re in luck. If you have Bluetooth (and the Pi 3 has this built in), you can make it behave as one of these beacons. I found excellent instructions here. This may work out-of-the-box for you but there are several pitfalls and trick that are not well documented. The page is also an excellent source if you are interested in familiarizing yourself with the Eddystone format and the Pi’s Bluetooth operations without getting into too much depth.

Google pre-verifies the web page: The Nearby app also does not retrieve the information from the web page directly but it is loaded within their network and forwarded to the Nearby app.
Google’s pre-verification is cached: If you make an error which means that Google will not pass your page to the Nearby app, once you have corrected it, it may not recheck the page for a long time. I have not managed to pin down exactly how long but I have seen *at least* 4-6 hours. There appears to be no way to force a re-check. This also applies if your page is working and you make changes.
The URL must be an https URL: Google decided for reasons that the URL must be an https url. It’s not well explained but I suspect that this is to prevent people with open WiFi hot-spots from directing people to websites and stealing information. https, in theory, at least ensures that people are connecting to the sites they believe they are.
The certificate must be valid: This seems like a no-brainer but it eliminates self-signed certificates, expired certificates and certificates that don’t represent the site. As an additional wrinkle, I was running with a certificate from StartSSL which several providers decided to revoke their CA status and my certificate chain became invalid, causing my URL to no longer function. Easily fixed by obtaining a certificate from a different provider but something to be aware of.
The page must have a title tag: Easy to miss when you’re doing some quick testing but if you don’t have a title tag, you won’t show up in Nearby.
Icons: The usual browser icon types seem to be supported. favicons or link tags work.
Redirecting: Main website not on https and thinking of just doing a redirect from the https site to the http site? Don’t. Google detects this and if the final endpoint of the page is not https, it will not show up in Nearby. This applies both to HTTPS header redirects and HTML meta tag redirects (I have not tried extended times on the meta tag, only 0s redirects). I have not tried JavaScript redirects but there’s a chance they detect those also. It might be possible to serve google different pages without redirects than you do to other users but I have no idea what would happen if Google detected this.
Pre-verification: You can pre-verify your page here. Note that this doesn’t seem to detect some error conditions such as a missing title tag and my unacceptable StartSSL certificate was verified fine but it is helpful.
Description: The description is, by default, taken from the text on the web page. I have not determined if there’s a way to specify the description in a different way. However, there is a meta description tag which is probably the answer to that question. I will be testing that.

Having succeeded with the Raspberry Pi, I wanted a more efficient version than a small computer running at 5V, 1A so I bought two small battery-powered beacons. More on those later.

The Ever Changing Next Halving Date

Note that I accidently ran this data from between the middle of the two halvings. I believe the interpretation still stands but I will run a complete analysis from the last halving tomorrow and update

For mining blocks in the Bitcoin blockchain, Satoshi designed the algorithm so that the difficulty would be periodically adjusted in order to have a block discovery time of ten minutes. However, with the rising interest in Bitcoin, mining power has kept ahead of the difficulty adjustments.

In order to see how this balancing act has proceded, I took all the blocks from the time of the last halving and calculated the average time to mine the blocks on a daily basis. (Note that I calculated the average over the period since the halving and not just on the day in question.

halving