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---
Danny O'B@danny@mastodon.spesh.com (2026-10-20 00:24:14)
@dthompson Have you thought/looked into iroh any more? It's QUIC under-the-counter, though I suspect you'd need to have a simple daemon for it running alongside Goblins (a la the Tor/libp2p implementations) if you wanted it there.

---Replies---

dave@dthompson@toot.cat (2026-10-20 00:40:34)
@danny yes, a lot of this research has been because I've been catching up on what's happening with iroh! I think iroh absolutely could fit in as an OCapN netlayer and it should be an available option. And yes, a daemon would be required as we couldn't possibly implement QUIC + everything else ourselves. iroh has some overlapping concerns with OCapN that make parts of each somewhat redundant. iroh has its own concepts of multipath and relaying, for example.