search

google / physical-web

The Physical Web: walk up and use anything
http://physical-web.org
Apache License 2.0
5.99k stars 665 forks source link

Suggestion to advertize an IPv6 address payload instead of domain names #27

Closed brandonwittwer closed 10 years ago

brandonwittwer commented 10 years ago

I'm just now joining the discussion, and I hope to offer something valuable to it. It appears that a lot of thought is going into the concern about the volume of data needed to be advertised in order to assemble a decently small domain name to the client device.

BUT: If the url isn't human readable, then why are we worried about DNS at all?

IPv6 addresses will entirely fit within the 16 byte payload and may be compressible even further. Already I've heard conversation suggesting that the response would not be the final webpage but rather a JSON-LD response with metadata. We'd need to suggest IPv6 since only one advertising response could be served from that address and IPv4 space is already congested. Having a dedicated public IP address that serves only one tiny piece of JSON information is a little inefficient, but without host headers to route that request around on the endpoint webserver it's the only way to make this idea work. There are more than enough IPv6 addresses to go around however...

I haven't tested it in the code yet and I don't own an IPv6 address to test with, but the concept seems sound to me. I think this will help get around many of the url concerns. Thoughts?

scottjenson commented 10 years ago

Interesting idea. One simple approach would be simply stack each 4bit digit, 2 to a byte, so a normally 28 byte address could be compressed into 14. The expansion code at the beginning would identify it as a compressed IPv6 address so we could interpret the entire package as binary.

I'd be interested in others comments.

The main reason URLs in their full form are so valuable is that they are so flexible, allowing everything from rotating IDs to parameters that reflect internal state (e.g. a temp sensor could be xyz.com/&t=28C) so I doubt the need for them would go away.

brandonwittwer commented 10 years ago

Thanks for the reply @scottjenson

If compression works, then you'd still have 2 bytes available to encode any simple identifier or statistic about the beacon host. you wouldn't need to encode any of the ceremonial visual characters: /&t= C. The client could hit the address by standardizing the parameter name in the spec so you'd have the entire two bytes to represent the significant data.

schilit commented 10 years ago

Interesting idea but... IPv6 addresses are 16 bytes (128 bits) long.

The average length of a domain name is only 10 characters so there seems little gain.

The most common length of shortened Urls is 20 characters or 14 with compression codes (e.g., replacing http:// with a single byte). Even with a Url path it is below the IPv6 address length.

Directly using IPv6 addresses is not going to save space and the use of hard-coded IP addresses has a number of other issues.

brandonwittwer commented 10 years ago

Good points. The trade off is simplicity of the spec, but it also limits it a bit. Requiring a URL shortener service is the negative on the other side of the discussion, since it latches the standard to a 3rd party dependency. (Aside from short vanity urls).

Anyways I thought I'd put it out there so its an option.=

rektide commented 7 years ago

I think this would be really valuable to have.

Related eddystone issue: https://github.com/google/eddystone/issues/28

scottjenson commented 7 years ago

This same issues still remain:

  1. every ipv6 address would need to point to a working webpage (for meta data)
  2. every ipv6 address would have to point to a public server (so the PWS can see it)

There are ways around both of these issues. Just saying that, for now, it would have to act like a URL. We clearly understand the value of local access of devices, but it does raise important security issues that we're still grappling with.