Local Peer-to-Peer API #103
Comments
|
Here's a description of a few my use-cases that would massively benefit from this proposal: WebBluetoothCG/web-bluetooth#231 (comment) Another use case: being able to more easily (even automatically with no intervention!) synchronize identities (private keys, etc) across my "local circle" of personal devices would be huge. It'd be nice if there could be any sort of API alignment (compat) with the Web Transport proposal... as I suspect most people will be building apps where they first try local communications, and then fall back to internet-based P2P. Also: I work for Socket Supply Co, where we build a hybrid web-native runtime to give web apps (in a native app wrapped webview) access to native device capabilities, and full bluetooth/nfc are an important part of that, for the exact reasons/use-cases above. We would love to have native web APIs for this instead of having to monkey patch them in. |
|
Also, and I think this is probably the most important point I can make on this proposal/topic: I've been so troubled/frustrated for years that web standards bodies keep considering amazing API proposals and eventually either kill or hobble them because someone points out all the ways a WEBSITE could abuse such APIs. I'm so frustrated because these arguments always miss the main point. Please, please, please... don't even think of trying to propose any part of this API for regular WEBSITES to have access to. This API should be fully enabled once the web app (PWA) is installed to a user's device. Installation is how non-tech users express their consent -- NO, not perms dialog prompts -- for allowing some app to have full access to whatever they want done on their device. I fear this proposal will suffer the same fate as all the other great native-in-web proposals that have come before it, if it's not clear from the beginning that there's absolutely no way this API would be exposed or exploitable by drive-by WEBSITE experiences. It should only be available in installed PWAs. |
|
I like this proposal. I have some thoughts on a point in the Security and Privacy section:
I think for some use cases users might want to be able to have connections persist for longer than ten minutes, even if the connection is inactive. This overall has to do with whether setting up connections between a bunch of devices in a group - and keeping those connections up - is a hassle, which I could see being an issue if a lot of people are using this at once (like at a conference or a big meeting, or if the same people connect their devices a lot). That said, this proposal looks good, and well thought out. I appreciated the Security and Privacy section overall, and I currently do things in the use cases section, but I have to do stuff like getting devices on the same wifi first. This API is a good step forward for a lot of use cases. Getify mentioned secrets already, but I think it's worth highlighting that being able sync passkeys securely is already important. This would make handling that easier and more secure, as well as opening up a lot of other opportunities. |
|
@getify @Drake42 I'm heartened to hear this proposal resonates with you. The team working on this proposal deeply appreciates your feedback and is excited about the innovative use cases you have for this API. We also hear your concerns. We take them as learnings. It is good you explicitly state them out. Thank you. Everyone watching: please keep your use cases, user stories, feedback, and suggestions coming. No idea is too small to share here. We'll make sure to reflect all the feedback in the updated explainer with credits to you. |
|
I got a couple of user stories/use cases.
I'm looking into using a RFID-card back and forth between phones just to test the idea. The otp-encryption-decryption-lib is already created. |
|
I like the proposal to allow the mobile PWA can set up the local network channel with PC PWA to transfer files, message and sync application status. It will fill the gap for the multiple screen scenarios absent in Web apps on different devices between phone and PC. |
|
We definitely have a use case for this. Our app, ActivityInfo is database platform for humanitarian response that uses IndexedDB and Service workers to synchronize data to our PWA on mobile devices and allow field workers to collect, review, and edit data offline, and then synchronize with the central server when an internet connection becomes available. This works well for scenarios where a field or healthcare worker is based in an office with internet, and takes day trips to areas without connectivity. However, in some cases, teams will travel together for several days (or weeks) to work in remote areas with no connectivity. Since they are reliant on an internet connection to a central server for synchronization, the field workers cannot share data within the team. For example: one field worker might conduct an intake assessment of an affected family, while another team member might provide psychological counseling. Normally, with a central server, these two records would be linked together, but since the devices can't access the central server, they are synced a week later as separate entities, with possibly contradictory information, that have to be reconciled later. With a local peer-to-peer API, the initial health worker could share the intake assessment draft, which would allow the psychologist to reference the intake assessmen via its CUID so that they are linked together when ultimately synchronized when the team returns to the field office with internet. |
|
Thanks everyone for your concrete and helpful feedback! The explainer has been updated with your suggestions and you've been acknowledged. Feel free to take another look with fresh eyes. What's next? We are hearing this API would solve important real-world problems you're facing, so in the next step we plan to propose to migrate this API proposal to an official WICG repository, start draft a spec proposal and in parallel continue work on an early implementation to prototype the API. We will share updates in this issue when we are ready to invite you to watch the new repo and test the prototype implementation. We're working toward that, but need a bit time. Meanwhile, feel free to use this issue for any further feedback, suggestions, or ideas. Thanks! 🚀 |
|
Can you share a bit more about why this proposed approach specifically limits the transport layer to wifi (local LAN) rather than also supporting data exhange over bluetooth/nfc? The discovery phase mentions potential implementation-determined fallback to BT/NFC, so I wonder why the transport couldn't also allow this? |
|
Yeah I don't think the spec needs to require BT/NFC for either the discovery or transport... but if it can use wording that allows implementations to use them, I think that's a perfect place to start. I liked the passive-allowance kind of wording in the discovery phase, so I guess I'd only suggest that similar wording be included in the transport section. Again, making it clear it's optional/fallback and not some required thing. I would imagine browser implementations would be happy with that balance. And BTW, for posterity sake, the reason having a potential for BT/NFC fallback support (for either/both phases) in this API, as opposed to just using the WebBluetooth/WebNFC APIs, is that those APIs only currently expose the server-client profiles (type of connection/communication model), not a true P2P type of model. |
|
Thanks @getify, added the description for BT/NFL as the alternative transports in ibelem/local-peer-to-peer@6518e78. As @anssiko mentioned that we are still in early stage, besides the spec, the feasibility of specific implementation details for browsers will depend on the technical approaches taken and challenges faced. We will examine and determine the final implementation path in follow-up investigations, together with feedback from communities. |
|
I think for my use case (sharing one-time-pad keys for encryption/decryption) I need NFC since that has an inbuilt privacy because of really short signal distance. |
|
Just want to underscore the comments above about the importance of NFC/Bluetooth. For our use cases, requiring field workers to set up a wifi network in the field would severely undermine the usefulness of this standard. Generally speaking, if there's a wifi network, there's a good chance that it will be connected to the internet (even if poorly), and so we can still rely on periodic synchronization with a central server. NFC/Bluetooth would enable true peer-to-peer synchronization in resource-poor, isolated environments. Having to carry and deploy a portable wifi network (and its power supply) is not a simple thing for medical staff or humanitarian workers. |
|
@eklem @akbertram, thanks for your feedback! When using e.g. Wi-Fi Direct as the underlying implementation, devices can make a one-to-one connection without an access point or internet connection. No Wi-Fi infrastructure is required. I noticed the explainer was not clear on this, so expect an update to that part. Thank you for raising this requirement. The infrastructure-less operation is a key requirement for this API. @eklem noted the importance of privacy. As for any Web API, privacy considerations are important to us no matter what the underlying implementation is. What is unique to NFC is its hardware imposed requirement for the two devices to be at close proximity (a few centimeters) to operate making it well-suited technology option for discovery where applicable. We expect end users to care that they can accomplish their task without friction, not so much about what specific technology is user under the hood to accomplish their task. We believe the "cloudless" local communication is a concept that end users do understand, however. |
|
@anssiko That's great! I wasn't familiar with Wi-Fi Direct and didn't make the connection. Indeed as long as no infrastructure is required and it's easy to use for end-users, sounds like it will work well for our use cases. |
|
Slight side question regarding wifi-direct... does this require both devices to have this special capability, or is one of the devices just acting like a normal wifi-capable device and the other is the one with the special act-as-a-access-point capability? The reason I ask is, there's lots of IoT devices (and otherwise just legacy devices) out there that are wifi capable, but I'm not sure that they have this wifi-direct special functionality. It'd be immensely more preferable if those legacy or IoT devices are able to still participate in this P2P connection with, say my phone, if my phone has the wifi-direct capability and is able to act at the AP. |
|
On the topic of wifi-direct, apple has publicly refused to support wifi-direct, in favor of their own apple-only standard (AWDL) which (presently) cannot interoperate with wifi-direct. So if this API specifies that platforms can use whatever they want, non-apple devices might use wifi-direct, but apple devices would use only QDL... and we'd have a web API where devices cannot talk to each other if they are apple vs. non-apple. That seems like a non-starter for a web standard API. Is there a plan here? Or is there just a hope that apple eventually caves in terms of interop between AWDL and Wifi-Direct? WebRTC faced similar challenges, and as far as I'm aware, mandated in the specification that there be interop between web-enabled devices. Thoughts? |
|
@getify, we are planning to experiment with Open Screen Protocol (OSP) extensions as an open standards-based implementation path across platforms and browsers. We want to offer an open alternative to proprietary stacks. Chromium implementation of the OSP spec called Open Screen Library is in development. (Full disclosure: I'm the co-chair of the W3C WG that defines OSP spec and Apple is a participant of that WG among others. Intel contributes to the implementation.) |
|
It's great to see more interest in this approach. I had previously written up something similar based on the OSP spec (Old doc ). I still believe this can work, even considering the strict privacy and security (especially fingerprinting) concerns of the web. More recently I read through the Matter spec. It has many similarities to the OSP approach. This made me wonder if it would make sense to combine forces. Matter could serve as the common foundation for establishing trust between local devices (including browsers, local servers such a NAS and IoT devices). Matter, just like OSP, could easily be extended (e.g. new device type) to open 'plain' UDP/TCP tunnels to allow local P2P use-cases (within or next to Matter's PAKE secure context). It feels like this would be slightly more work but it could enable a more diverse/vibrant ecosystem due to the joint foundation. |
|
@backkem, thanks for your support, proposals and all the exploration you've done in this space over the years. For others watching, here's the missing context connecting the various dots:
I'm happy to see so many folks express interest and contribute exciting ideas in this space. Your support and contributions are super important as we advance this API further. |
|
@anssiko I guess I'm changing my mind 😄 I'll test it when it becomes available. |
|
Cross-linking a proposal from @backkem for large message considerations: https://github.com/ibelem/local-peer-to-peer/issues/11 |
|
I decided to have a go at implementing a version of this proposal as an experiment. It's now up at backkem/go-lp2p, containing a barebones OpenScreen Protocol (OSP) implementation and a version of the Local Peer-to-Peer (LP2P) API around it. The data-channel example provides a decent overview of the LP2P API that I ended up with. I deviated from the proposal quite a bit. For each deviation, I've opened issues on the local-peer-to-peer repo for further discussion. I hope this can help inform a continued design/spec effort or serve as a means of testing further ideas. |
|
@backkem, much thanks for your continued concrete contributions, including the latest implementation experiment. It is great to see multiple implementation experiments for this proposal this early. The API design will evolve informed by all the experiences gathered from these diverse implementation efforts. Btw. I'm digging the "have a Go" pun :-) |
|
The repo now lives in https://github.com/WICG/local-peer-to-peer Happy incubating!! |
|
I realize this issue is closed but it seems like the most sensible place still for mentioning another use-case for this which apparently comes up as something people want quite a bit - the ability to set up a webrtc connection between two nearby devices without using a server. This "upgrade" would be usable if, for example, the two devices are on the same LAN and the internet is down. Also it would just make an app intended for local peer-to-peer use resilient against the server used for ICE negotiation eventually being turned down. A few examples of other people trying to achieve this sort of thing with the technologies that are currently available: |
|
Indeed, I had added pion/offline-browser-communication in the explainer: https://github.com/WICG/local-peer-to-peer/blob/main/EXPLAINER.md#references as another example of this concept. |
|
One other thing I would like to raise specifically is that the proposal is currently looking a bit "mDNS" focused, which assumes devices on a shared LAN, which for many use-cases is not much better than assuming available internet access. Personally I would like NFC to be one of the top contenders, as I think many uses of local communication would prefer the explicit 1:1 relationship that NFC inherently entails. (But I recognize that peer-to-peer NFC communication is awfully hardware and device driver dependent and might therefore be hard to get working consistently.) |
|
Could you elaborate on the use-case you have in mind? Do you imagine the full communication to happen over NFC or would you use it for discovery only? |
|
The use-case for me would be NFC for discovery only, e.g. for a multiplayer game or a simple file-transfer app you could touch devices together for discovery then let webrtc take over from there, which should make it compatible with not necessarily being on the same LAN, and still remain serverless (if they're not on the same LAN and also not able to punch holes, like mobile devices often are, they would still require STUN+TURN servers, but that would still at least be cutting out the signalling server and the corresponding need for manual partner-ID matching). I can see other use-cases that would suit NFC-primary as well, like key exchange, sending small files with no auth required, or conveniently transferring links. (Maybe medium-sized data too, I'm not sure what the bandwidth is like on NFC peers - "look at this picture without me handing you my unlocked phone" might be a pretty compelling use case.) For this purpose, NFC for discovery and switching to a LAN connection if available could be pretty amazing, cutting out both the webrtc step with any external services and the "is this the expected user" negotiation of if you went direct to LAN first. (Though maybe having LAN-first discovery optionally able to just make all connections without user intervention if the use-case is a low-security one would be fine too, to achieve that low-friction initialization.) Low-friction is definitely the main thing I'm looking for - I would want users to be able to open a PWA and establish a connection to a nearby peer who also opened the app, ideally without typing or tapping anything extra. |
Maybe when using the API, you could specify if you'd like to discover using NFC, Bluetooth or LAN (allowing multiple options). Depending on what discovery methods are specified, the browser may want to handle permissions differently. |
Introduction
The Local Peer-to-Peer API enables mobile and desktop devices to transfer messages or files directly between devices through close-range communication in a privacy-preserving manner. As of today, these tasks on the web require the use of a centralized cloud service, a WebRTC-based solution or an email service that all transfer data through the internet.
When a user wants to transfer messages or files to another device nearby none of the existing solutions provide a compelling user experience because web applications are not privy to local communication technologies optimized for these tasks. This proposal solves this problem by enabling web applications to use applicable local communication technologies for data transfer between devices. This improve user experience, enhances user’s privacy and works offline without internet connectivity as is expected of every modern web application.
Read the complete Explainer
Feedback
I welcome feedback in this thread, but encourage you to file bugs against the Explainer
The text was updated successfully, but these errors were encountered: