The Code is the Easy Part

Jim Ray: How would you rebuild, from scratch, one of the most foundational pieces of software on the modern web, the platform that powers over 40% of websites today. This was the question Matt Kane, a principal engineer at Cloudflare, was facing earlier this year when he took on the task of creating the EmDash CMS project. What he calls the spiritual successor to WordPress. First launched as a beta on April 1st, and then as a 1.0 at the end of September, EmDash is indeed a complete rethink of the 25-year-old WordPress. And it was made possible by two technologies: AI coding agents, and AT Protocol. Matt, who has a long history with open source software, including as a core contributor to the Astro project that EmDash is based on, talks about why atproto was an obvious choice for the plugin directory and how much he enjoys working with the atproto developer ecosystem.

EmDash, though, isn’t just a recreation of one of the most successful pieces of open source software in history. It’s a demonstration of what’s possible today when building with agents. Matt offers some timely guidance and wisdom for what modern software development looks like. how to keep your open source projects from being overwhelmed by slop-ridden PRs, and where to focus your time as an engineer. EmDash is an exciting new CMS. atproto Ecosystem project and just as exciting, a master class and how to build software today. I learned a lot from this one and I hope you enjoy my interview with Matt Kane.

Matt Kane, welcome to Off Protocol. I’m delighted to have you here.

Matt Kane: Great. Well, it’s great to be here, Jim. Thanks for having me.

Jim Ray: Matt, you are one of these folks who has a very enviable domain name in that it’s like super the brevity is there mk.gg I wasn’t even sure what the .gg TLD stood for how like is that is that just because you’ve been around for a minute? How is it that you came to possess such an incredible domain name.

Matt Kane: Well, I think you’ve kind of managed to find the dark secret of a lot of the success of AT Protocol is that it’s a really great way for people to flex their domain purchases. So it’s I’ve actually had it for less time than you would have thought. I’ve had it for like for less than ten years actually. And it’s a Guernsey domain, G and the main thing was that they did two letter domains. And I’ve got the extremely confusing thing of having a colleague who is tk.gg who is also called Matt and was also involved in is also on my save almost the same team at Cloudflare. So we have a one-letter difference in our in our domain name and we’re both called Matt.

So that causes no end of confusion. So I very much appreciate that Bluesky allows me to flex having a having a short domain. It is one that confuses people when I tell them you know, when I when I tell them it, who are normally people who don’t realise that domains can be that short. And also occasionally run into problems with forms where they don’t expect an email address to be able to be that short.

Jim Ray: Right amazing. It’s like the inverse of having a hyphenated super long name or something like that. I think people who understand kind of how the domain name system works, they do love the fact that so much of the protocol is built on DNS. And but I hadn’t quite considered that you get to kind of flex the fact that you have a very cool domain name right there in your user handle.

Matt Kane: I’m I still always have to defer to my wife though, who has got the best domain that I know because she’s called Eloise and her domain is eloi.se. So that’s like you know, but that does sort of lead up to one of my, you know, my one of my great rivals who is the person who owns the equivalent domain, which is ma.tt. So that is Matt Mullenweg, the creator of WordPress.

Jim Ray: Yes, exactly. And we’re going to talk a little bit about WordPress here in a minute. And we at Bluesky, we also for a while people were wondering if we would only hire people so that we had pairs of them. There are two Jims, there are two Alex’s. We have a couple of other multiple names, but the TK and the Matt Kane, that is that’s a truly impressive pairing there.

Matt Kane: We also joined Cloudflare within a week of each other last year.

Jim Ray: I would think recruiting alone would be like I don’t know if we can hire two folks that have such similar names.

Matt Kane: And we’re both, you know, English guys with a similar accent and you know I’m a you know it’s there’s a lot of a lot of potential confusion there.

Jim Ray: Amazing. But it seems like it could also be pretty fun. Maybe on an April Fool’s Day or something like that. So Matt, you’ve got a pretty fun history of being an engineer and i want to talk a little bit about how it is that you came to be a protocol knower as we like to say your original history your career starts as a pastry chef is that right.

Matt Kane: It’s true, it’s true. And I mean the a lot of this comes down to the fact that I am quite old and when I was a you know, when I was a kid I you know I started I started doing programming when I was like eight, ten or something. And then started getting kind of seriously into it when I was about eleven or twelve. But at no point did I realize that it was a job. So I didn’t even consider it. So I did the other thing that I really liked which was cooking. So this was, you know, this was in the nineties and I still love cooking and I still really, you know, and still would l love to do it.

And may, you know, I may have still being the chef now if the if the hours were better and the pay was pay was able to match what I what I can get as a software engineer. But yeah, so I started out as a chef. I was a pastry chef specifically. That was just because I’d been a baker beforehand. So I did that for a few years and that was kind of that’s what my training was. You know, I went to Catering College. I, you know, worked as a chef and it was a huge amount of fun. But it was you know, I was I was f getting close to burning out at the age of twenty, so that’s why I left it and it was kind of peak.com time and I thought oh you know seems like you can actually have a job doing coding so that was when I started doing things for the web and that’s where I still am, you know, more than twenty five years later.

So I don’t consider them to be incompatible. They’re both you know, you make something, you get quite instant gratification from it. You make something is there immediately. And then you go and put yourself out in front of everybody and tell and see if people like it. and if people spit it out then you immediately get you know, you feel you feel bad about it and if they if they find something nasty and t send it back to the kitchen then you’re in trouble. But equally if everybody’s going, oh, you know, come I’ve traveled from everywhere to as I told, you know, someone told me about your sticky toffee pudding or whatever, then you know, it gives you that that kind of gratification.

So I think that sort of, you know, that’s what I’ve been wanting to do since then is building things and making stuff for people, you know, to try out. And that’s kind of why I like doing open source software is that I just, you know, I got such quick turnaround, I just build something, share it, and people can try it out.

Jim Ray: As an amateur, I have no formal training, but I am the cook in our house. I really love that framing a lot. And I’m just going to think of when my kids reject what I’ve made for dinner. That’s the that’s the equivalent of a compilation error. and something to learn from and we’ll try to do better next time.

Matt Kane: Exactly. You know, put that one on the backlog and you know when it when it comes back around then you can you can sh ship a new version and see if you can, you know, the latest iteration is able to Hit your KPIs.

Jim Ray: Yeah, there you go. There you go. Well, so I think I first noticed you in the atproto ecosystem with a project that you still run called Cirrus, which was not your first atproto project I went on to discover, but was the one that I think it was most interesting to me. And Cirrus was it honestly it felt like a provocation more than anything. It was, can we run a PDS? inside of a Cloudflare worker with I g I guess it’s a single JavaScript file, is that right?

Matt Kane: It’s I mean it c it kind of started out that way. It’s kind of grown to a bit more but it is basically it was basically that it was lu it was one of those kind of could this work? And it’s kind of there’s a bit of a thing within engineers within Cloudflare that once you kind of get to know them, everything in Cloudflare people want to build using a durable object. Durable objects are one of the primitives at Cloudflare that are most misunderstood. Or it’s not even that they’re misunderstood, they’re just not understood because they’re quite confusing. And before I worked at Cloudflare, I kind of vaguely knew that they were you could use them for WebSockets and that they had some stuff with storage in them, but I’d never really tried because it just seemed like what you know, sounds neat, but I can’t really sh think about what it’s what I would use it for.

And shortly after I started Cloudflare, I started playing around with durable objects a bit more. And I realized that they are actually really cool because they are basically just a little web server that’s, you know, and they’re a web server where you can spin up a web server for anybody. You know, you can have an infinite number of them every single user could get their own one and it comes with a little SQLite database and it comes with ability to have web socket hibernation and you know just lots of useful stuff is built in. So it’s a really nice thing for if you are building out some quick project that you need lots of different bits of pieces and it’s just there.

And, you know, it’s kind of you don’t need to think so much about some of the kind of annoying bits of serverless architecture with the them being stateless and so on. So anyway, long story short, I obviously I’m seeing this stuff about it being good for WebSockets and I’m playing around with it. And having spent a bit of time looking at atproto stuff, I was thinking, hmm, WebSockets. I know what uses WebSockets. And I was just like, has anybody tried doing this? And I’d looked and then there was some kind of been some talk about it. And there’d been a few things about trying to use durable objects for some certain parts of the atproto stack, but nobody seemed to have tried to do it with a PDS.

And this was basically over the Christmas holidays last year. And as most engineers at the time had we had double Claude credits and thought that Opus 4.5 might was realized that it could actually be used to build stuff properly. and maybe it would be worth trying something out. So I just, you know, I just did a few tests first and just sort of saw whether it could whether it could, you know, hold open a firehose and just see how it might work for sending events and stuff. And my first tests all sort of started to work. So I just thought let’s just do it. And it was I was actually away on holiday at the time and I just got as you know, this sort of ha seems to happen a lot is I’m you know I’m away, I’m doing something and I you know I’ve just got completely tied up in it.

And I remember trying to like making decisions and trying to change the design on the top of a tor with like a big pile of rocks in Dartmoor, in i in the like in Devon in England, like a windswept tor, you know, going for a lovely walk and sort of, you know, the bracing December wind and then going, oh actually let’s just check what’s going on and sending a few notes and stuff to improve my improve this new this weird thing that I was building. But that that was basically where I got to it. And so I made this thing, and then obviously, you know, it was it was initially an extremely vibed thing, the fact that I was controlling it by phone. But then I started using it, you know, trying out for real and polishing it and reviewing it and, you know I’ve I’m very used to reviewing code of variable quality. You know, I’ve worked in open source for a long time and you know I’ve written a lot of variable quality code myself. So it was kind of fine reviewing it and looking at it and then trying it out. And I it got to the point I was just like, let’s just do it. And I migrated my main account over and you know, I did that I think in January I first migrated it and I’ve been running off it ever since. And it’s works.

You know, there’s bugs, there’s all kinds of random things that come up and it’s like 95% those are OAuth related and I you know it’s may I’ve done stuff like thing I’ve made a I’ve made a th a tool for Cirrus that is a PDS conformance checker because it’s really hard to see if it’s doing things right. So I’ve now got the so that’s a check.cirrus.earth which will let you like point it at any PDS and it will tr run lots of tests on it to see if it does what it’s supposed to do. Because you know, there’s one thing following the protocol and there’s the other of actually doing what things in the wild expect, you know, if there is some quirk in the reference PDS that lots of sites have come to expect, then you have to follow that and you know that’s the way that things are.

But I think I think you know the th the thing about it was that I kind of really liked the whole concept that atproto has of owning your data and you know it as a your own the data you can have, you know, you can you can do what you want with it. But it was kind of like this is great in theory, but in practice it’s not actually so realistic. So I just thought, well, what is the absolute minimum way you could do it and this is why a focus all the way through was that this was going to be a single user PDS.

Jim Ray: Right.

Matt Kane: I was not, you know, I was deliberately designing it. with that constraint is that I was not going to do any of the user related stuff and the whole thing was going to be set up using a CLI. You would do I mean, w when I realized that the npm create pds package name was available, that was like completely got me set on it. So that is the way that you now do Cirrus, is you do npm create pds. It walks you through the whole thing and will migrate you over and it’s been good because it’s like I’ve used that flow for lots of other things as well now. So it’s it was a really good way of learning those kind of like deeper parts of the protocol.

Jim Ray: There’s so much about Cirrus that I really like, starting with that idea of the m kind of minimum viable PDS and how you actually make some of these kind of big, often abstract ideas about data ownership. Or, you know, control over your experience on the internet a little bit more accessible. This is something that comes up a lot. And so I think just taking that and making it a little bit more concrete is it’s really great. The name is amazing too. So thank you for kind of like going with our like atmospheric waves there. And it’s also exciting to hear that, you know, you’ve been running this in production on your own for coming up come out of a year now.

I w I wanna circle around back to the AI coding bit, but I think as you were talking, one thing that I was thinking is I think it was Simon Willison who kind of identified November of twenty-five as like this inflection point. But I really do think that that Christmas was like was maybe even a more kind of visible inflection point because it was when a lot of folks like yourself had a little bit of time to start playing around with some of these things on their own. I think internally we’ve seen a few projects emerge. There was one that just came out this week. They kind of very clearly vibed like an entire programming language and the thing that they built first as a reference for their programming language was a PDS.

And so we’re kind of excited about this idea because if you can build something, if you can build a PDS, whether it’s with a new programming language or a new framework or at you know like you were saying something like durable objects, then it gives you a way to test a lot of different parts of your stack, I would think.

Matt Kane: Yeah, absolutely. And I think the double Anthropic’s double Claude credits over the over the holiday period certainly helped as well.

Jim Ray: Yeah. Absolutely smart. Whoever was on the on that team, nice work. Well, so in addition to this, maybe we can back up just a little bit. So you’ve been doing a lot of open source work, including the I think the Astro JavaScript framework is probably the one that that you’re maybe most well known for. What was it about Astro that got you excited? I also really like Astro as somebody who really had to kind of be pulled kicking and screaming into the like we’re gonna run JavaScript on the server now. Astro, I think, is something that really kind of jibes with how I think about how the web should work in a lot of ways.

But what is it that kind of attracted you to working on Astro?

Matt Kane: I’ve I mean I’ve really liked Astro since I very first used it. And I think part of that is then it feels kind of old fashioned and back to basics that you are like you’re writing HTML. And it’s you can just write HTML and it’s kind of you have a bit of you can put some TypeScript up at the top and then stick some HTML up down below and it just it just works really well. And if you know HTML, you can write Astro and you could stick some CSS in there and it just works as you would expect, but is all nicely scoped to the page and it’s just I mean the developer experience for it is really nice and it’s it kind of I really like the way that it’s very simple by default.

So if you know you don’t if you start out with something simple, you don’t end up with a huge amount of a huge amount of stuff stuck in your page that you didn’t ask for, which you would get with a lot of other frameworks, like, you know, the most obvious being Next.js, because that’s the, you know, the big one at the moment. But the place that I worked before the framework I worked on before I worked on Astro was Gatsby, which was kind of notorious for that sort of thing, because it was very much a single page app thing, which did ship a huge amount of huge amount of JavaScript for anything and kind of Astro was pretty much the sort of antithesis of that, in that it’s very lightweight. It’s very nice and, you know, very enjoyable to work with. But it also had a lot of the stuff that I liked from Gatsby about the way that it was very much focused on the content and it was designed to give you very performant pages and was not primarily about building like highly interactive web apps and dashboards and things like that. So I liked it from that point, but then I just sort of felt that it was doing things a lot better. And so I, you know, I started contributing to it and then I then eventually became a core maintainer and then and like was employed by Astro. So that was kind of I’ve been spending a lot of time working on open source professionally, which is great, you know, which is, you know, fantastic.

Like I start since basically since I started working at Gatsby, which was in like to beginning of 2000, I’ve been working paid to do open source work since then, which is which is fantastic. Because then after Gatsby I was working at Netlify and then and then Astro now on that Cloudflare as well and I’ve spent the whole time working building open source.

Jim Ray: This kind of brings us to the project that you have been working on for a while at Cloudflare and just launched a 1.0. This is a project called EmDash. This is a project I when it launched I was personally very excited about my background before I kind of worked more on the tech side was in publishing. So I was I was super excited to see this. There’s a bit of a history, I guess, within Cloudflare of launching things on April 4th. Fool’s Day, is that right? And so was that what led you to launch kind of the beta of EmDash on April 1st of this year?

Matt Kane: Pretty much, yes. It was it was in that was kind of one of the early decisions that was made about it was I think there’s kind of it’s been a double-edged thing, to be honest. You know, on the one hand it got a lot of interest. On the other hand, I would say that good quarter at least of people thought that it was an April Fool and so we’ve you know, we had to go through quite a lot to convince people that it was real afterwards.

Jim Ray: Right.

Matt Kane: But it you know, it’s not surprising because it was quite a outlandish project when we first started it, you know. So it’s not surprising that people find it a bit unexpected.

Jim Ray: So talk about that outlandish list outlandishness a little bit. I went back and read the kind of the launch blog post that that went out on April 1st. One thing that I was really struck by was kind of how you positioned it. And it was basically like we’re gonna we’re gonna rethink what would we create today if we wanted to rebuild WordPress from the ground up. And you were very explicit about that. You said like, hey, this is WordPress, but your plugins operate in a secure sandbox. I believe you called it the spiritual successor to WordPress. And so kind of talk walk us through a little bit how you thought about the positioning of EmDash.

And then we’ll we can talk a little bit too about like how you thought about even starting this project to begin with.

Matt Kane: It’s ver was always very much framed around that. And the way that it started was I think, you know, it’s kind of connected to what we were talking about before, in that after the kind of the holidays, beginning of January this year, everyone was thinking about what these this new world meant, what the possibilities were and what we could do now that we couldn’t do before. And it was into that that I got a DM on a Sunday evening from Dane Knecht, our CTO. Now I subsequently found out that he sent that to me because he was sitting next to Matthew Prince, our CEO. who and talking about this and the this basically the DM said something along the lines of could you build a new WordPress? And that was basically you know, that was pretty much it. You know, the Dane gets to the point. You know, he doesn’t waffle. He gets to the point. Now what he couldn’t have known was that basically the entire Astro core team has been talking obsessively about building the new WordPress for years.

One of the things that Astro has always had is this feeling of that it’s kind of part of a CMS, but it is not a full thing. And there’s lots of CMSs that work great with Astro but it’s feels like a kind of m like it should be part of a WordPress and it’s very, you know, as I was saying, it’s got very good features in there for doing managing content and for handling content when you’re building the site on the front end. But in terms of managing the content on the back end, it’s you know, the stuff you get out of the box is markdown files, which, you know, we love markdown files. Agents love markdown files.

It’s not really a scalable thing for anything other than you know docs and a pretty simple site. So we’ve always talked about we should build a CMS. And at Astro, we talked about building a CMS for eight for you know for a long time and various people made various attempts at it and then everything. But building a serious CMS is a lot of work. And particularly if you’re building an open source one and not like you know, use it getting revenue from it. It was it was just not something that we were able to justify. But it mender when I got that DM from Dane I already had it all worked out in my head.

So it was like, yes, I’m gonna do it like this. It’s gonna use Astro. You know, I’d even got features that I’d that I’d been bringing into Astro with that sort of thing in mind. Not specifically about building a WordPress replacement. but about enabling that kind of thing within Astro. So live content collections, which are, you know, are things specifically designed for CMSs. And then route caching, which is another thing that is particularly good for things with like highly dynamic changing content like CMSs. So the kind of the pieces were all in place. And it was it was kind of at that point it was more a case of that it was finally possible to really do this.

And I then got this thumbs up from my boss’s boss’s boss’s boss to give it a go. And effectively an unlimited token budget. And so that was basically how I learnt to handle agents. You know, the this kind of thing of everyone how everyone who’s doing any kind of agentic coding has kind of learnt the ways that they like to do it with you know how they’re handling multiple agents and how they’re doing planning. and all the all the kind of the difficult stuff.

Jim Ray: Yeah.

Matt Kane: I spent a lot of time in January and February learning that. as so many of us did, but I also had this very specific goal. Well, that was in it was very specific in one sense, but also very vague in another. But what I did have that was extremely specific was a deadline and that deadline was 1st of April, because that was, you know, pretty clear that that was when it was this was going to be. So that meant that I had like a little bit over two months to build something that was twenty-five years old, you know, a replacement for. So with, you know, that had thousands of developers and I was to build it most of that time on my own in secret.

So it was it was quite a it was quite a challenging thing, but so s you know it was a it was a great thing to be to be challenged to do, but it’s it brought up a huge number of things that largely down to what the thing was that we were going to build. So it wasn’t so much that the actual building it was the difficult part, it was the whole product side of it that was that was the thing that was the real challenge. So because obviously WordPress is many things to many people, you know. And that was that was really the core of what we had to nail down to build this thing.

Jim Ray: I want to talk a little bit about building with agents. If there is a chief anxiety in the industry right now, it’s AI agents. And if you if you hang out in various parts of the Bluesky app, people have lots of thoughts and feelings about this. Our podcast is mostly aimed at developers or people who are interested in the AT Protocol. And obviously agents are just a huge change in how we work. And so maybe we can start with like what were some of the things that you learned during those two months kind of leading up to that April 1 deadline. I’m sure that there were things you had to unlearn from your 25 year career as a software engineer, things that you had to try out that didn’t succeed.

But I guess what were the things that that you maybe some of the assumptions that you started with that turned out to be good and then what are some of the things that you’ve had to reevaluate since then?

Matt Kane: I think the biggest thing that I’ve that I’ve kind of learned from this is that the code is the easy part.

Jim Ray: Correct.

Matt Kane: When you can just have something that’s just able to whip up a prototype in a few minutes or build a massive prototype in a in a few hours. the code isn’t the bit that you should be thinking about so much anymore. And I was very glad that very early on it became pretty clear to me that that’s that that was the case and that what I needed to do was spend a lot of time working on the spec. rather than spending a lot of time looking at the code. I think I’d kind of come from a good place there in terms of the lot of the open source work that I’d done, like with the approaches that we take to planning new features, which by their nature, because of being done in public with lots of people’s eyes on it needs a very well drawn spec, which so you know and Astro uses an RFC process, so we go through often months and months and months are before between a proposal first being created and anybody actually writing any code for it.

So I kind of started Converging on a process that’s similar to that. And obviously, you know, all kinds of software development uses specs for doing it f the thing that I found was particularly useful was spending a long time with the agent iterating on the design of it, well what it is we were going to build, you know, working through all of the questions that you would ask if you were a product manager, you know, what doing the research, finding, you know, finding what competitors are doing, maybe spiking out some experiments. It’s the sort of thing that I as a principal engineer I spend a lot of time doing anyway.

Jim Ray: Sure.

Matt Kane: I spent a lot of time doing that before writing any code at all. And then I then started to basically told the agent to work out a plan for doing it. And that part I didn’t really look at all. I just let it I trusted it to write a plan with work streams and you know, parallel work trees to work in and all the kind of stuff that’s now built into a lot of the harnesses, but wasn’t then, and then just let it rip and told it to go off and build. And I think that having it where it’s built around a spec means that you can do the bits that need the iteration and the it the kind of big changes can be done very easily at that stage because you can just literally just look at the design and think, oh that doesn’t make any sense.

And you can go off and build it and then you can throw it away and go back to the design and change that. And I think that that’s the big thing that’s changed for me is that you don’t spend a long time looking at the code and doing the do designing the features while writing the code, you know, doing using the code as a way of working out what you’re going to build. You kind of do that separately. And it’s not something that is a revolutionary. thing cause, you know, it’s kinda s how it’s supposed to have worked anyway. You know, you’re supposed to plan the things before you build them. But it’s just made it a lot easier to do the thing you’re supposed to do.

Just like it makes it a lot easier to write all those tests that you should have been writing.

Jim Ray: Right.

Matt Kane: And it means that you instead of being the slightly sloppy engineer that maybe lets some of those best practices slide. You can be the very strict Taskmaster that says in your AGENTS.md, no, absolutely, we have to have this very well spec thing and the all of these plans and all the right test coverage and all that kind of stuff. So I think that’s kind of the way that I’ve had to think about it is just kind of moving where the work happens, where the you know, where the iteration happens and where the experimentation happens.

Jim Ray: One thing that I think I’ve learned from working with agents and my work has not nearly been as extensive. Within our team internally, a lot of the work that we’re doing is kind of building out some of these tools and custom harnesses and things like that. But one of the big takeaways for me is that working with agents really does enforce a lot of the best practices that we have spent decades now iterating on and trying to refine. And I like that quite a bit, but it does it does kind of force you into a sort of a slightly different way of thinking. Are there things that that you were surprised by that that you thought would take longer or that ended up taking more time that you thought it would.

You know when you sit down, you get this DM from your boss’s boss and you’re like, yes, I can knock this out. Are there things that that ended up taking longer or are there things that you were just like, wow, I thought that was gonna take a week and here we are an hour later.

Matt Kane: I mean the bit that was the biggest initial surprise, which, you know, I think everybody has experienced now, is that I had something working within 24 hours, you know. there was a working CMS where I could log in and I could edit pages and publish them and all that kind of stuff was done within 24 hours. I’d spent a day working on the design. Working on the spec and the plan. And then I just sent the agents at it for f like four hours the following day. And that was basically the kind of bit that was made me think, actually this might work. And obviously it’s very different to what it was what it was then.

And so that that part of it has been the bit that was the bit that was so super easy. Now the bit that was really that was a lot harder was all the front-end stuff and the interaction with like the like a text editor, all of those bits that need a lot of manual testing.

Jim Ray: Yeah.

Matt Kane: And generally just the sort of front-end design as well. Because I mean it’s a lot better now, but particularly back then the whole front-end design stuff, it was just really not very good. We needed a lot more manual work on that side of it than anything else to for the you know the individual bits of the editor experience and those kind of parts to get the real polish on there. That was I suppose you know it wasn’t surprising that that took takes a long time because it’s always been something that takes a long time. But I think it supposed it’s a it’s a surprise because it had hadn’t been sped up at all you know, for from my point of view in terms of the work that I was doing.

So I was having to go through and manually do all of the testing on that side of things. So it meant it was a lot harder to do the iteration and stuff on that side. Now they are a lot better at it now. They’re better at being able to do that sort of testing and they’re also better at just doing front end stuff in general, but it’s still very much that there is a very kind of bimodal distribution of a lot of these things where it’s, you know, just amazingly good at s something and then other parts of it is just really just not worth using it for at all.

Jim Ray: Was there a thought that I look at so many websites these days, especially things like technical documentation, and I can almost instantly tell that this was something that was built up by Claude. And I try not to be too judgmental about it, especially I’m particularly excited when the words were not written by Claude, that there was clearly a human touch there. And I’m much more willing to forgive the overall UI and things like that. But over that time, were you able to see actual improvements in how the agents were able to build out the front end of things? And did you see their capabilities kind of growing in ways that maybe the back-end capabilities or were they both kind of in lockstep in terms of the capabilities that you were seeing?

Matt Kane: I think absolutely, yes. And the thing that made all of this possible was that, you know, in November the models got good enough to actually plan a large piece of project and build a whole thing. And that was the bit that was sort of saturated in that if your thing wasn’t super complex, it could just build it. And even if it was pretty complex, because you know, building a PDS, building a CMS, these are things that are pretty complex, but you can one-shot them, but they’re the sort of thing that if you knew a bit of you know, if you were a experienced developer you could do them with the help and it was able to do most of it itself.

What it wasn’t able to do at all, really, was tasteful front-end design.

Jim Ray: Right.

Matt Kane: Could not write prose at all. Terrible, terrible prose. Now, it’s got a lot better at the front end. Opus 5.5 is kind of, I think, a bit of a turning point there. It’s a lot better. There are very much lots of tropes of design that you will see everywhere. And you know, you will see it in a lot of the stuff that we’ve put out because, you know, the actual front end templates and stuff have not been the thing that we’ve been focused on making perfect and beautiful. We use Cloudflare’s Kumo component library for the for the whole admin side of it. So it’s kind of it’s gonna look like that for whatever it is.

So the actual admin thing is using a using the it’s all using TanStack and the components from Kumo. So the agents are perfectly fine at doing that. It’s all about just the kind of finding the edge cases and things on there. But in terms of making a site that looks anything that’s not really bland and generic. It’s not been very good at that until pretty recently. And in terms of prose, it’s still terrible, you know.

Jim Ray: Right.

Matt Kane: I know some people claim that it’s able to, you know, if you give it like thousands of words of your own writing it can sometimes write it well. But you know, I use it to generate like changelog blogs. That’s about the limit of what I would trust it with for writing anything. I think it’s it’s interesting that Cloudflare as a company is about as kind of about as AI pilled as you can get. But we now, you know, when we had our big birthday week last, you know, a few weeks ago where we did all of our big releases, including EmDash. we were basically told don’t use AI to write your stuff. You know. It’s just not good.

And it’s it doesn’t show any signs of getting better. So I think, you know, the writers the writers are safe for now. Which is ironic, you know, these are supposed to be large language models and human language is the thing that they seem to be most the seem to be worst at, but yeah, I think that’s kind of where it stands at the moment.

Jim Ray: One place I’ve landed in my own kind of personal ethics on these things is if I’m writing something that I just need a computer to interpret I’m happy to let the robots do that if I’m writing something that I need another human being to interpret, whether that’s the front end of a website or some actual code, then I want to be pretty seriously involved in that. It when it’s like prose writing, I want to have touched every word. The other thing I think is I think human beings were just so much more malleable. And so we very quickly, like everybody knows, even if we can’t identify them, everybody knows the LLM isms these days. And to the point where I have instructed my agents, like, stop talking like that.

And I have a whole dictionary of things I don’t want them to say. And I think that’s just gonna be true. I mean, it’s been true for the entirety of human history. It’s gonna be true going forward, where it’s just like we as a people are much better at adapting and this I guess this is why I’m not super worried about LLMs taking all of the like creative jobs because like as soon as that happens, we’re gonna adjust as a society and we’re not gonna want that anymore. We’re gonna want something else. I want to talk about the atproto bits because I think those are particularly interesting and compelling. There’s a lot of like atproto native pieces under there that if you know where to look, you can find and activate.

But the thing that I think is most interesting is the fact that you have a plugin registry, and that plug-in registry is itself based on AT Protocol. But you wouldn’t necessarily know that if you go to the registry, which I think is awesome. And so I’m curious, like, can you talk a little bit about some of the decisions that went into one, building a plugin registry. Obviously, one of the things that makes the WordPress ecosystem so formidable is it has this massive 25-year plus history of plugins and extensions and things like that. So that was obviously something that you all wanted to include as well. What were the decisions that went into saying like but you know what, we’re going to build this registry on the AT Protocol and make it something that brings along some of the advantages of the protocol as well.

Matt Kane: One of the first things that I knew was that plugins were going to be absolutely critical. That I think probably the biggest thing that is behind the success of WordPress is the plugin ecosystem. And because WordPress plugins are just incredibly powerful and you can a lot of them are kind of almost mandatory that the core they’ve gone to the extent that WordPress there’s a lot of stuff that should really be in the WordPress core that requires plugins. But at the same time the fact that it has this incredible powerful plugin ecosystem and you know, entire multiple businesses that are built entirely around just shipping plugins, I think is like an absolute critical thing. But we, you know, there’s no way we would be anywhere near their level of the number of them, but we want to at least be able to support it.

It was always going to be a thing that I needed to do. There were kind of two really big problems that the WordPress plugin ecosystem has. One of them is the security side of things. Because of the architecture of WordPress and the fact that it’s all, you know, it’s all just one big PHP app, plugins basically have got the keys to the kingdom. They can any plugin you can store install can do basically whatever it wants it’s all running in the same process. It can read to you and write to your database. So it’s not really surprising that like it’s well over 90% of all the vulnerabilities found in WordPress are through plugins. So, you know, it is a bit of a wild west out there.

So you have to make sure that you really trust the plugin providers, that was just not something that we thought was going to be viable in the you know the system that we’re going for now. So that was that was where I’ve kind of my immediate thought was we were going to need to do sandboxed plugins. So the primitive that we’ve gone for is that they run inside what they’re called a dynamic worker, which is where it runs on Cloudflare. But you can also it works in Node as well, where it runs in a separate isolate process. But it g basically gives a very locked down kind of sandbox where the code can run, but it doesn’t have access to any external resources apart from the ones that have been passed in specifically.

So it doesn’t even have raw network access or anything. It just gets access to whichever capabilities it’s declared. So it’s a bit when you install it, it’s a bit like installing an app from an app store and it shows what the capabilities are for it. But it’s like in the it’s even more locked down because it you know it can declare that it’s only able to access certain domains for it. example. All of its data, you can it can be segmented. And so all that was one of the key parts for it. And that’s been, you know, one of the bits that were most important. But then the other part of it is the actual plug-in marketplace and the registry.

Now this has been a big problem with WordPress, and anybody who’s followed WordPress at all in the last few years will have seen some of the drama that’s gone related to the WordPress plugins where you know where there have been fallings out and plugins have been taken over and all of this kind of stuff that is generally just not the sort of thing that you want to build into your plugin registry from the start. Obviously also in the back of our mind was all of the issues that the JavaScript ecosystem has had with supply chain attacks on NPM. and the Shai-Hulud worms and all these kind of things that if we’re building something from scratch, we want to be able to address all of those things from the start.

When we f when I was you know first designing it, it was just going to be in a like a normal centralized registry. It was going to install stuff. the plugins downloaded and s cached locally and then run inside the dynamic worker or inside the workerd process. But I very quickly thought I don’t want to be running a plugin registry. I don’t want to be the I don’t want to decide now that I am going to run the central registry for this for the end until the end of time and I don’t think that people are gonna want that. They’re gonna want to be able to have something that solves all of those problems.

And I was already building stuff on atproto, as we’ve you know, as we’ve talked about, but it became clearer, the more I thought about it, that the approach was going to be the best approach. And I was certainly, you know, I was inspired a lot by the kind of the people that the work that the people on doing npmx had been doing. But the thing that became clear from that was that the it needs to have its own registry. It’s like having a front end is great, but if you want to make things actually different and fix the problems. You need to have your own registry. So that’s kind of where I ended up with atproto.

It’s kind of I think possibly I kind of interrogated it harder than I would have done if it wasn’t for if I wasn’t already building stuff on there, because I was like, am I just being biased? Do I just like atproto? Do I just like the people I was hanging out with in Vancouver a few weeks ago? And if I got fully atproto-pilled and going for it automatically, the more I looked into it, the more it made sense. I did spend some time looking at other options, but it was basically just kept coming back to that.

Jim Ray: That’s great to hear, and I think it speaks well of the ecosystem, because there are some really great people and we did have a pretty fun time in Vancouver. But it’s also nice to hear that all of these kind of big heady, for lack of a word philosophical topics that come up from time to time actually can affect how we go about building these things. I’m curious, what was the response internally? When you floated this idea of, hey, instead of having a centralized registry that Cloudflare potentially would control, we’re gonna build it on this kind of wacky decentralized protocol that nobody would control and anybody could clone or take ownership of or was there any pushback on that or were people pretty into the idea for the for the most part?

Matt Kane: I think it fits very well with the ethos of Cloudflare in general, to be honest. I didn’t get any real pushback on it at all. I think we very much always wanted to be the ones that build the open ecosystem. You know, we’ve we want to like participate in protocols and we want to provide the plumbing and give people the tools and we don’t want to build the marketplace. We want to build the thing that you build the marketplace with.

Jim Ray: Sure.

Matt Kane: So atproto fits very well. atproto works particularly well with Cloudflare is that it definitely fits in a lot of what our ethos is. So it very much made sense and it also very directly addressed. one of the key problems that people had with the WordPress ecosystem. So it certainly made a lot of a lot of sense there. It was not a not a hard sell in terms of using it under using it under the hood.

Jim Ray: One thing that I’ve noticed is that you have gotten a little bit of recognition from the WordPress team. I saw that Matt Mullenweg himself was tweeting about this over on the other place. And I think you mentioned that you had to resurrect your long dormant Twitter account to respond. What has the response been broadly from the WordPress ecosystem? I know I know a bunch of people in that ecosystem from my time working in agencies and design spaces and things like that. I know a bunch of folks that are excited to have an alternative. What has the response looked like from kind of your end of it?

Matt Kane: Honestly, it’s been a lot more positive than I feared. I did I did expect there was be quite a bit of pushback and I think the terms in terms of the kind of the real heavy responses from some of the people that you would expect, it’s not actually been as much as I thought. And a lot of the things that I’d been building not wanting to kind of put too much that would be seen as being anti-WordPress because, you know, a lot of people really like WordPress. And I very much didn’t want to be going in and saying, hey, WordPress sucks. This is what you know, you come over and use this use this JavaScript thing instead.

I very much didn’t want to do that. And I think possibly I over corrected. There is a reason that we’re wanting to do something that is emulating WordPress, which is that WordPress gets a lot of stuff right. You know, there is a reason that it powers like there is a lot of stuff that is good there. But at the same time, the thing that surprised me was that there was a lot more appetite for making big changes than others than maybe was expected at the time. So I think that has come has been one of the things that I’ve kind of taken from it is that among WordPress users, there is a huge amount of appetite for something that is going to be an alternative that does the things that they love about WordPress or even just the things that they like about WordPress, and doesn’t have all of the problems that they that they don’t like. And you know, we’re not gonna we’re not gonna do everything for everybody, but I’m hoping that we are listening to them enough to be able to have the, you know, the right kind of experience that people are looking for. A lot of that has just come from the fact that we’ve built this fantastic open source community. Which one of the that has been the sort of the thing that’s come from this is that suddenly there’s a lot of people coming from the WordPress ecosystem who are now taking part in the EmDash development in the open source, which has just been fantastic to see.

Jim Ray: And I should also mention we have we’ve got a great relationship with the WordPress team. We’ve worked with them on things like the standard.site plugin. And obviously we have kind of a direct interpersonal relationship with M2, with our CEO. I really like this idea of the kind of push-pull nature. And the best of open source is you see the good ideas that are happening. There’s a world in which I think especially some of the things that you’ve done on the plugin side, whether it’s the security sandboxing or things like building the locked open plugin registry, I think we would all love to see versions of that, not just in WordPress land and EmDash land, but across the broader ecosystem, because I think there’s a lot to be learned from that.

Matt Kane: I’m hoping that we’ve got the opportunity to do these experiments with the way that this is being built. Because of it being a brand new ecosystem, we aren’t restrained by building something that needs to be compatible with fifteen years for NPM or 25 years for WordPress with all of that kind of baggage, we can start from scratch and we can experiment with these things like, you know, having this atproto thing and, you know looking at whether we’re going to be able to use permissioned data for paid plugins and these kind of things where we are able to try all this stuff out. And Hopefully it’s designed in a way that we can also then feed back to the rest of the ecosystem and have people using in some of the things that we’ve learned as ways to inform other kind of parts of the protocol for people who wanting to use it for similar kind of purposes, whether that’s distributing software or distributing it.

Anything really, you know, it’s this registry type use case is certainly broader than just software.

Jim Ray: I wanna kind of finish up here with talking about the road to 1.0. So you were talking about the Cloudflare birthday celebration I was really grateful that y’all published a blog post that collected all of the blog posts because I was having a really hard time just following all of the releases. It was really incredible. Congrats. For I mean it’s an organization that ships like that at that velocity is not an easy thing to build for sure. So on April 1, you launch kind of the beta of EmDash. And then it wasn’t until a couple weeks ago that the 1.0 comes out. And so that time is honestly longer than it took from when you got the go-ahead, you got that DM to shipping the beta.

What was that period? Like was it was it more that you’d kind of like stepped back to look at other priorities and then you kind of came back into it? Or were you just kind of grinding on the 1.0 that whole time and you knew that like, okay we had we had our April 1 announcement and now we’re gonna have our October announcement. What was happening in that time period?

Matt Kane: It was working faster than ever, I have to say.

Jim Ray: Oh wow.

Matt Kane: Our feet definitely did not come off the gas. And I think the thing that changed massively was the open source community. You know, we’ve got we’ve had over two hundred external contributors now contributing to the project we’ve got like over a thousand people in our Discord. Now we’ve got like we’ve got multiple people from ex outside of Cloudflare who are now who are now maintainers. So the big thing that happened was that people were using it, people were feeding back what was broken, which initially was a lot. people were also telling us what they needed because I have, you know, I’ve used its CMSs for quite a lot, but TK who was who was like doing the product side of things, you know, he came from a background in the media.

But each of us had only got our own experiences of it. And the thing about, you know, a CMS is it’s used in so many different ways by so many different people. So the thing that has been so useful is having hundreds of people, thousands of issues and PRs and everything giving us feedback on what we’re doing wrong and what we’re doing right and what’s missing and what’s great and all that kind of thing. We have been just working at a speed faster than ever before because of the huge number of PRs that we’re having. And I think the thing that the thing that’s been quite amazing though is that even though the majority of these PRs will have been written with AI assistance, virtually none of them are slop.

We are getting high quality PRs from people who are using EmDash. We’re not getting these drive by slop things that a s lot of projects are having to deal with and that that are causing them to have to close down their incoming PRs. We are very lucky that we are getting good PRs that are fixing real issues that are following our PR templates and are just generally doing what we need. And we use a lot of automation for helping us review these and we have you know, we have bots that do all of the first pass reviews on these things, because otherwise it would be impossible. But at the same time, you know, that is the big thing that has been the like big pleasant surprise is that we’ve managed to build this really vibrant open source community super quickly and that’s I mean that’s the only way that we’ve managed to build something that is so mature in such a short period of time.

And it’s the fact that this thing is now able to run the Cloudflare main Cloudflare blog and you know moving cloudflare.com over as well, the main Cloudflare site. because it’s able to handle it because we’ve got so much good, you know, useful feedback and so many people contributing.

Jim Ray: That’s incredible. Do you have any recommendations for folks that might be a core contributor or managing an open source project for avoiding the kind of slop PRs that I think we’ve heard so much about. that do seem to be kind of endemic to certain projects.

Matt Kane: So there are a few very specific things that I recommend. One of them is having a very good AGENTS.md in your repo and when you’re writing it, thinking of it as being writing it for the agent that is being worst controlled by a user. So it is it is very when you’re sort of developing, building something yourself, you kind of make the AGENTS.md thing as a something that you’re writing for your agent.

Jim Ray: Sure.

Matt Kane: Things that your agent gets wrong or whatever. But when you’re doing it for an open source project, you are writing it for the agent of the person who is least in control of their agent. If you look at the EmDash AGENTS.md, it’s very prescriptive about things that need to be done. And a lot of that is down is things like the procedures of the repository for things like PR templates and what the test coverage is and things like that. Because I find a lot of people saying, oh yeah, no, but these AGENTS.md things, they don’t help them write better code or you know they’re not they’re not as they’re not good. It’s much better to just let the agent read the read the repo and it’s like, well yeah, maybe for you, if you’re doing it well, but the AGENTS.md that I’m writing is for somebody who’s pointed OpenClaw at the repo and said why doesn’t this work?

Fix all the bugs, you know, gone and opened all these issues. So we’ve got lots and lots of rules in there about what agents are allowed to do, what agents are not allowed to do. And every PR has to have an agent, an AI disclosure thing on there that they have to check the box and say what model they are and harness they are. Those sort of things make a huge amount of difference. Now on top of that, you have to use all of the kind of automation for just keeping control of the quality. But the other is that we’ve just got a really good review bot now, which is one that we’ve built ourselves.

But it does a really detailed review of every PR when it’s first opened. The users are really good at it, read really good at responding to it. But what this means is that by the time a human first reviews it, it’s already been through all the realms of the kind of the annoying back and forth stuff. And it’s at the stage that a human can actually just review it as from a higher level and be able to say, okay, no, this is building the wrong thing. You know, this is coming at it from the wrong angle or whatever. Because most of these things have been built with AI assistants, you don’t need to feel quite so bad about saying, sorry, no, I’m gonna close this PR because that’s you’re an open source maintainer for a long time and it’s horrible having to close somebody’s PR when they clearly put a lot of work into it.

I don’t think it’s quite so bad when it’s, you know, a lot of work has been put into it by Claw Claude or Wayne.

Jim Ray: Sure.

Matt Kane: It does mean that really long hard work part of it is a lot of that is taken out. The agents are good enough to do the kind of baseline level of all the code review. So that you know, that makes things a lot easier. And we’ve got bots that run on the issues as well. So when a new issue opens, we have a bot that will triage it and try to reproduce it. And if it can fix it, it will open a PR and ask the user to try it out and you know we’ve got a whole workflow that goes through from that which was inspired by the Astro project, which has got something very similar and has used that to get down to zero issues on the Astro repo, which is pretty amazing.

Jim Ray: That is amazing.

Matt Kane: Where so basically almost any new open newly opened issue will get triaged and reproduced and possibly fixed by an agent within, you know, as soon as it’s open. So we use that to take the heaviest parts of the workload off. And I think that’s the only way that you can really cope if you’ve got anything that gets any volume of PRs or issues.

Jim Ray: So I think one of the things that’s most disorienting for me about this time that we’re living through right now is being able to predict what’s going to happen on any kind of a timeline. And so Given that, what does the future of EmDash hold? Whether that’s next week or two quarters from now, as you think about the future success of EmDash, how do you think about what that looks like?

Matt Kane: I mean this is something that we’ve been thinking a lot about at the moment because as a project that has just gone to 1.0 and has just also brought on our first external core maintainers, it’s something that we’re having to think a lot about. And I’ve kind of said that we want to slow things down a bit and be a bit more thoughtful because we have been on full sprint 1.0 mode. And a lot of that has come down to I want to kind of codify a lot of those principles that I was talking about before, which were about the way that features are implemented with planning things in advance. And so one of the procedures that we’ve that we’re putting into place now is that every feature needs a design PR first to work out the spec because it’s much easier to iterate at that point than have somebody open a PR for a big new feature and then everybody spends the next month discussing different the way that it’s implemented in it while hundreds of PRs and landing simultaneously and constantly conflicting it.

So this is a new policy that we’re being more gonna be more strict about that. So it’s kind of working out where we want to be in a bit more of a thoughtful way. Obviously a lot of the stuff we’re doing is just, you know, making things more stable and making sure that it’s reliable for more different use cases. A lot of it is at the moment as well is just seeing how people are using this. for real because pre-1.0 people lots of people were using it, but they were using it by net their nature where people were a bit more experimental and a bit more open to trying things that were that were pre-stability, shall we say.

And now it’s you know we’re wanting we’re talking to more people who are trying it, who are expecting the stability of a of a 1.0 project. So the thing I was coming to before where I was saying, you know, WordPress is a lot of things to a lot of people. a lot of what EmDash has had to be is working out which bits of that are the bits that we want to meet. But also as we are now maturing beyond just being a WordPress alternative we are kind of finding our own way out there and see what things we should be doing that aren’t just something that we’re doing to replace WordPress.

Jim Ray: It’s a very familiar story as I work at a place that is known for being an alternative to certain social networks and now we’re really trying to figure out how to how to branch out. Matt, I can’t thank you enough. I’m, as I’ve mentioned several times. Personally just really excited about the EmDash project. Congratulations again on the 1.0. I actually had to check. You’re up to 1.2 now. Is that recording? Yep. And I think by the time this goes live, there might be even another dot release. So really inspiring to watch this work. I know you’re open to contributions. I’m sure folks in the atproto land are watching this as well. So really amazing work.

Matt Kane: Well, thanks a lot for having me and it’s great to have contributions from people who are in the atproto ecosystem because they kind of I find that they’re both they both get the this sort of ethos that I’m going for, but generally also just I just like working with them because they, you know I think anybody who gets who’s interested in something like this seems to be on the same sort of level as what I’m doing. So I very would very much welcome contributions from people who are atproto Knowers. So do you know just come to emdashcms.com and find all the info there.

Jim Ray: Amazing. You heard the man. Get to it. Thank you again so much, Matt.

Matt Kane: All right, thanks.