Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explore other local communication media #47

Open
backkem opened this issue May 6, 2024 · 4 comments
Open

Explore other local communication media #47

backkem opened this issue May 6, 2024 · 4 comments

Comments

@backkem
Copy link
Collaborator

backkem commented May 6, 2024

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
Copy link

getify commented May 6, 2024

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
Copy link
Collaborator Author

backkem commented May 6, 2024

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
Copy link

getify commented May 6, 2024

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants