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.
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