Oddbean new post about login | logout > bringing TCP to Nostr I'm not quite sure what this means. Client-relay communication is accomplished via WebSockets, which is built on top of HTTP, which is built on top of TCP. So we're building TCP on top of TCP?
technically, websockets are just a way to switch to TCP after starting with HTTP
So...still TCP on top of TCP 🤣
I get the significance of web service discovery through relays (which seems to be what this NWS is?), but I'm scratching my head wondering if Nostr is the best tool for solving the problem.
nope, it's raw you have to manage your own pings, it's in the spec but you have to handle making and receiving them and timing out connections oh yeah, they can manage configurable compression options, that's automated, i don't think there is very much other than this
https://datatracker.ietf.org/doc/html/rfc6455 i'm gonna sit and read this, and i think you should too, because we use this all day long
Conceptually, WebSocket is really just a layer on top of TCP that
does the following:
o adds a web origin-based security model for browsers
o adds an addressing and protocol naming mechanism to support
multiple services on one port and multiple host names on one IP
address
o layers a framing mechanism on top of TCP to get back to the IP
packet mechanism that TCP is built on, but without length limits
o includes an additional closing handshake in-band that is designed
to work in the presence of proxies and other intermediaries
https://datatracker.ietf.org/doc/rfc9220/ this might be interesting too... it's basically reworking websockets to work over QUIC transports (which is UDP @ChipTuner @Michael J )
yeah, it's basically the same as TCP except, mostly, the rigmerole of handshake and disconnect, and that you can send either binary or text frames, everything else is optional... maintaining a ping to detect loss of connection is application level, but conventional
Thanks for this! Gonna give it a read.
there is a version for QUIC/HTTP/3 https://www.rfc-editor.org/rfc/rfc9220.html one big difference is that http/3 has built in scheme for multiplexing connections so this is quite cool for nostr as it means you could auth on one stream and bind it to the multiplexed connection and not need to auth for each stream - most clients start up multiple sockets, 2 or 3 at least often sit open for an hour or more if you walk away
A crappy VPN really. There is a reason VPNs use UDP datagrams
i think the thing is that the nostr should just be a weakly consistent data store for relay and service addresses creating tunnels should definitely stay on another protocol layer
%100!!!! The amount of crazy stuff I never though was possible just by having publicly available database secured with some math is unreal. An extremely solid spec to just focus on that ability and were living the dream!
yeah, it's really important to keep domains separated, i'm sure you know well what happens when you write code that handles too many contingencies and then you realise you forgot one and it breaks the whole thing when it would have worked better if you made it into a layer cake with simple parts that are related in each layer and passing data between the layers to enable the complex behaviour