Eddystone

[SMarkkuA]

Hey,

can someone please open to me what´s wrong? I have a couple of Radius Network´s RadBeacon Dots. I have configured those with Radius´s own config tool. They should support eddystone url´s, but what I don´t understand is that there is some webpages start with https:// they advertise, but they don´t advertise any http:// pages.... Why is that, because github pages tells:

So could someone tell, what I am doing wrong? Config pic below:

[scottjenson]

Google's Physical Web scanner will only show https URLs. This is done for security purposes to make sure no one could be subjected to a man in the middle attack.

The Physical Web scanner is a separate project from Eddystone. Eddystone wanted to be able to put any URL in the beacon.

[ernstolivier]

Greetings, such a nice service a method of getting questions answered, I thank you in advance Scott,

So, I have read that there is a limit to how bytes you can have in an eddystone broadcast url and that you can conserve bytes by using a shortcut shcema...

as in an earlier post above which shows https://www. as equivalent to Decimal 1 ...Hex 0x01...

so in that example does the subdomain have to match www exactly? If that is the case and I want to use a secure url with a distinct subdomain as in this example https://1.mydomain.me/$s2

How many bytes does that count for through the final digit "2" ? Is that 15 bytes?

Or , to use my custom subdomain "1" .....would I have to count bytes via the method Decimal 3 ...Hex 0x03 meaning https:// followed by 1.mydomain.me/$S2

In which case my first example would number 15 total bytes while my second example would consume 17 bytes (effective losing 2 bytes ...."1" and a " . " with the custom subdomain option ?

Am I calculating the byte counting process correctly?

Also, am I correct that a .me extension is not restricted nor would my example url slug of "$S2" be limited within your specification either ????

I hope my question makes sense to you,

Your assistance on this matter is greatly appreciated.

Thanks

[scottjenson]

The compression scheme is VERY simple, just replacing some of the header bytes (https://www) and some of the TLDs (.com, .org) That's really it, everything else takes up space. You basic calculations look correct.

What we've learned though is that using a URL redirector is actually very helpful. Not only does this allow you to use any length URL you wish, it has the amazing property that you can change it after the beacon is deployed. This is huge as you no longer need to visit the beacon physically to change it. In addition, you can turn the beacon 'off' by just redirecting it to null.

I realize that many not apply to you but please consider it as it's saved us in so many ways in our deployements.

[ernstolivier]

Thanks for the quick reply. If you don't mind ...I want to be clear in understanding the reason for there being several variations in header byte formats ,,,and thus I was trying to focus on whether the header byte "https://www." or Decimal 1 is specific to use cases where you are using a www subdomain as your canonical url,

While many sites still do, many newer sites have structured their sites to avoid it. So, when it has been avoided if I wish to use my own non www subdomain as in my example 1.mydomain does that automatically eliminate the decimal 1 use case from consideration? Otherwise, what is the point of the spec listing two essentially equivalent header byte alternatives in such precise detail down to the period asin the Decimal 1 use case ?

e,g, https://www. vs https:// (without www.) in all the working examples?

I would like to be clear on this as every byte is so important? What happens if you exceed the 17 byte limit by even one character?

Will the url notification fail because of that (I imagine when trying to add it into an Eddystone beacon it won't be possible) ?

Also, I noted your point about short urls but I figured out a way to redirect my own url at the DNS level so I would prefer to mange that aspect using my own methods, although the "custom subdomain" part of my question is what I need to be clear about since I could potentially redirect that as well on my own........once I understand any inherent limitations of setting things up that way. I recently read that using cookies can get messy when you are using a custom subdomain as a canonical subdomain, etc. (but I don't plan to anyway)

Please advise.....

Thanks in advance

[ukBaz]

@ernstolivier, Have you looked at: https://github.com/google/eddystone/tree/master/eddystone-url#url-scheme-prefix I think that makes it quite clear; https://www. is 0x01 and https:// is 0x03

The number of bytes is a limit that can't be exceeded and comes from the bluetooth standard. Here is a nice summary of the different formats and how each byte fits into the Bluetooth 4.0 standard

which it comes from this original tweet: https://twitter.com/josryke/status/763006284052463617