diff --git a/public/blog/application-first/ai.png b/public/blog/application-first/ai.png
new file mode 100644
index 0000000..a92fc23
Binary files /dev/null and b/public/blog/application-first/ai.png differ
diff --git a/public/blog/application-first/eric-andre.jpg b/public/blog/application-first/eric-andre.jpg
new file mode 100644
index 0000000..1a3cdfc
Binary files /dev/null and b/public/blog/application-first/eric-andre.jpg differ
diff --git a/public/blog/application-first/step.png b/public/blog/application-first/step.png
new file mode 100644
index 0000000..018bbd6
Binary files /dev/null and b/public/blog/application-first/step.png differ
diff --git a/public/blog/application-first/sun.png b/public/blog/application-first/sun.png
new file mode 100644
index 0000000..b23ce3b
Binary files /dev/null and b/public/blog/application-first/sun.png differ
diff --git a/src/layouts/global.astro b/src/layouts/global.astro
index 127442f..0433548 100644
--- a/src/layouts/global.astro
+++ b/src/layouts/global.astro
@@ -5,22 +5,25 @@ import "@shoelace-style/shoelace/dist/themes/dark.css";
// NOTE: This is magically used as the type for Astro.props
interface Props {
title: string;
+ description: string;
frontmatter?: {
title: string;
date: string;
+ description: string;
};
}
-let { title, frontmatter } = Astro.props;
+let { title, frontmatter, description } = Astro.props;
if (frontmatter?.title) title = frontmatter.title;
+if (frontmatter?.description) description = frontmatter.description;
---
-
+
diff --git a/src/pages/blog/application-first.mdx b/src/pages/blog/application-first.mdx
new file mode 100644
index 0000000..a77b3af
--- /dev/null
+++ b/src/pages/blog/application-first.mdx
@@ -0,0 +1,211 @@
+---
+layout: "@/layouts/global.astro"
+title: Application First
+author: kixelated
+description: Yolo. Time for a startup.
+cover: "/blog/never-use-datagrams/bodies.jpeg"
+date: 2025-05-02
+---
+
+# Application First
+Today was my last day at Discord.
+It's a great company with a great product and great people.
+If you're an A/V engineer in SF, [take my job](https://discord.com/jobs/7953473002) and make me proud.
+
+My brain says I'm making a mistake, but my heart wants to kamikaze into the sun.
+It's time to double down on this passion project.
+
+**tl;dr**
+- I'm making a startup to progress Media over QUIC.
+- Any generic components will be open-source.
+- It's going to be sick.
+
+
+ 
+ Artistic interpretation of a real mood I swear.
+
+
+## Media over QUIC
+But before I explain more, I have to bore you with some history.
+
+I've been working on Media over QUIC for a long time.
+My fateful project to reduce latency at Twitch was over 5 years ago (!).
+We tried using WebRTC, but it just kind of sucked; it wasn't designed for our use case.
+I eventually stumbled upon QUIC/WebTransport and [pivoted once more](https://quic.video/blog/distribution-at-twitch).
+
+I built something called Warp as a LL-HLS replacement for Twitch and it was pretty good.
+We needed more browser support and somehow had to convince Apple this was worth adding to Safari.
+So I got permission to release it as an [IETF draft](https://www.ietf.org/archive/id/draft-lcurley-warp-00.html) despite knowing nothing about standards bodies.
+And when I say "permission", I mean we needed to get Twitch lawyers to fight against Amazon lawyers to participate in the IETF and strike down a provincial patent filed without my knowledge.
+**FUN TIMES WERE HAD.**
+
+Unfortunately, priorities at Twitch changed and Warp was only briefly in production for 10% of Chrome users.
+Amazon finally noticed that we were losing a ton of money and the post-Covid downsizing began.
+But hey, I got severance and used it to build this crude [quic.video](https://quic.video) website while in a coffee shop in Tokyo.
+I'm back in San Francisco now; a huge downgrade.
+
+## Standardization
+It turned out that the Warp draft struck a chord within IETF.
+[Meta](https://www.ietf.org/archive/id/draft-kpugin-rush-03.html) and [Cisco](https://www.ietf.org/archive/id/draft-jennings-mimi-quicr-proto-00.html) had both published similar drafts.
+All I had to do was [combine our drafts](https://www.ietf.org/archive/id/draft-lcurley-warp-04.html) and boom, we'd have the start of a new standard.
+The [Media over QUIC](https://datatracker.ietf.org/group/moq/about/) working group was born.
+It's apparently the most active working group [with a variety of drafts](https://datatracker.ietf.org/group/moq/documents/) aiming to shake up the industry.
+
+However.
+HOWEVER.
+[I decided this was not the most productive path](https://quic.video/blog/transfork).
+I stopped my involvement, and I'm no longer listed as an author on the [latest moq-transport draft](https://www.ietf.org/archive/id/draft-ietf-moq-transport-11.html).
+It would have been cool to put *author of RFC9876* on my resume.
+Oh well.
+
+Trying to standardize an experimental protocol is just a huge time sink.
+Arguing with multiple people from a big established company (__*cough*__ Cisco __*cough*__) was a nightmare.
+I was going nowhere in a hurry.
+
+I decided it would be better to join an existing company, like **Discord**, and see if I couldn't replace WebRTC from within.
+I'm kind of a gamer and have always wanted to work at Discord.
+My BFF had just become the boss of the A/V team and I was like "I'm in".
+
+Well that failed.
+I did some neat things at Discord, like rewriting the WebRTC SFU in Rust.
+But my primary passion is MoQ and it just didn't make any product sense.
+
+- Why would you rewrite your established A/V stack for nearly zero new features?
+- Why not fork WebRTC (even more) instead?
+- Who cares about a "simpler" protocol when everything already "works"?
+
+Discord is prioritizing the right projects and making incremental improvements.
+I can't disagree with any of the decisions and priorities.
+Like I said, it's a great company and I hope one day they'll end up using MoQ.
+
+But I can't keep working on WebRTC.
+There's just too many things that I wish I could improve but I'm forced to maintain compatibility with `libwebrtc` for browser support.
+It's a lucrative dead end.
+And a bitch.
+
+
+ 
+ **LET ME OUUUUUT**
+
+
+## Strengths First
+I'm guilty of advocating for new tech just for the sake of it.
+It's how you push boundaries.
+But it's also how you pivot in a circle.
+And boy do I love rewriting stuff.
+
+It might sound obvious, but you need to figure out what a new technology is good at *before* you use it.
+It could be significantly faster, or have significantly more features, or be significantly cheaper.
+But it has to have *something*.
+Otherwise you're just migrating to the nextest Javacript framework and irritating every coworker in a 5-mile radius.
+
+So what is Media over QUIC good at?
+Well, the story around CDN support is great, which is why so many CDN companies are actively participating and building prototypes.
+Google, Akamai, Cloudflare, Fastly, etc.
+
+But what real *product* use cases does it solve?
+Why would you use it over WebRTC or HLS/DASH or SRT or RTMP or TeamSpeak?
+Don't get me wrong, CDN support is great, but I'm not going to rebuild my entire media stack for that, nor would it be cheaper than existing HTTP and WebRTC CDNs.
+I need something users care about.
+
+That's where the standardization effort falls short.
+The working group is focused on dumb shit like reinventing HTTP/1.1 pipelining via [FETCH](https://www.ietf.org/archive/id/draft-ietf-moq-transport-11.html#name-fetch).
+The motivation is to support VOD, which is noble, but it's something HLS/DASH (via HTTP) already does very well.
+There's no point reinventing the [\