Make resources resourceful : Network Discovery API

[rektide]

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.

[scottjenson]

I think this is an excellent topic to discuss. My concern with te Network Discovery API is that you have to load a web page in order to use it. The primary motivation of the physical web was around stream lining the UX. The goal is to pull out your phone (or moral equivalent) and get to the beacon page as simply as possible. Unless I misunderstand this API, asking the user to load that page first is going to be a bit cumbersome.

[elroyjetson]

If it is implemented through the Cordova plugin, it would operate the same as a native app. It would just be implemented in a more web/portable way than an Android specific way. The plugin works on both Android and iOS.

[scottjenson]

But again, an app is (effectively) just a cached web page, it's the same issue. Point #0 of my FAQ on the github introduction page is that we are using an app right now because it is the ONLY way to prototype this at the moment. The proper way for this to work is to have it integrated into the OS so it is as seamless and easy as possible (to get the eventual web page)

[jonathanstark]

Although they bear a passing resemblance, the physical web (PW) proposal seems to be fundamentally different than the Network Service Discovery (NSD) spec.

Following are a few of the big differences that I noticed. Please correct me if I'm misunderstanding anything:

1. NSD is for finding services on the user's local network. PW (importantly) has no such restriction.
2. NSD advertises potentially complex interactive services that are available for use on the user's LAN. PW broadcasts simple URLs to potentially complex resources on the public internet. i.e. the complex stuff is in the cloud, not embedded in a TV or something
3. NSD devices by definition need to be connected to a network over HTTP. PW objects don't need to be connected to a network. Most probably won't be.
4. NSD devices need to be powered on so they can perform the advertised services. PW objects don't need to be powered. In fact, they don't even need to be electronic.

In summary, NSD sounds like Android internet for your home network, and PW is like "over the air" QR codes.

Again, please correct me if I'm wrong. I only just read through the NSD spec.

[sirvon]

If PWs weren't connected to some kind of network they would be pretty "dumb" smart IoT devices, and that would be missing the point on the opportunity at hand.

I don't think this tech should be thought of as a way only to lead ppl back to the web, just by throwing them urls to mobile-ly catch and visit, but the point that things around you are alive, is to "take the internet off the internet". And live and learn in the moment more.

If PWs weren't allowed or used in a way that made them 2 way interactive, remotely configurable and controlled by whoever owned them, I would chunk the technology in the devolution category.

The whole point of interfacing with physical objects using the most widely accessible, easy to use, intimate interface known to man... a mobile device. Is to stay "connected" to that moment when that inanimate object just started flirting with you, and telling you about your surroundings more, because its way more aware than you are.

Remotely pushing to these Physical Web objects and having them push to Physical human's phones, so that those ppl can push back either directly or by way of the cloud, I would just think is realizing the full richness of this opportunity.

[ghost]

There are several classes of devices that might want to use PW:

1. Devices that only want to advertise their proximity (like iBeacon AirLocate) and a link to contextual information on the web
2. Devices that additionally want to advertise some other data they have, such as sensor data, which can be done as part of the URL (I'm particularly interested in this case, BTW)
3. Devices that additionally want to receive data, such as commands. This is the two-way interactive device mentioned.

As it stands, PW supports 1 and 2 by directing the user to a URL that provides contextual information, but only supports 3 if there is a back channel available (such as the internet or a BLE GATT service). In the case of 3, if the URL points to the device itself (either directly or indirectly), the URL could provide much of the same data that network service discovery provides. What's important is that the specification of JSON data returned from the URL that is parsed by the mobile device can accommodate arbitrary instructions for communicating with the device through that back channel.

You could also accomplish 3 by using PW only to notify the user of the presence of a particular type of device, and then providing a plain old BLE GATT service. The URL can say, "Hey, if you install such-and-such app, you can control this device." The advantage of using PW here is that it doesn't require the user to have an app installed or running just to know of the presence of a device, even though they might still need an app to fully interact with it.

[jonathanstark]

I'm not saying that PWs couldn't or wouldn't be connected to a network; I'm saying that it's not a requirement. This potentially extends the concept beyond fancy new devices to "legacy" objects that perhaps aren't even electronic. A PW could certainly broadcast an address to a service that resides on it (which I believe is very similar to the NSD spec) but that is just one use case.

[jonathanstark]

Looks like @jcrabtr and I are on the same page :)

[sirvon]

thank you for highlighting "offline" but still very much "in-life" use cases. Yes, allowing the spec/tech to mesh well with "legacy" tech would open possibilities for discovery much more. In experimentation, I am definitely going to play with offline type PWs, cases 1 and 2, that basically just piggyback off the humans existing connectivity.

[scottjenson]

There is so much to explore here. We feel there actually is a lot of value for 'just take to me a web page' scenarios. However, there is also value to talking to things nearby. The PW is just a gateway to interactivity. I've built a vending machine using a RPI and a web server so when I walk up to it I get a web page that when I push it, it drops a candy bar. It's fun and crazy quick (the instant I push the on screen button, the candy drops)

However, this does go through the full internet and I can see how that's too much of a round trip for most. My point is that there are so many valuable use cases here: 1) Just going to the web (bus stops) 2) Going through the cloud (vending machine) 3) And yes, going directly to the object directly

There are lots of ways to offer #3, I just don't want us to loose the value of 1 and 2

[sirvon]

I actually believe alot of what we think is the right things to do in this space is totally wrong, bc we've never had the power to acceptably have conversations with our environment, and give up power to the things around us. Like if that door is smarter than me because its connected to 50 million sources and doesn't have to think about human stuff that I do like taking care of my kids, let it be SMART. no! don't just send me a link. The thinkers and doers need to unleash the full power and potential of the technology, and not be caught in any old/legacy way of thinking. this is a completely different experience than anything before us. Honestly, every object around us has the ability to communicate with us now, intelligently.

[scottjenson]

OK, what are you proposing we change to our spec?

[jonathanstark]

@sirvon Wha?

[lowesoftware]

To add to the conversation, I think the #3 "going direct to the object" is the most interesting opportunity here to expand the spec and demo technology around. Otherwise we're really working on replicating what a QR code is -- or even a sign with a printed URL. Yes, it's a better experience not to have to scan or type, but I think that's not the real opportunity.

Smart objects I would argue are already connected objects (or there's a 95% overlap), and they will already have access to cloud services and cloud data to be even smarter. I come from the smart vending/self service industry and there is a big push to move more logic to the devices themselves -- because connectivity still isn't great via wireless. Latency sucks on a web browser -- but latency really sucks on a physical object... I'd be really annoyed to press a button start my car and then if it took between 100ms and 5000ms for the car to actually start depending on the time of day or where I'm at... or it 404s and never starts because I'm in San Francisco :(

I think the ability for a smart device, or a local network of smart devices to collaborate two ways directly with my personal device (phone, watch, glass, implant) is what will unlock really great user experiences yet imagined. So it's not only how can I control my environment, but with a two-way handshake (which could be optional), my environment can respond to me at my command -- or with an identity layer -- passively with my permission. It may not be the first step, but I think it's where I'd like to see the spec evolve to.

[sirvon]

sorry I finally gave my body a rest. The reason this particular issue sparked my attention was due to these statement...

"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."

and again,

"But again, an app is (effectively) just a cached web page, it's the same issue." "The proper way for this to work is to have it integrated into the OS so it is as seamless and easy as possible (to get the eventual web page)"

The down playing of the raw effectiveness and power of APPs and upselling of The Web as the end all be all.

Why couldn't this spec be more in line with the rest of the movement in mobile/"off the web" development and have an api or integrative piece that devs could add into their designs, effectively giving every app the ability to sense and authenticate against, beacons/PWs.

Why not piggyback on the decentralized/uncontrolled pathways and avenues that mobile apps are creating by way of deep links within a singular device and without the need to ever directly hit webpage.

Yes, everything essentially goes back to some "web server" but these external PWs should help me utilize the resources that already exist on the powerful webserver in my pocket and all its modules/apps.

I potentially see coming with the assistance of PWs and more in app predictive techniques, a climate where you won't ever have to go out to the web using a browser or a generic http link but just canvas and grasp everything you can desire from the apps on your phone and the leading assistance, objects around you offer and share.

My addition to the spec, in thought and as a voice, would be MORE reliance on Native Apps and less reliance on the WEB as we know it.

I guess my passions is more in line with how to shape the final end use/real world use of PWs for the greater public.

[jonathanstark]

Regarding the "non-cloud, direct interaction" model: Bluetooth already supports this. If that's the only interaction model that interests you then Bluetooth is probably all you need.

What excites me about PW is that, unlike the monolithic Bluetooth spec, it is simple. If PW delivers on its promise, any garden variety Web developer will be able to easily add some basic "smarts" to virtually any object. Yes, in many cases this will amount to a QR Code on steroids. And yes, it's a stretch to describe an object extended in this way as "smart". But that's just one interaction model that PW supports.

The magic of the Physical Web initiative is that it extends the inclusiveness of the web to physical objects.

As TBL said, "This is for everyone."

[scottjenson]

I couldn't agree more, you're sliding into my 'triumph of the mundane' post. My personal feeling is that which this is 'just a better QR code' it is better in way that makes a huge difference. Having the potential to find anything within 30meters in a unified way really is a new platform and as you point out, encourages whole new use cases. While it does seem trivial that pets will wear these, that's the point: nearly anything can offer up trivial information very cheaply. The "internet toaster" might not be about tweeting when it's done but rather letting you see a youtube video on how to clean the crumb tray.

Of course, once we have this in place lots of other possibilities open up.

I'm worried though that we're abusing the 'issues' feature of GitHub. If you don't mind, I'd like to close this thread and start collecting issues more related to the code. Of course, I'm happy to engage on social media, etc to discuss this further.

[jonathanstark]

Agreed that issues should be for issues. Should have a proper discussion forum with threading somewhere. Google plus?

[rkfalcon]

@jonathanstark You mentioned in an earlier post comparing NSD to PW that "PW objects don't need to be powered. In fact, they don't even need to be electronic.". Can you expand on that a bit. How could you discover PW objects if they are not powered and/or electronic?

[scottjenson]

Closing as we're not really an issue now. I'm happy to pick up on G+