MIME-Version: 1.0
From: Eli Mallon <eli@stream.place>
Date: Tue, 14 Jul 2026 21:17:17 -0700
Message-ID: 
 <CAJ_8DJ4nxZTQQ-gcM8doFMQjVA_AtsvfL1aiBUk=+NxMqK7kOA@mail.gmail.com>
To: atp@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001344f606569e9adc"
Message-ID-Hash: 46Q3ELZH3ZGYNW6DFPXNHWFMKKFY7IXD
Precedence: list
Subject: =?utf-8?q?=5BAtp=5D_atmoq=3A_ATProto_over_Media_over_QUIC_Transport?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/atp/byiE6I59R66dfxO74chBp54ctfo>

--0000000000001344f606569e9adc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 =E2=80=94 not everything in the atproto universe *quite* cleanly mappe=
d onto
MOQT primitives =E2=80=94 but overall the system works quite well. My prese=
ntation
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

--0000000000001344f606569e9adc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<div><br></div><div>My name is Eli Mallon, I&#39;m =
the creator of <a href=3D"https://stream.place/">Streamplace</a>; livestrea=
ming and VOD on the AT Protocol. (If Bluesky is working on Twitter on atpro=
to, we&#39;re working on Twitch and YouTube.) Very excited for our first WG=
 meeting next week!</div><div><br></div><div><span style=3D"background-colo=
r:transparent">In March, Suhas Nandakumar and Cullen Fluffy Jennings submit=
ted</span>=C2=A0<a href=3D"https://datatracker.ietf.org/doc/draft-nandakuma=
r-atproto-atom/">draft-nandakumar-atproto-atom-00</a>: a spec to relay atpr=
oto data over=C2=A0Media over QUIC Transport (and thus WebTransport) instea=
d of the current implementations that use WebSockets. Streamplace&#39;s wor=
k sits right at the intersection of media and atproto, so this felt perfect=
ly targeted at us!</div><div><br></div><div>The idea is exciting for a few =
reasons. On a basic level, MOQT is a lower-latency and higher-throughput pr=
otocol than WebSocket, providing us a solid protocol-level option when we g=
et to the point where sending the entire global atproto firehose over a sin=
gle WebSocket becomes unrealistic.</div><div><br></div><div>But to me the h=
eadline is this: atproto relaying over MOQT means atproto firehose data cou=
ld be broadcast over generic MoQ relays, piggybacking on the substantial ef=
fort that is going into the next generation of low-latency global media dis=
tribution. Currently, fan-out for atproto relays is handled with services l=
ike Bluesky&#39;s <a href=3D"https://github.com/bluesky-social/indigo/tree/=
main/cmd/rainbow">rainbow</a>; custom atproto-aware software purpose-built =
for fanout. A MOQT implementation would instead allow us to instead use off=
-the-shelf MoQ relays=C2=A0<span style=3D"background-color:transparent">lik=
e </span><a href=3D"https://developers.cloudflare.com/moq/" style=3D"backgr=
ound-color:transparent">the big public one that Cloudflare operates</a>=C2=
=A0or the global networks being built out by Cisco and Akamai.</div><div><b=
r></div><div>We&#39;ve recently completed an initial implementation of the =
spec called <a href=3D"https://github.com/streamplace/atmoq">atmoq</a>, whi=
ch includes a Rust server (that sits in front of an upstream WebSocket rela=
y) and Rust, Go, and TypeScript client implementations. The implementation =
diverges from the spec in some ways =E2=80=94 not everything in the atproto=
 universe <i>quite</i>=C2=A0cleanly mapped onto MOQT primitives =E2=80=94 b=
ut overall the system works quite well. My presentation next week will go i=
nto detail, but some brief highlights:</div><div><br></div><div>* Tested an=
d working with the public atproto relays at Cloudflare and <a href=3D"http:=
//moq.dev">moq.dev</a>.</div><div>* In addition to the &quot;everything&quo=
t; track that provides all the data, each separate user is made available a=
s a their own track, facilitating use cases where you only care about synci=
ng a small number of users.</div><div>* Tested and working in-browser.</div=
><div><br></div><div>We&#39;re operating a public atmoq relay at <a href=3D=
"https://streamplace.network">streamplace.network</a>, please feel free to =
try it out.=C2=A0<span style=3D"background-color:transparent">Happy to answ=
er any questions; </span>otherwise looking<span style=3D"background-color:t=
ransparent"> forward to presenting next week.</span></div><div><br></div><d=
iv>Thank you!</div><div>Eli</div></div>

--0000000000001344f606569e9adc--