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.
This is just an initial proposal, and probably will reduce down to one with developer feedback and implementation experience, which is normal for API development.
Whether it's one shape or the other doesn't take affect the network protocol underneath.
If you have constructive ideas of how to simplify the protocol underneath or the API, you can share them with the authors. The people that work on that APIs are always looking for constructive feedback
> Whether it's one shape or the other doesn't take affect the network protocol underneath.
So, the issue I see talks about the API, but the duplication in the specification is at the level of the network protocol: there are different capabilities being exposed and different kinds of headers being attached to the packets.
Honestly, it just isn't clear to me that the entire concept of these stacks is even trying to be simple, and so my experience has been that deep thought that leads to simpler things isn't considered valuable.
I mean, as a single trivial related example: I love WebRTC, I have a giant stack built using it, and I even can mostly defend how it was architected... but the idea that every packet can be tagged as either a string or a binary is superfluous complexity that is not present in any comparable protocol including the now multiple competing specifications for implementing similar things, as we have somehow ended up with all of WebSockets, WebRTC, and WebTransport.
Only, here, in this spec, people not only want string and binary, they want to add a third one?!
This just isn't needed, and is at the point of strongly coupling the entire protocol to JavaScript, as, otherwise, what even is the difference between a "Blob" and an "ArrayBuffer"?
If you are receiving a packet, you should either always get an ArrayBuffer or a Blob depending on if you want the underlying protocol to construct messages or streams. (And, in this case, it should be a ArrayBuffer.)
It should then be easy to construct a Blob (if we must have this idea at all) from an ArrayBuffer; and it is already (apparently) easy to get a String or ArrayBuffer from a Blob (though this inherently requires a copy; but again: this is a packet oriented protocol, so it should always be using ArrayBuffer).
Meanwhile, there should be a really cheap way of getting a String from an ArrayBuffer, as JavaScript uses UCS-2 anyway, so there is no true "encoding" that happens... it could be this is the case, but I'm pretty sure that the current way to do this always causes a needless copy.
This would not only be sane, this is effectively how the other two related protocols already work: WebTransport doesn't have any of this silliness, nor did WebSockets; they let you configure how you receive data, but that's a decision for the receiver, not the sender.
And I must underscore that point, as if I want to receive data in a steam-like interface to handle someone sending me an insanely large packet (which WebRTC supports btw: you can run out of RAM on a single message), the sender shouldn't be the one to specify "no: you MUST receive this as a single giant ArrayBuffer, as I didn't mark this as Blob".
But like, if you read the issue I linked there, the people working on this are actively trying to encode these kinds of type preservation into the design. In either that issue or a linked one, they discuss that, if they go with a WebTransport-based protocol, maybe they will need to as the spec authors (and not the end developer) define a framing solution to get this feature back.
And so the problem then is that the kind of feedback I have is, inherently, "non-constructive": to me, the problem is that people are being "constructive". And so I am showing up saying "no this thing you want shouldn't happen: you don't need it and you should leave it up to the end-to-end principle for people to build this on top".
The people building this have some kind of use case in mind where they have become excited to build a kind of high-level RPC that they clearly feel requires a serialization format so they can transfer high-level objects across the wire, but I feel that should inherently be out of scope for this kind of specification.
And so "the thing you want isn't what anyone should build" always comes off as "deconstructive", as in some very real sense it must be. I thereby find that people like me just sit around grumbling as we find the entire concept of a web browser muddied up with a billion similar-yet-incompatible ideas all sort of trying to be general purpose and yet each one designed by people with a single use case in mind, and then, often, entirely abandoned later without any attempt to either evolve or normalize it (as is the case with WebRTC, which people seem to have simply given up on, even as it was just starting to get good).
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.
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.
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.
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 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.
Why 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.
This is just an initial proposal, and probably will reduce down to one with developer feedback and implementation experience, which is normal for API development.
Whether it's one shape or the other doesn't take affect the network protocol underneath.
If you have constructive ideas of how to simplify the protocol underneath or the API, you can share them with the authors. The people that work on that APIs are always looking for constructive feedback
> Whether it's one shape or the other doesn't take affect the network protocol underneath.
So, the issue I see talks about the API, but the duplication in the specification is at the level of the network protocol: there are different capabilities being exposed and different kinds of headers being attached to the packets.
Honestly, it just isn't clear to me that the entire concept of these stacks is even trying to be simple, and so my experience has been that deep thought that leads to simpler things isn't considered valuable.
I mean, as a single trivial related example: I love WebRTC, I have a giant stack built using it, and I even can mostly defend how it was architected... but the idea that every packet can be tagged as either a string or a binary is superfluous complexity that is not present in any comparable protocol including the now multiple competing specifications for implementing similar things, as we have somehow ended up with all of WebSockets, WebRTC, and WebTransport.
Only, here, in this spec, people not only want string and binary, they want to add a third one?!
https://github.com/WICG/local-peer-to-peer/issues/13
This just isn't needed, and is at the point of strongly coupling the entire protocol to JavaScript, as, otherwise, what even is the difference between a "Blob" and an "ArrayBuffer"?
If you are receiving a packet, you should either always get an ArrayBuffer or a Blob depending on if you want the underlying protocol to construct messages or streams. (And, in this case, it should be a ArrayBuffer.)
It should then be easy to construct a Blob (if we must have this idea at all) from an ArrayBuffer; and it is already (apparently) easy to get a String or ArrayBuffer from a Blob (though this inherently requires a copy; but again: this is a packet oriented protocol, so it should always be using ArrayBuffer).
Meanwhile, there should be a really cheap way of getting a String from an ArrayBuffer, as JavaScript uses UCS-2 anyway, so there is no true "encoding" that happens... it could be this is the case, but I'm pretty sure that the current way to do this always causes a needless copy.
This would not only be sane, this is effectively how the other two related protocols already work: WebTransport doesn't have any of this silliness, nor did WebSockets; they let you configure how you receive data, but that's a decision for the receiver, not the sender.
And I must underscore that point, as if I want to receive data in a steam-like interface to handle someone sending me an insanely large packet (which WebRTC supports btw: you can run out of RAM on a single message), the sender shouldn't be the one to specify "no: you MUST receive this as a single giant ArrayBuffer, as I didn't mark this as Blob".
But like, if you read the issue I linked there, the people working on this are actively trying to encode these kinds of type preservation into the design. In either that issue or a linked one, they discuss that, if they go with a WebTransport-based protocol, maybe they will need to as the spec authors (and not the end developer) define a framing solution to get this feature back.
And so the problem then is that the kind of feedback I have is, inherently, "non-constructive": to me, the problem is that people are being "constructive". And so I am showing up saying "no this thing you want shouldn't happen: you don't need it and you should leave it up to the end-to-end principle for people to build this on top".
The people building this have some kind of use case in mind where they have become excited to build a kind of high-level RPC that they clearly feel requires a serialization format so they can transfer high-level objects across the wire, but I feel that should inherently be out of scope for this kind of specification.
And so "the thing you want isn't what anyone should build" always comes off as "deconstructive", as in some very real sense it must be. I thereby find that people like me just sit around grumbling as we find the entire concept of a web browser muddied up with a billion similar-yet-incompatible ideas all sort of trying to be general purpose and yet each one designed by people with a single use case in mind, and then, often, entirely abandoned later without any attempt to either evolve or normalize it (as is the case with WebRTC, which people seem to have simply given up on, even as it was just starting to get good).
Local 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
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.
https://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.
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.
I 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