Home | Notifications | New Note | Local | Federated | Search | Logout
Note Detail
dave@dthompson@toot.cat (2026-10-18 09:52:32)
I have been thinking about how QUIC, the new hotness in low-level transport protocols, might apply to OCapN. My initial findings suggest it would be a poor fit but I'm still doing research.
QUIC's killer feature, stream multiplexing, doesn't do anything for OCapN because 1) OCapN mandates only one connection may be open between any two peers at a time for reasons of reference equality (in the sense of eq? in Scheme) so there can't be multiple streams at this abstraction layer 2) OCapN mandates FIFO order of message delivery and 3) unlike HTTP, OCapN is async and doesn't use a request/response cycle so once a message is delivered the pipe isn't blocked waiting for a result. The remaining advantages of QUIC are relatively minor things like faster connection due to not having to wait for a TCP handshake before doing a TLS/Noise/whatever handshake and just not being ossified like TCP.
A reliable transport built on UDP would still be very useful for OCapN because you need UDP for NAT hole punching, but idk if there's anything that can be taken off the shelf and used as-is.
---Reply---
d@nny disc@@hipsterelectron@circumstances.run (2026-10-18 09:58:14)
@dthompson QUIC is a version of double ratchet from the signal protocol (trevor perrin was advising on both). i strongly recommend looking into that instead; that's what i'm basing a similar system on
Reply
---Replies---
dave@dthompson@toot.cat (2026-10-18 10:02:09)
@hipsterelectron I think we're talking about two different QUICs. I'm talking about https://www.rfc-editor.org/rfc/rfc9000.html