Git Product home page Git Product logo

physical-web's Introduction

The Physical Web

The Physical Web is an effort to extend the superpower of the web - the URL - to everyday physical objects. Our premise is that you should be able to walk up to any “smart” physical object (e.g. a vending machine, a poster, a toy, a bus stop, a rental car) and interact with it without first downloading an app. The user experience of smart objects should be much like links in a web browser, just tap and use.

At its base, the Physical Web is a discovery service: a smart object broadcasts relevant URLs that any nearby device can receive. This simple capability can unlock exciting new ways to interact with the Web.

Introduction to the Physical Web

Build Status

Why URLs?

The URL is the fundamental building block of the web, giving remarkable flexibility of expression. It can be:

  • a web page with just a tiny paragraph of info
  • a fully interactive web page
  • a deep link into a native application

Why We're Doing This

The number of smart objects is going to explode, both in our homes and in public spaces. Much like the web, there is going to be a long tail of interactivity for smart objects. But the overhead of installing an app for each one just doesn’t scale. We need a system that lets you walk up and use a device with just a tap. The Physical Web isn’t about replacing native apps; it’s about allowing interaction for the times when native apps just aren’t practical.

Open Design

The Physical Web must be an open standard that everyone can use. This can’t be a product that is locked down by a single company. Like many web specifications, this is an open source design that is being released early so everyone can experiment and comment on it. There is much to discuss and add to this specification.

Contents

physical-web's People

Contributors

asagrawal avatar beaufortfrancois avatar cco3 avatar colemurray avatar dermike avatar devunwired avatar dinhvh avatar don avatar edent avatar g-ortuno avatar gbuesing avatar grahamoregan avatar hayesjordan avatar iankchristie avatar jakeleichtling avatar jpmedley avatar kevinahuber avatar louaybassbouss avatar matthewsibigtroth avatar meriac avatar mmocny avatar nishadg246 avatar nondebug avatar peeja avatar s10wen avatar sandeepmistry avatar schilit avatar scottjenson avatar thunderkeg avatar wiiikiii avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

physical-web's Issues

18 characters for URLs is far too short.

Problem

The hard-coded list of TLDs cannot be relied upon (.co.uk? not even .net made the list). So we can say that you have 17 characters after the http(s)://. Here are some URLs that would not fit.

Also, why did you not include the trailing / in the TLD replacements? That would save an extra character.

Solution

A simple solution is simply to send several advertisment packets, each containing a part of the URL. A simple scheme could be that the first 4 bits indicate the number of fragments, and the second 4 bits indicate the current fragment number. This would allow very long URLs at a slight battery cost.

Consecutive packets would not be sent immediately after each other, as Android has issues with this (woo quality BLE code right guys?; ok to be fair the BLE spec is stupid about that.). Instead they would be sent evenly spaced through the advertisment period. E.g. if you currently send a <17 byte URL once per second, you'd split a longer URL into 2 and send alternate packets every 0.5 seconds.

Create a beacon app

My excitement about this project is peaking right now, but there's no way for me to play with it.

I wish there was an application that I could download to my Bluetooth enabled devices that would convert them into beacons so I could play with the interaction model around my house.

I am a web developer so I'm not sure if this is even possible, but I can promise you I be playing with the physical web right now if I had beacon applications on my laptop, Xbox, Roku, Android phones, iPhone, iPads, etc...

Just a thought :)

Jonathan Stark

Use 7 Bit GSM Alphabet

Problem - there are 144 bits available for a URL. This means 18 characters of 1 byte each. This restricts usage to those who have a short URL, or places users at the mercy of URL shortners which may not be long lived.

Solution - GSM 03.38 is a 7 bit alphabet which is used for SMS. It is a subset of US-ASCII and contains all the characters typically used in a URL.

With this, the 144 bits could be divided into

  • 20 URL characters (20x7=140).
  • 4 bits for protocol.

For example

  • 0001 = http://
  • 0010 = https://
  • 0011 = tel:
  • 0100 = smsto:
  • 0101 = mailto:
  • 0110 = ftp://
  • 0111 = magnet:
  • etc etc

At a minimum, the 7 bit alphabet (which every SMS sending device can understand) gives 2 more character - an 11% gain! When properly combined with the protocol bits, the savings become more dramatic.

https://en.wikipedia.org/wiki/GSM_03.38

Create CONTRIBUTING.md guidelines to let people know they have to sign the CLA

Since you require signing a CLA for contributions, you should probably have a CONTRIBUTING.md

Blog post about Contributing Guidelines:

Today we added support for sharing your preferred policy for contributions with the folks wanting to collaborate with you on your project.

We've tried making this easy for everyone. As a maintainer, all you have to do is add a CONTRIBUTING file (or CONTRIBUTING.md if you're using Markdown) to the root of your repository. Then we will add a link to your file when a contributor creates an Issue or opens a Pull Request.

image

Now, as soon as your collaborators start participating, they can easily find the guidelines you'd like them to follow.

Location fingerprinting

Not saying this is a good thing or bad thing, but it occurs to me that if the beacons became fairly widespread, it would be easy for any application that had access to Bluetooth to fingerprint a geolocation.

For example, let's say the Chrome browser on Android had access to Bluetooth. It could then detect the unique combination of URLs being broadcast near me and use that as a fingerprint to tell who else was near that same "beacon fingerprint".

Yes, this could probably also be done with GPS location data but that's a different permission and it's unlikely that someone who was allowing Bluetooth access to an application would consider that would also pinpoint their geolocation.

In other words, if we wanted to control access to our location, we would also have to turn off Bluetooth.

Now that I'm thinking of it, it occurs to me that simple Google search results could be modified based on the beacons that were near me. So if I search for "car wash" and I happen to be physically near a car wash that's broadcasting, it might become the first search ranking results in the organic Google search results because of the physical proximity.

Again I'm not saying this is good or bad but it's an interesting consideration.

"116 Beacons Nearby" (Not!)

Problem: there are 4 distinct URIs but lots of duplicates.

Cause: the Android notification code does not inspect URIs

Solution: keep a HashMap<String, Integer> or MultiSet to keep track of URIs

Notification: "1 Beacon Nearby" or "1 URL nearby"

Matt: "URLs nearby." What do you think?

Scott: Neither URL or URI are very consumer friendly terms. I'm frankly not
thrilled with 'beacon' either to be honest. If we move to a more agressive
notification approach, e.g. showing the 2 closest beacons then 'the rest'
things get easier as we are just listing the actual title/info and don't
have to worry what to call them.

Selecting "1 Beacons Nearby" notification goes to About screen

Problem: if you exit the app while the About screen is active then use the Notification to return to the app it goes to the main screen.

Expected behavior: selecting a notification should always go to the Nearby beacons display

Solution: The main activity should detect the intent from the pending notification and bring up the proper fragment

Privacy from a User Tracking Perspective?

The intro doc touches slightly on privacy from the perspective of random local observers seeing beacons, but I don't see any mention of privacy from the perspective of the intended user being tracked by the servers hosting the beacon endpoints.

I wrote up little doc that I called "OpenBeacon" (http://obcn.io) so I've been thinking about url-based beacons for awhile. The best thing that I've come up with so far is actually something that I've stolen from Moxie Marlinespike's Perspectives project where any beacon server must act as a proxy to other beacon servers so that one server will know who you are (ip address) and one will know where you are (the beacon that you see). There is obviously potential for abuse if you were to just have an open proxy that will pass any tls connection, but I'm sure there is something that can be done to prevent that, I just haven't given enough thought to what trade offs are acceptable.

Suggestion to advertize an IPv6 address payload instead of domain names

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?

Missing Continuous Integration and Testing

"For example check out the Angular.js project on GitHub. The small green box in the readme which says “build|passing” is powered by TravisCI, one of several minimally invasive (and free) continuous integration services for open source projects."

No beacon found in app when using nodejs code

The precompiled app doesn't find any beacon when using the node examples.

I'm running them from a virtual debian machine on a Mac. The beacon is picked up by BLE scanning apps on both iOS and Android, but not by the Physical Web one.

Proactive Notifications, Native Apps and Meta Data

First of all I want to say that I am very excited about the physical web project and the fact that there is an idea which is open source and publicly discussed.
As I read the documents I got a bit confused about the goals regarding notifications and the integration with apps. In the "introduction" document you say why this is currently an app and that it should be part of the operating system and its settings later but also that there should not be proactive notifications to not pester people. People should be able to see notifications only when they ask for it.
But how is this going to happen? Either they opt-in in the OS settings , then they get all notifications and if they don't, no notifications be be shown.
I would like the idea of protocol dependent handling. For standard protocols like HTTP the settings of the operating systems should decide if a notification will be shown. The meta data for the notification content will be loaded via a JSON request as I understood.
But to keep the system open for app developers, it could be possible to register an "protocol handler" for an app. If the broadcasted URLs protocol part is not a standard protocol then the handler is called and the app can decide what should happen and provide meta data if the notification should be triggered or return null/false if not. This way it would be still very easy to deploy a beacon that links to a web page but it opens possibilities for providers of solutions which have their own settings/logic implemented.
For example: A city guide app could register a URL handler for "cg:// ". If a beacon is detected with an URL starting with "cg://" then the handler of the city guide app evaluates the URL and could trigger a notification or not, depending on the settings the user of the app chose in the apps GUI. The click on the notification should then deep link into the app. Still the user could opt-in or out for all the general beacons in the city via the OS settings.

Enhance URL Compression

As noted in the documentation, a major limitation of the advertisement packet is the relatively short length available for URLs. This is partially mitigated by having strings such as 'http://www.' represented by a single byte. Since it is expected that URL shortening services are going to be used, would it make sense to also represent some of those as a single byte, e.g. 'https://goo.gl/'? Pushing the idea further, instead of the single byte compression there could be a prefix field, where prefixes (domains) could be registered similarly to Bluetooth assigned numbers. For example, I could request that there be an assigned n-byte prefix that translates to 'https://www.mydomain.com/my-companys-really-long-beacon-url/'. That assigned number is then part of the specification. (Since this is open source, the 'request' would really just mean submitting a patch.)

What other options are available for supporting longer URLs, before taking the greater measure of creating a custom GATT service?

Mandate https:// for URLs

In order to save precious bytes, it would make sense to specify the protocol. If the client is assuming that every beacon is advertising a URL, there's no need to include the https:// in the broadcast.

As part of "HTTPS Everywhere" it would make sense to encourage adoption of https:// within this space.

It also, hopefully, will discourage people from putting up fake beacons, or those which point to malware.

https://www.youtube.com/watch?v=cBhZ6S0PFCY

Extract URLs from WiFi SSIDs

Quick question: have you had any discussion about showing URLs from WiFi SSIDs?

I saw a presentation from @scottjenson a while back about this project and really liked the idea and even hacked some tests myself.

I think interactions with Bluetooth beacons can be very meaningful due to the small radius, but I can also see how fetching data based on URLs from WiFi SSIDs might be interesting too.

My rationale:

  • My devices already scan regularly
  • Setup would not require new beacons, just configuring existing access points, which means a way lower barrier of entry
  • Many places have WiFi nowadays: businesses, events, museums. Some of them might be private, but that would not be an issue
  • Bigger radius than bluetooth, which will enable different use cases

I think this would be really interesting if the OS also extracted schema.org or json-ld information form the webpages.

Some use cases:

Quick access to a conference schedule

Alice is attending a conference. The organisers have setup the conference WiFi with a URL in the SSID. The URL points to the webpage containing the conference schedule and the schedule using schema.org in the markup.

When Alice opens Google Now, her Android phone had picked up the information and it shows me the current and next sessions in the schedule.

In-store order from your phone

Alice goes to the cinema and there's a big queue to buy tickets. The cinema doesn't have a public WiFi, but they have a private WiFi network that has been setup with a URL in the SSID. The URL points to the webpage from that cinema venue where she can buy tickets.

When Alice opens her mobile browser it shows a link to buy tickets for that cinema.

protocol and domain substitution in URIs

Here's some feedback after reverse engineering the UriBeacon protocol and domain substitution

I think you might want to leave more space between 0x06 geo: and 0x07 .com

For example to add more protocols, like sms: it would be convenient to have it in order in the array, so the substitution value is the array index. (This is what NFC URI prefixes do.)

Order is also important so the "best" match is picked. e.g. http://www 0x0 over http:// 0x2.

It might be too late, but I'd consider moving .com to 0xF0 or something to give you more room for adding protocols after 0x6 geo:.

Up button doesn't always dissapear

Repro steps:
Enter About menu. Click the hardware back button. Up button (leftward pointing arrow in the left of the action bar) doesn't disappear.

Firmware compatibility with BLE112

I see a BG Script for BLE113 under firmware. Has anyone tried it with BLE112? Is BLE112 compatible by any chance?

If not, any specific reasons?

Out of box experience for Android App

The initial experience is not good for a user -- especially if they don't have beacons nearby

Should show a few descriptive pages including a link on how to get/create a Uri Beacon

The Complete Service UUIDs is not necesary

As described in "Getting started testing..." the advertisement packet currently begins with:
0x03, // length
0x03, // Param: Service List
0xD8, 0xFE, // URI Beacon ID
Those 4 bytes are not necessary. The data type 0x03 (Complete List of 16-bit Service Class UUIDs) defines a list of services that are available after establishing connection, which is not this case.

Some other use cases, f.e. temperature sensors, are already using only the data type 0x16 (Service Data) to advertise with temperature (service UUID:0x1809) and f.e. battery status (uuid: 0x180F).

In such case the packet would look like:

uint8_t advdata[] =
{
/* 4 bytes removed */
0x0A, // length
0x16, // Service Data
0xD8, 0xFE, // URI Beacon ID
0x00, // flags
0x20, // power
0x00, // http://www.
0x41, // 'A'
0x42, // 'B'
0x43, // 'C'
0x07, // .".com"
};

and there are extra 4 bytes for the URL (or 3 for flags: NoBrdSupported, and one for URL).
Such packet is clear as the URI Beacon ID is present.

Make resources resourceful : Network Discovery API

At present, physical web relies on a dedicated app which can sense the presence of webservers around it.

W3 DAP group already has a very successful & amazing spec that any web page might be able to use ; the Network Discovery API. Via network-disco, one page can find out about other pages in the local network. The web API is generic, and already functionally very similar to physical web's.

Rather than define a native api on Android for consuming one particular communication-means (BLE), I'd offer that there's an obvious champion already in the realm:

  • providing an API that would befit both web
  • and which could be ported to native use,
  • which has a number of existing transports
  • which would undoubtedly welcome BLE as a discovery mechanism.

At present, I suggest familiarization with the Cordova Network Discovery plugin. The underlying code here could be re-used sans the WebView wrappings to provide a start for Network Discovery native developers on both iOS and Android, and Web app developers benefit from being able to make apps that can browse locally available services... today.

Add a firmware directory

It would be great if the repository included firmware examples for various BLE modules and SoCs, such as RFduino, BLE113, nRF51822, etc. You've already written the RFduino example in the docs. This would facilitate openness in hardware in addition to the mobile and web components.

I can contribute these as either a directory in the main repository or create a separate repository for firmware. Which would be preferred?

Delay in showing snippet

The snippet is shown after meta data is loaded AND a new sighting is seen.

This will delay the appearance by about 500 ms.

The snippet should be shown as soon as the meta data is loaded.

Nearby Beacons shows URLs too early

Problem: Nearby beacons display shows URLs but those URLs might be invalid or filtered later on.

Expected behavior: snippets for Uri Beacons should only be shown when meta-data is in hand, either from a server or a cache

Gradle project failed to sync

Am trying to build the app through Android Studio; when I run I get the error:

Failed to sync Gradle project 'foo'
Cause: failed to find target android-21

Does the app use an API that’s not been released yet? I only have API 20 for the L Preview.

"Demo" doesn't work on Lollipop

Process: org.physical_web.physicalweb, PID: 6537
java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String org.uribeacon.beacon.UriBeacon.getUriString()' on a null object reference
at org.physical_web.physicalweb.NearbyBeaconsFragment.getUrlFromDeviceSighting(NearbyBeaconsFragment.java:334)
at org.physical_web.physicalweb.NearbyBeaconsFragment.access$600(NearbyBeaconsFragment.java:65)
at org.physical_web.physicalweb.NearbyBeaconsFragment$NearbyBeaconsAdapter.getView(NearbyBeaconsFragment.java:352)
...

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.