google / physical-web Goto Github PK
View Code? Open in Web Editor NEWThe Physical Web: walk up and use anything
Home Page: http://physical-web.org
License: Apache License 2.0
The Physical Web: walk up and use anything
Home Page: http://physical-web.org
License: Apache License 2.0
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.
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)
...
Error:Cause: failed to find target android-21 : /Applications/Android Studio.app/sdk
Install missing platform(s) and sync project
https://github.com/google/physical-web/blob/master/documentation/getting_started.md links to http://www.rfduino.com/ but it's not entirely clear which RFduino module(s) you are using.
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
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?
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.
The demo mode beacons could have more relevance to the physical web use cases.
I think we could save one byte for the URI by including the slash after .com etc. in the expansion.
The link in the descriptions doesnt work without adding [www].physical-web.org
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.
What steps will reproduce the problem?
Open app
Start Scanning for beacons
What is the expected result?
One beacon is found the animation stops and disappears.
What happens instead?
The animation stops but it doesn't disappear.
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.
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
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
Tiny fix -- current sketch has a comment at the top of the file using a "#" char instead of "//".
Fix is in this pull request: #138
In a separate commit, I also moved the sketch into a directory of the same name, so that it can be loaded into Arduino IDE without re-saving.
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.
As only short URLs are possible, relying on URL shorteners might be common. It seems the server backend does not yet resolve such URLs, resulting in Unknown name, Unknown description.
Kind regards, Thomas
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?
Help me
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
For example
0001
= http://
0010
= https://
0011
= tel:
0100
= smsto:
0101
= mailto:
0110
= ftp://
0111
= magnet:
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.
Inspection Results from Android Studio Studio (Analyze-> Inspect Code) lists 232 issues.
This has been creeping up recently -- prune the easy ones.
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
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.
How can I connect BLE_Nano with USB to Arduino, even after updating the library, in Tools-> Board is not present BLE_Nano.
I have to add the component hardware, how should I do?
Thanks for your help!
It's been awhile since this unused resource detector has been run for this project. Run it again.
Define how the Thing can notify the user, after the user has discovered and interacted with the Thing and given permission for one-time, or repeated notification. This seems to be a general-enough pattern to figure this out once and apply everywhere.
More details blogged here: http://upon2020.com/blog/2014/10/another-inverse-physicalweb-use-case/ and referenced here per suggestion of @scottjenson in the hope that others can chime in.
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.
Now, as soon as your collaborators start participating, they can easily find the guidelines you'd like them to follow.
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.
The Android notification is present but no UriBeacons are present.
Possible cause: the service has exited and on restart hasn't cleared notifications.
Solution: go through service shutdown/startup condition
Steps:
Expected:
The new url should be set to the beacon.
Actual result:
No url is set.
To repro this bug:
Have only one or two active beacons nearby. Launch app. Scanning indicator is visible. As the NearbyFragments listview populates, the scanning indicator does not disappear.
Hey, the Tessel is capable of making a beacon pretty easily:
https://github.com/tessel/docs/blob/master/tutorials/ble-getting-started.md#beacons
When I get off of work I'll try to make a working example and put it up somewhere on github.
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.
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:
I think this would be really interesting if the OS also extracted schema.org or json-ld information form the webpages.
Some use cases:
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.
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.
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.
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
"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."
Minor updates required to reflect changes from L Developer Preview -> 21.
More details in:http://developer.android.com/sdk/api_diff/preview-21/changes.html
(I will make a pull request for it in a moment)
Pull request here: #154
Currently, a central can connect to the RFduino, which disables beacon advertising. This pull request makes the device non-connectable.
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.
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.
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?
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?
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:
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.
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:.
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.
I am looking
The URL shortener class should not block the main thread. Currently it issues a get() which is blocking. It should probably take an argument of a runnable callback to be invoked by the completion method and use this to call back into the requestor.
See the documentation around AsyncTask and
the URL Shortener API
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.