[Atp] atmoq: ATProto over Media over QUIC Transport

[Eli Mallon <[e-mail]>]

Hi all,

My name is Eli Mallon, I'm the creator of Streamplace
<https://stream.place/>; livestreaming and VOD on the AT Protocol. (If
Bluesky is working on Twitter on atproto, we're working on Twitch and
YouTube.) Very excited for our first WG meeting next week!

In March, Suhas Nandakumar and Cullen Fluffy Jennings submitted
draft-nandakumar-atproto-atom-00
<https://datatracker.ietf.org/doc/draft-nandakumar-atproto-atom/>: a spec
to relay atproto data over Media over QUIC Transport (and thus
WebTransport) instead of the current implementations that use WebSockets.
Streamplace's work sits right at the intersection of media and atproto, so
this felt perfectly targeted at us!

The idea is exciting for a few reasons. On a basic level, MOQT is a
lower-latency and higher-throughput protocol than WebSocket, providing us a
solid protocol-level option when we get to the point where sending the
entire global atproto firehose over a single WebSocket becomes unrealistic.

But to me the headline is this: atproto relaying over MOQT means atproto
firehose data could be broadcast over generic MoQ relays, piggybacking on
the substantial effort that is going into the next generation of
low-latency global media distribution. Currently, fan-out for atproto
relays is handled with services like Bluesky's rainbow
<https://github.com/bluesky-social/indigo/tree/main/cmd/rainbow>; custom
atproto-aware software purpose-built for fanout. A MOQT implementation
would instead allow us to instead use off-the-shelf MoQ relays like the big
public one that Cloudflare operates <https://developers.cloudflare.com/moq/> or
the global networks being built out by Cisco and Akamai.

We've recently completed an initial implementation of the spec called atmoq
<https://github.com/streamplace/atmoq>, which includes a Rust server (that
sits in front of an upstream WebSocket relay) and Rust, Go, and TypeScript
client implementations. The implementation diverges from the spec in some
ways — not everything in the atproto universe *quite* cleanly mapped onto
MOQT primitives — but overall the system works quite well. My presentation
next week will go into detail, but some brief highlights:

* Tested and working with the public atproto relays at Cloudflare and
moq.dev.
* In addition to the "everything" track that provides all the data, each
separate user is made available as a their own track, facilitating use
cases where you only care about syncing a small number of users.
* Tested and working in-browser.

We're operating a public atmoq relay at streamplace.network, please feel
free to try it out. Happy to answer any questions; otherwise looking
forward to presenting next week.

Thank you!
Eli