Local Peer-to-Peer API Draft Community Group Report
wicg.github.io
Local Peer-to-Peer API Draft Community Group Report
1–10 of 12 posts
Re: Local Peer-to-Peer API Draft Community Group Report
#2https://wicg.github.io/local-peer-to-peer/#security-same-ori...
The W3C won't ever adopt a system like this. They intentionally nerfed all local-loopback servers to never be able to effectively use websockets or ssl. That seems like a place to start before adopting this.
I honestly don't believe we will be able to meaningfully change or improve browsers without abandoning the w3c and starting standards over almost from scratch. Brave exists, but we would need to do better than that and design more general p2p protocols and systems.
Re: Local Peer-to-Peer API Draft Community Group Report
#3Local peer to peer? Please, just give us QUIC API for Peer-to-peer Connections https://github.com/w3c/p2p-webtransport and bring back Network Discovery https://www.w3.org/TR/discovery-api/ or something like it.
Conflating a couple separate specs together for a single use case is bad. Keep specs lower level. P2p connectivity should be a thing, unto itself. Local networking should be a thing.
See also, direct socket API in Chrome 131, 5 days ago, https://news.ycombinator.com/item?id=42022649
Re: Local Peer-to-Peer API Draft Community Group Report
#4Local peer to peer? Please, just give us QUIC API for Peer-to-peer Connections https://github.com/w3c/p2p-webtransport and bring back Network Discovery https://www.w3.org/TR/discovery-api/ or something like it. Conflating a couple separate specs together for a single use case is bad. Keep specs lower level. P2p connectivity should be a thing, unto itself. Local networking should be a thing. See also, direct socket AP…
I was one of the original authors of the p2p QuicTansport API and the WebTransport API which is based on it.
I've also recently discussed this new local p2p API with the authors. And I'm in the favor of it, at least in principle.
The difference is that local p2p does not require signaling like, say the p2p done by ICE, WebRTC, or p2p QuicTransport. So for some uses cases, this would be better. And, if done right, this would fit well into a cohesive set of APIs that cover both kinds of p2p.
I'm also in favor of making APIs low level, but I'm not sure if raw sockets is going to work. Keeping congestion control working is pretty important.
Re: Local Peer-to-Peer API Draft Community Group Report
#5https://wicg.github.io/local-peer-to-peer/#security-same-ori... The W3C won't ever adopt a system like this. They intentionally nerfed all local-loopback servers to never be able to effectively use websockets or ssl. That seems like a place to start before adopting this. I honestly don't believe we will be able to meaningfully change or improve browsers without abandoning the w3c and starting standards over almost fr…
WebRTC (with p2p) was done within the W3C, as was a p2p QuicTransport. And this new API is similar to the open screen APIs that have been done in the W3C.
So I'm pretty sure work like this can be done in the W3C.
Re: Local Peer-to-Peer API Draft Community Group Report
#6https://wicg.github.io/local-peer-to-peer/#security-same-ori... The W3C won't ever adopt a system like this. They intentionally nerfed all local-loopback servers to never be able to effectively use websockets or ssl. That seems like a place to start before adopting this. I honestly don't believe we will be able to meaningfully change or improve browsers without abandoning the w3c and starting standards over almost fr…
WebRTC (with p2p) was done within the W3C, as was a p2p QuicTransport. And this new API is similar to the open screen APIs that have been done in the W3C. So I'm pretty sure work like this can be done in the W3C.
Try making webrtc work without a domain name and ssl cert. It shipped compromised so it couldn't be used without giving the server the potential to mitm all connections. its not p2p in any sense except network efficiency.
Re: Local Peer-to-Peer API Draft Community Group Report
#7Why does this contain both data channels and WebTransport? Isn't the latter just more data channels?
edit: OK, I found this issue.
https://github.com/WICG/local-peer-to-peer/issues/29
Ugh... this is just so poorly thought through. We keep ending up with overly complex protocols that have too many states and too many options and too many control messages to accomplish what a more simple API could provide, and so to implement all of this we keep needing too much code and too many special cases and too many round trips to establish anything.
Re: Local Peer-to-Peer API Draft Community Group Report
#8I made something that achieved similar results with existing technologies by abusing STUN/TURN.
It does not handle discovery but it does allow local communication without a server.
https://blog.yifangu.com/2024/07/16/crossing-the-mixed-conte...
Re: Local Peer-to-Peer API Draft Community Group Report
#9I made something that achieved similar results with existing technologies by abusing STUN/TURN. It does not handle discovery but it does allow local communication without a server. https://blog.yifangu.com/2024/07/16/crossing-the-mixed-conte...
I did something similar a while back: https://github.com/pthatcherg/stunl
Re: Local Peer-to-Peer API Draft Community Group Report
#10Earlier quoted context omitted.
WebRTC (with p2p) was done within the W3C, as was a p2p QuicTransport. And this new API is similar to the open screen APIs that have been done in the W3C. So I'm pretty sure work like this can be done in the W3C.
Try making webrtc work without a domain name and ssl cert. It shipped compromised so it couldn't be used without giving the server the potential to mitm all connections. its not p2p in any sense except network efficiency.
I'm not sure what you mean. It does work without a domain name and SSL cert.