[efecan0]

You’re right: HTTP adds an extra RTT and headers we don’t strictly need.

My current roadmap is:

1. Keep WebSocket as the “zero-config / browser-friendly” default. 2. Add a raw-TCP transport with a single-frame handshake: [auth-token | caps] → ACK → binary stream starts. 3. Later, test a QUIC version for mobile / lossy networks.

So users can choose: * plug-and-play (WebSocket) * ultra-low-latency (raw TCP)

Thanks for the nudge this will go on the transport roadmap.

[reactordev]

The actual handshake part of WebSockets is good. Send a NONCE/KEY and get back a known hash encoded however you like. This can be as little as 24 bytes or as much as 1024. Just sending the HTTP preamble eats through 151 bytes at least. Imagine that for every connection, per every machine... That's a lot of wasted bandwidth if one can skip it.

Compression helps but I think if you want to win over the embedded crowd, having a pure TCP alternative is going to be a huge win. That said, do NOT abandon the HTTP support, WebSockets are still extremely useful. WebRTC is too. ;)

[efecan0]

Agree: for small devices every byte counts. Plan is to keep WebSocket for zero-config use, but add a raw-TCP handshake (~24-40 bytes) so embedded clients can skip the HTTP preamble. I’ll note that on the transport roadmap. Appreciate the insights!

[inetknght]

> Compression helps

It's generally unwise to use compression for encrypted transport such as TLS or HTTP/S.

https://en.wikipedia.org/wiki/Oracle_attack

[efecan0]

Good point, thank you.

You’re right—no compression over TLS by default. If I add deflate support later it will be opt-in and disabled when the connection is encrypted.

Appreciate the insights!