Some thoughts The design proposal doesn't say one way or the other, but I guess/hope this would be plumbing through to the underlying OS IP stack, otherwise yo

Some thoughts The design proposal doesn't say one way or the other, but I guess/hope this would be plumbing through to the underlying OS IP stack, otherwise your browser would need to obtain its own IP address. The source repo for this is called raw-sockets but nothing implies that's what they would actually use/require; raw sockets usually require root. The proposed API is just to open sockets. Does this mean all these non-HTTP protocols are going to be implemented separately? Will they ship with Chromium, or are we looking at web sites sending down a bunch of wasm-compiled protocol implementations? Honestly, the developer thread was really enthusiastic but didn't seem to account for the vast gulf between "can open a tcp socket" and "functional mail client". It's interesting that in the security mitigations section of the explainer doc, the author is explicit that listening for incoming connections is not part of the proposal _yet_. The developer thread is full of ideas that would require incoming connections (DHT specifically) though. Also, the idea that this unlocks communication with legacy systems seems counter to the idea that hostnames resolving private addresses won't work. I guess you get around this by making your app have connection profiles (common with RDP, Chrome OS SSH app does this, etc.). I think this makes the most sense if you consider a web browser to actually be a rich UI toolkit that happens to speak HTTP. Should these developers get to write other network clients with CSS/JS frontends, or not?