Last week was the last official week of my Recurse Center batch.

While at RC, I worked on a lot of different projects, paired with a lot of people, wrote a few blog posts, and presented on both technical and non-technical topics many times.

My main goal was to become a better programmer by writing a lot of Rust and working in a domain I find particularly interesting.

Not only did I succeed at this, but I surpassed my own expectations!


The main project I worked on was a recently announced Media over QUIC library implementation written in Rust. This library, originally started by Luke Curley as a rewrite of his Go proof of concept “WARP” implementation, now represents a leading edge open source implementation that’s being used to inform the design of the Media over QUIC specifications themselves. I worked with Luke to help design several major revisions of the library API and also contributed code which included fleshing out proofs of concept around contribution workflows.

I also deployed Media over QUIC relays running this code to both and Google Cloud (GKE) to use for testing.


The bulk of the code I wrote this summer was for a video ingest / contribution tool called moq-pub. Much of that code has since been rolled into the underlying library.

moq-pub takes fragmented MP4 media and sends it to a MoQ relay server using the MoQ Transport protocol (MoQT). Essentially:

ffmpeg -i tears_of_steel.mp4 -f mp4 ... - | moq-pub --host

Working on moq-pub was a great excuse to take a deep dive into topics like:

  • The ISO BMFF / MP4 container format
  • The QUIC transport protocol and the various Rust libraries that implement QUIC today
  • WebTransport
  • async Rust and tokio
  • Designing async / await Rust code using channels to simplify ownership of shared resources

We also learned a lot about how the library’s ergonomics could be improved by encapsulating more of the protocol’s messaging and protocol-related state rather than forcing client applications to maintain that state and handle control messages on their own. (This is why the current version of moq-pub is so much smaller than the first version I wrote.)


Having a CLI tool to handle MoQ contribution workflows is great, but I thought it would be even better if we could make MoQ connections directly from software like ffmpeg, OBS, and gstreamer.

So, following up on moq-pub, I’ve also built a small Rust library to wrap moq-rs and expose a C FFI so that non-Rust native code can also contribute streaming media using Media over QUIC.

I call this library libmoq, and I already have a very lightly patched version of ffmpeg that can make use of libmoq to connect to a MoQ relay server and send video. The current implementation still has a few bugs, but I’m actively working on fixing them so others can take advantage of this code, too. Expect to see a bit more polish and documentation in the coming weeks.

et cetera

Besides all of the Media over QUIC work above, I also worked on various other smaller learning projects, some of which I’ll also be open sourcing. I also paired with a lot of other folks on both some of this code, and on their own projects.

I would love to stay at RC forever. I’m pretty sure this has been the most fun I’ve ever had programming, and I really like programming!

Maybe someday I’ll have saved up enough to retire for good, and then I can just hang around RC and the Virtual RC space and work on fun open source stuff forever…

But today is not yet that day. I’ll have to go back to a paying job sooner or later. Maybe I can at least find a fun and collaborative team to join and carry some of this great energy forward…

If any of this sounds interesting, you know where to find me.

(Hachyderm, Bluesky, Discord, Twitter [LinkedIn?][], etc.)

P.S. I’ll be at Strange Loop later this week if anyone wants to meet up there!