search

WICG / local-peer-to-peer

↔️ Proposal for local communication between browsers without the aid of a server.
https://wicg.github.io/local-peer-to-peer/
Other
62 stars 6 forks source link

Explore other local communication media #47

Open backkem opened 1 month ago

backkem commented 1 month ago

As pointed out by @ravenblackx here, the current specification may over-fit somewhat on using the LAN and mDNS for connectivity.

While we already phrase the API design as separate from the connection medium and put forward OSP as one canonical protocol implementation, it may be worth emphasizing broader applicability. A first step could be adding a section with illustrative examples of other connectivity options. Examples include: NFC, BLE & Wi-Fi Direct for discovery and, where feasible, for transport. This is also in-line with the local communication medium wording of the explainer.

The same comment also brings up WebRTC as a transport. Interoperability with WebRTC is an interesting topic to explore. However, it goes beyond the "local communication medium" scope we've set for ourselves. Aside from WebRTC, there is prior work on supporting discovery in a WAN setting, E.g.: RELOAD. Again, it's out of our scope to tackle this now but it does beg the question if it would make sense to name the API to be forward compatible with non-local use cases. E.g.: l2p2 -> p2p prefixes.

getify commented 1 month ago

The same comment also brings up WebRTC... Interoperability with WebRTC...

I don't see supporting the interop of negotiating/signaling for other P2P options (like WebRTC) as expanding beyond the "local" part of this API. I think that's very much in scope and relevant.

But if we were going to spec out a broader P2P connectivity beyond the "local" part, I'd hope that would involve exposing direct UDP sockets support (perhaps similar to Node), which is a favored way of doing P2P in non-web contexts. I don't think those are going to fit cleanly in the currently imagined API, no matter what it's named. That said, such effort seems to me too far to reach for in this current proposal.

backkem commented 1 month ago

Yes, interoperability as in a developer wiring both APIs together is a given. I meant considering WAN transports on the inside of the API is out of scope.

Regarding raw sockets: there is another WICG project exploring this already. This approach has very different security implications. We're purposefully trying to design within a strict security model.

getify commented 1 month ago

I meant considering WAN transports on the inside of the API is out of scope.

Yeah, that seems like a reasonable line to draw.

DanielHerr commented 1 month ago

Another example is local multiplayer on handheld game consoles such as Nintendo DS, Switch, and Playstation Portable, though I'm not sure what underlying protocols they use.