EmDash: The WordPress Successor That Fixes Plugin Security

Plugins were kind of one of the most important things that we needed to get right, but equally, you know, we know that plugin security is one of the biggest issues with WordPress. I mean, it's like 95% plus of security vulnerabilities in WordPress come from plugins. So I was trying to think of a way that we could do this that was going to be at least more secure than WordPress, if not completely secure. And then suddenly I realized that we had in Cloudflare this product that was perfect for it. And that's in the dynamic workers. Hello, everyone, and welcome to This Week in NET. It's a special April episode. It's actually about an announcement that we did on April the first, but it's not an April Fool's joke. It's actually a very much a full fledged product. I'm your host João Tomé based in Lisbon, Portugal. And for that, I have two Matt's based in the UK. Hello, Matt Taylor. And hello, Matt Kane. How are you? Hello. How are you? Good. Thank you. You're both in the UK, but you're in different places, right? Yeah, I'm at home. I'm in London, about 20 minutes in the office. Matt is a bit further away, I think. Yeah. More north or south? I'm west. I'm near Stonehenge in the countryside. That's a beautiful area. Oh, well, a big announcement we had the week that we were recording, and it was an April 1st announcement. And for Cloudflare, that's not an April Fool's day specifically. That's actually a real product, fun product, really important product day. We launched our public resolver, Quad One, on that day in 2018. And of course, there's a bit of history even in the past in terms of technology. Of course, Apple celebrated its 50th birthday on April 1st this week as well. And even Gmail was launched also on that day. What can we say to folks about this announcement, introducing MDash, the spiritual successor of WordPress that solves plugin security? What is the main take, really? Well, I hope that this can be as impactful as Gmail. I'm not really sure whether that's going to be the case, but hey, you got to swing for the fences or whatever they say. Yeah, I mean, as you said, this MDash is the, we call it the spiritual successor to WordPress. So it's not a rewrite of WordPress or a port. It's a new CMS that's built with the same philosophy as WordPress. It's designed that if you like WordPress, we think you'll love MDash because it follows, we tried to bring the good bits of WordPress because we like WordPress. WordPress is great. WordPress has done, manages to scratch an itch for millions of sites out there. So we wanted to do something that captured that part. But then equally, I think most people who use WordPress can recognize that it's got drawbacks. And if it was built today, it would be a very different thing. And so that's what we did. We built it again today and it has turned out to be different. But at the same time, the idea is that it would be still familiar for people who are fans of WordPress. And Dane, our CDO actually said yesterday on Twitter that WordPress is actually an important product and we're not replacing WordPress. WordPress will be around. This is another option with a different set of skills and possibilities really, but this is not to remove WordPress completely. Exactly. WordPress has a lot of fans and has a lot of history, has an enormous community who've been dedicated to it for many years. It's got thousands and thousands of plugins and themes. That's not something that's going to disappear, not overnight, not over several years. But I think the thing that we realized with MDash is that there's an entirely new community of people who have been kind of growing up on the Internet in an entirely different space. When I was young, WordPress was the thing that you would use and you would FTP its little file folder up to your little VPS or something and you'd get your website going. But you can't run WordPress on a lot of modern infrastructure that people are signing up to now as the first place they host their sites. So I think there was a real gap to build something that's both full stack, so you get the entirety of the site, the CMS and the front end, but is deployable to places like Cloudflare. One of the things that I found really interesting, and I used WordPress many years ago especially, is first there's a lot of complexity if you want to do stuff. So there's that. You need to select many things and think about many things, even when you want to do something simple in some way. And the other thing is it seems a bit targeted for you to spend money as well, which is something I never liked too much on about WordPress. If I want to do something a little bit more cool or to stay a bit more longer in time, the costs were always a bit there to do something relevant. Yeah, I think there's some interesting things in some of the architectural decisions that WordPress made early on, which were very sensible for the time, but have kind of become prohibitive or like methods for extraction from the user as time goes on. Just think about media space, for example. There's more media on the Internet than ever before, but a lot of WordPress hosts are going to be charging you based on the amount of storage that you have with them. Part of the kind of rationale for that and why that makes sense with WordPress, even though the hosts may be doing something different, is that WordPress is built to run on your local file system. And when you upload an image, you are uploading an image to a WP content uploads directory that exists next to the code. And that's not how software is built nowadays, right? You would upload to R2 or S3 or some kind of blob storage system like that, and you would reference the file via a locator. And that's how, of course, we've built Emdash, right? So effectively you get unlimited to the degree that you're willing to pay for it. Storage associated with your site that has absolutely no relation to the cost that you're paying to your host to maintain the site itself, right? You can separate those two things entirely. So I think there's a lot of little things there, little like tweaks that effectively mean that the way Emdash is built means that it can operate at much greater scales, much more efficiently than WordPress is able to. So a lot of the things that are the complexity and the cause of the complexity are also the other side of some of the strengths of WordPress. And a lot of that comes down to the plugin system. And that is something that people love about WordPress, is that there are a huge number of plugins out there. But at the same time, that has kind of led to a pressure to not include things in the core that, in general, everybody needs. So things like SEO and forms and so on are the sort of things that everybody really wants. So these are things, the fact that these things are, that need to be installed by every site, and in many cases need to be paid for, is a thing that's kind of in conflict with the best kind of user experience. What we try to do is include just the right parts into the core of Emdash that are the sort of things that everybody would need. You know, SEO comes out of the box and, you know, you don't need to do a plugin to do custom fields. So, but at the same time, we want to make it easy to extend it where it does need to be extended and do it in a way that is not too complex and can be done easily. Makes sense. Before we go into some details, some cool details, to be honest, why not also explain a bit of your experience? You have both a great experience in different projects and different things. Can you give us like a very quick run through of your past that actually led you here to this project? Matt, Taylor, if you can. Sure. So I have spent, before I joined Cloudflare, the last 10 years of my life working at various national media companies in the UK. So I worked at the Times of London, the Sunday Times, The Sun. I was at the Financial Times before I moved to Cloudflare. And a lot of that time I was working in CMS and working with content management and all the various challenges that evolve from publishing at that kind of scale. So I really know a lot about the challenges that WordPress presents and is presented with when you're trying to do that kind of thing. And all the various kind of intricate bespoke systems that exist in this world. So really, really invested in what MDash can do to transform this area. My experience comes at it from another angle because I am still, I'm currently a core maintainer on the Astro team and MDash is based around the Astro web framework. But I also previously was on the Gatsby core team. And so I was involved in both of those. I've been involved in integrating the web frameworks with CMSs and Gatsby in particular had very deep integrations with WordPress. And, you know, we were on the, we worked together with the teams behind WP GraphQL, for example. So I've got quite a lot of experience in seeing the headless CMS side of things and using WordPress and other CMSs in a headless way, which has helped me get the perspective on the way that that could be made simpler because, you know, a headless CMS is great in many cases, but it's also a lot more complex to deploy than deploying the famous five minute install that you can get with WordPress because you have to create effectively two sites that you're maintaining and deploying. And this is what we tried to get away with and get away from here is we wanted to be able to have something that was as easy to deploy as WordPress or if not easier, but at the same time has the powers of the modern web technologies built in. That's actually a good segue because for one of the things we always like to do in this show, in this podcast is understanding how things came to be, like the initial idea and hey, who started it, how many months it took. Sometimes we had Vinext that was done in one week with AI in a sense. Of course, there's in many of these projects, there's a whole project before that, that actually feed into the project that we announced. A whole work done before sometimes, the Astro team, for example, that is actually making this possible in a way. Can you explain to us a bit the process of actually wanting to do this and how many steps it took in terms of months and teams? Yeah, sure. This is something that the Astro community and I and the Astro core team have wanted to do for a very long time, but we've not really been able to devote the resources to it because it is a major undertaking. WordPress is 20 years old more and you don't just replace that thing in a weekend. I was discussing this with Dane, our CTO back in January. He was talking to me, it's like, how could we get WordPress working? Obviously, I jumped to that because I immediately had been thinking about this for a long time. This is something that I'd put a lot of thought into, and I'd even been building parts into Astro that were designed specifically for this sort of use case. In Astro 6, we launched live content collections and we launched root caching, which are both things that are designed to help CMS use case. So, I was immediately thought this is how we would do it, and I knew that this was going to be the approach. But the difference this time is that we had the agents to help. This is something that, well, you mentioned VNX was, you know, another project that was another kind of audacious attempt to replace something else. This is very interesting, the contrast between the two ways that we did this, because both of them were ones where we threw a lot of agents and a lot of tokens at it. But VNX was one where it was a deliberate attempt to replace an API. So, it was very closely scoped and it was able to run against a test suite and the agents were able to iterate through it. Whereas this one was much more loose in terms of the definition of what we were building. We were very deliberately not trying to do a direct port of WordPress. We, you know, something that we didn't think would make sense. It was not going to be a thing where you would do a drop-in replacement. The idea here is that we wanted to make it conceptually similar enough, specifically so that agents could do ports. You know, that was one of the initial things there, was we were thinking we wanted agents to be able to port your site or your theme or your plugins over from WordPress. So, the approach that we took on this is that, starting in January, I spent a long time working out the specs for this. And, you know, I spent several days just on the first drafts of the specs for what we were going to build here. And that was then before we started throwing the fleets of agents at it. And that has kind of been the approach that we've taken from all the way through now, is this cycle of writing the specs, iterating on the specs, and then sending the agents to them. And then, like, after that, going through multiple cycles of security reviews with agents. So, it's been while VNext was something where there was, it was like first version in a weekend and then shipping it a week later, which was like a kind of, you know, something that really blew my mind. That actually happened in the middle of the development of MDash. I'd been, when Steve, who's my manager, did, started work on VNext, it was, I was already several weeks into working on what became MDash. So, it was like I was seeing him shipping something in the time that it was taking me to iterate on a single feature. So, I think this is a thing where it's like in absolute terms, this wasn't actually that quick. You know, I've spent nearly three months working on this thing now. Whereas, but at the same time, it's three months where it was mostly me. I mean, aside from doing the actual, the coders mostly been me and the agents. So, it's just the fact that it's something that while it took several months, it's something that would have otherwise taken several years. So, that's the main difference. And it would have taken several years with a full team of people. And I think it's a very interesting example of the different ways that you can use agents for building software. You know, one of them is the very much, the extremely rapid kind of build out against a spec and throw all the agents at it in one go. And the other is the making use of the agents to be able to build something that would have taken a very long time in merely sort of a medium amount of time. So, it's been, you know, it's been quite a learning experience. And I think it's honestly not something that we'd been able to do four months ago. So, it's certainly something that I've learned a lot from. Really interesting, really interesting. Although also different projects in terms of what they want to achieve. The VNAC was also a proof of concept in a way, trying to see what we can do in that much time with agents. This is a bit different. This is a more finalized thing as well with a different purpose and with WordPress behind that gives, it's like 40% of websites use WordPress in a sense. That's a lot. So, it's a different project as well in that sense, right? Yeah, absolutely. And I think the other thing to think about here is like, if we were to announce or we want to build a CMS with you on Cloudflare, how do you want that to work and try to build a community from scratch with nothing to show for it and just an idea? You would have to invest over a year into building that thing because no one is going to join you on that journey. And the fun thing that we can do now with this is we can kind of have an opinionated take on, well, we want to build something that's like familiar to people in the way that it looks and operates, but is kind of architecturally built very differently and get something that does that as a demonstration that can be the basis for them people to open PRs, build a plugin, experiment, see how it works much, much faster than you would have been able to otherwise. So, these kinds of things, you can very quickly get the flywheel rolling much faster than you could previously. Today, I've seen people release plugins and open PRs to change how it works, which is awesome because it starts to also give us the feedback that we need to learn from our original opinionated direction. Where do people want to take this? What kinds of things do they want to build with this? How can we best support that? Makes sense. One of the things that you already mentioned in a way that plugins are securely sandboxed and can run in their own isolated via dynamic workers. That part, it's also something that is important in this project in terms of difference, right? And it goes back to the ecosystem, the Koffler ecosystem, in this case, workers and developers, but the ecosystem is there also to support making this a bit more resilient in terms of those plugins and what they can do in security in a way, right? Yeah, I mean, it was an interesting kind of moment when I'd been... Obviously, the plugins were kind of one of the most important things that we needed to get right, but equally, we know that plugin security is one of the biggest issues with WordPress. I mean, it's like 95% plus of security vulnerabilities in WordPress come from plugins. So, I was trying to think of a way that we could do this that was going to be at least more secure than WordPress, if not completely secure. And then suddenly I realized that we had in Cloudflare this product that was perfect for it. And that's in the dynamic workers, which, you know, they were mostly used for being able to execute code that was written by agents securely. So, it allows you to dynamically create code and then run it in a sandbox worker. And you've got very granular controls over the way that these things can execute. And I suddenly thought, wait a moment, that would be absolutely perfect for this. And, you know, I wasn't totally sure whether it would work. And so, I got the agents to spin up some prototypes for it and it worked perfectly. So, this was immediately this light bulb moment of what I think it took this to another level of what this was going to be able to achieve. Because I think that before the main thing was that we were thinking, you know, this is a way to bring modern web type technologies forward. We'll be able to do something that's easier to deploy and we'll be able to scale to zero and effectively infinity in both directions, which, you know, the serverless thing. But this ability to solve the plugin security problem suddenly appeared. And I realized that that was going to be the most compelling thing in many ways, because of the fact that the security is so much of an issue for WordPress. So, I think, you know, we say solve, it's going to still within a particular scope and then certain types of plugins do need to be installed as a node module. But for the kind of plugins that very often end up having, you know, the biggest blast area and taking down your entire site, this does solve the vast majority of those kind of problems. Because a bad plugin cannot do very much at all. It's not going to take down your whole site. It's not going to read your entire database and it's not going to start crypto mining on your servers. These are all things that it's not able to do. It's very much fully isolated in terms of the permissions that each plugin has got. And it can't stamp all over the storage of other plugins or of your core, even if you do give it the widest access controls. Yeah. And a lot of WordPress plugins that have some of the highest scope vulnerabilities, that vulnerability ends up being a way to create an admin user or directly modify the database in that kind of way through which then the aggressor gets in. And I think in the production of some of the work we were doing for this, we were looking at, okay, what are recent plugins that have been compromised that we could look at from the perspective of how emdash works? And one of them that had this exact vulnerability, you know, admin user can be created, was a plugin that effectively allowed you to run workflows off the back of actions happening in your systems. An event gets triggered, a post gets published, a post gets saved, something like that. And then another thing happens off the back of that. And I think Matt, from what we've built, that's possible today in this sandbox environment, right? You've got hooks that you can trigger events happening off of, and you know exactly what those events are able to do and what web addresses they're able to contact and what other actions they're able to take. So this plugin, were it in emdash, would not be able to be compromised in the same way. Absolutely. You know, you keep these, the access that they all have is completely scoped and those are exactly the sort of plugins that these sandbox execution is supposed to... And it's audible as well, those plugins, in a sense, because of that. So that's important, right? One thing, actually, it's open source and MIT licensed. Why is that important and how can actually that be part of the ecosystem, really? I think, you know, one of the key things about WordPress is that it's published under the GPL license. And that's what is known as a copy left license, which means that any derivative work has to be published under the same license if it's distributed. Now, I am a great believer in open source. I've been working in open source for the majority of my 20s and I want to encourage open source. And I think that the GPL, in many ways, has been a great success. You know, the greatest piece of open source software out there, the Linux operating system is GPL. But at the same time, the GPL license is a big problem for a lot of enterprises because of the fact that it has this viral nature, as they call it. And enterprises have to be extremely careful to make sure that they're not mixing their GPL code with their own code, because it then forces that code to adopt the same license. And this is a problem because, you know, if you want to release something as a GPL, then that is great, but it should be something that you make a specific decision to do. So, I was very clear from the beginning that I wanted to be sure that this was not a derivative work. Because it goes to the extent that even every WordPress plugin and theme has to be GPL licensed, just because of the way that it integrates with the WordPress core. So, I was already not planning to make this a direct port of WordPress, because from the reasons that I said before, in terms of, you know, conceptually, it didn't make sense. But I also wanted to be sure that we had the plugins separate enough that people would still be able to use their licenses freely. And I have to say, the amount of work that went into making sure that we could make this carefully MIT licensed very much vindicates the reasons why we wanted to make this MIT licensed. You know, coming at it from our own internal policies as an enterprise and the amount of time that I spent speaking to lawyers over this, I think this is very much released in a way that is designed to be as flexible for both every end user and for enterprises who have these kind of policies. You know, if people want to write GPL licensed plugins, then great, that's fantastic, but they need to make that choice themselves. And I think that many, you know, some people will, but some people prefer the flexibility and kind of legal peace of mind that you get with a license like the MIT, where, you know, the really realistically only requirement in there is that you give credit. So, I think that that has become the de facto license for a lot of, for most of the web ecosystem, precisely because it is simple, easy to understand and not, doesn't make the lawyers scared. I think that I was very glad that we were able to get to a position where we, you know, where our lawyers were comfortable with us saying, this is MIT licensed, because, you know, to be clear, I, this does not have any reference to the WordPress source code in it at all. I was very, you know, very clear. I didn't even look at it. And obviously it's a different language. So, you know, it wouldn't, wouldn't make much of a, make much sense to, to, to do that. But, you know, I made a choice from the start to not, not even look at the WordPress code just to, you know, just so that I couldn't even be tempted. And we, we had Joost de Valk doing some tests before we launched and he's the creator of the plugin, plugin Joost. I remember using that plugin as a journalist back in the day, using WordPress websites specifically. And he has some, some thoughts and ideas there. That was an important feedback, right? Yeah. It was really fantastic to chat to Joost when, when we were building this, he was someone that we reached out to because of his vast experience in the WordPress ecosystem, you know, all the people and projects that he's worked on. And he published a blog post same day as we launched Emdash kind of praising it for what it brings to the web saying it's one of the most interesting things that's happening in this area that he's seen. And to have that kind of level of confidence in this project is truly fantastic. I mean, the reason we initially were like, we need to go talk to this guy aside from these facts is because like the week before we were planning to launch this, he posted a blog saying how he'd moved his entire site to Astro. And we were like, what a fantastic moment to engage this guy and say, Hey, you can, you can get both. You don't just have to have the kind of fast serverless performance and deployment technique of Astro. You can also have the CMS side of WordPress, but inside Astro working kind of in harmony. So yeah, to have his support is fantastic. And we're really looking forward to working with folks like him moving forward. In his blog post, he said something that sticked with me that I think is really important and relevant, which is related to the design philosophy that is behind Emdash that is trying to make AI agents be, so this is ready for AI agents. So it's done in a way in many situations where the agent can read, modify, generate content without parsing markup. So it's actually built with that in mind, even if you go there and you don't see that much difference behind it, behind the scenes, there's things that will help this AI age. So that's why he titles that blog where he mentions Emdash with a CMS for 2026 for the present and future in a sense, which is cool, right? Yeah, absolutely. I think he lands on a really important point here, which is like, if you, you know, from working in CMS for so long and from just experiencing the last couple of years outside of Cloudflare, looking at a CMS and thinking about how AI can work with it, a lot of people are approaching this from a perfectly fine angle, but not an architectural angle, right? Because they're retrofitting stuff in. So you'll see things like a grammar checker, a kind of like, you know, claim verifier, a write me a headline or title for my post, these kinds of things that are kind of like AI just plastered on top of the system, but he's absolutely right. And I'm so happy with the stuff that Matt has put together for this, that really thinks about how CMS works in this way to provide a way for the agents to operate inside the CMS and not just layer little features on top. So the ability to interact with it through an MCP or a CLI and the API being kind of like fully there is a really good way to think about how we're expecting people to work with this stuff in the future. Instead of you having to install a plugin to do a particular job, you could get an agent to do it. With the MCP, you can link it up to Cloud, to OpenAI. You can ask it, make this operation happen inside my CMS, and they can likely do these kinds of things nowadays. It's really, really fantastic. It's MCP native. I think that what Matt is saying is absolutely right, that the way that people, the way that AI has been kind of bolted onto existing CMSs is one of the reasons that people, a lot of people are not happy with it and find it either frustrating at best or, you know, downright offensive at worst. And I think that a lot of that is because things like using it for doing the actual content creation, I think is the least interesting thing that you can do with the AIs with a CMS at the moment. So I really wanted to focus on allowing that the AIs to do the things that they are good at. And AIs are not good at writing great prose, you know. Maybe they will be one day, but at the moment, you know, it comes out, well, you know, this is one of the reasons we called it MDash, you know. It's like a dig at the way that the AI can write pretty generic prose with some certain common tropes in it. But what I did want to do is give it the ability to do the things that it is good at. And the things that it's good at is structured things like writing code, for example, porting WordPress plugins to Ecliptic, to MDash. And it's allowing it to do things like handling the structures for the schema, handling big refactors of your information architecture, and generally doing things that are annoying for a human to do. And then we can allow humans to focus on the important bit, which is writing great content. Can we show it off? What can we show in terms of the playground? The website, of course, the website. The blog has a link to the playground area that people can just test it out and play with it. And also a deploy button to put your data from WordPress, your blog from WordPress to MDash. But can we show it off? Absolutely. Now, let's have a quick look here. Now, one of the things that I've done here is we've created this playground, which actually it generates you an entire working site that just lasts for an hour. So, you can go in there and break as much as you want and play around with it, but nobody else will ever see it. So, this is what the dashboard looks like. It will look quite familiar if you are used to WordPress. We've got the content types on here. And these are our posts. And all of this is going to be familiar to people that are using WordPress. But we do have things built in, including the SEO. So, that is one of the things that comes out of the box. It also supports i18n out of the box and various other things. So, we've got the editor here is a block editor by default. So, you can insert items in there. You can insert reusable sections into the code, into the content. We've got image handling. We have comments with automated moderation that uses AI moderation. And we've got the ability to properly manage content types. Now, this is one of the key mistakes, honestly, that WordPress made at the beginning. And unfortunately, it's one that I was stuck with forever, which is the fact that the content types are fixed. And that has led to the fact that basically everyone needs the ACF plugin in order to handle their custom content types. And, you know, that doesn't make sense. You know, you have a database, you should be using the fields in the database. And that's the difference here is the content types are flexible in here. So, if we have a post type, we can add or remove these individual fields. We can put different types in there. We can have built-in search. So, we can tell which parts need to be searchable. And we can say that this is a SEO-enabled content type as well, which means that it automatically gets the support for titles and descriptions and images and so on, and includes it in the sitemap. So, this part is all flexible and can be handled like that. And then we have the plugins. Now, I haven't got any plugins installed on this because this is the playground. So, the plugins are not enabled by default. But this is where you would be able to include your plugins. So, this is an important one. So, we wanted to make it very easy for you to move from WordPress. And we offer a few ways to do that. Now, the most portable way is that you can just run your normal WordPress export, which every WordPress site has, and then just upload it here. And we map it through and do everything like, you know, we will read. If you do have a Yoast installed, we will read those fields and map them to the SEO fields in here. Or you can install our export plugin into your WordPress site, and then just link them together. And it will automatically authenticate you and export everything. Or if you are running it on WordPress.com, it will authenticate you through there and use the WordPress .com APIs. So, what I'm going to do here as well is have a look at one of these pages. And then I'm going to look on the preview for it over here. So, one of the other things that we've got is you may have noticed this down at the bottom here, which is the edit. So, this edit mode here allows us to click on the button on the front page while you're editing, while you're viewing the site itself, and actually start editing it in place. So, you know, this isn't going to be the thing that you do for your main writing. You'll use the proper main interface in the admin. But what you can use it for is for making those little edits while you're on the front page and just needing to realize that you've made a little change that needs to go in there. And if you're on the real site, you will see that this has drafts and revisions and all of that. We don't have that in the Playground, but it will allow you to see that and see these things being updated in real time. I heard people online saying, hey, this looks like WordPress in terms visually, like the aspects. WordPress was something relevant for many years for many people. So, using the same visual aspect is not far-fetched. And with small differences, of course, that you showed many of those as well. The visual aspect of making it simple is also important, right? Yeah, and part of that is going to be through familiarity. You know, we wanted it to, we weren't going to slavishly copy the full WordPress design, but we did want to make it familiar to people that are used to using WordPress. And so, you know, your WordPress muscle memory should still work there. The things that you want are going to be in a similar sort of place in there. And the editing experience, you're not going to need to learn everything from scratch. But at the same time, we've tried to, you know, make improvements in there and where we think that those things can be improved. We will make those in a way that we think is going to be helpful for you and that are going to hopefully be things they're not going to get in your way. They're going to be the kind of affordances that you would be hoping that WordPress would have. What about feedback we've been having? It was published yesterday. We're recording this on Thursday. What's the main takeaways from the feedback that we got so far? There's two kinds of classes of feedback, I think. One class is there's obviously a bunch of WordPress people who really, really, really like WordPress and don't see why this needs to exist. And, you know, they want to keep using WordPress and that's completely fine. I'm not bothered and they shouldn't be bothered either. Like we're not here to disrupt WordPress in that kind of way, as said. But the other class, and it's a much greater volume, are people who are Cloudflare fans, Astro fans, you know, people who have grown up on a bit more of a more modern Internet and have been looking for something like WordPress to do the kind of job that WordPress does without having to jump through all the hoops that WordPress requires you to jump through to do that. And also something that is, you know, more AI enabled and enables them to have a bit more customization and safety over the experience. WordPress being the state that it is for vulnerabilities and the plugin ecosystem being the state that it is, is no secret. So there's a lot of concern about that, I think, that people are trying to get away from. So it's been great to hear. There's been, as I said, people reaching out on GitHub with suggestions. There's been a couple of plugins that have been created already, which has been great fun to see. There is a product manager from Pantheon who has decided to port the Gutenberg editor into our tool, which has been a wonderful PR that I've loved to read. And I don't think we'll merge it, but it's always open to discussion, right? So, yeah, it's been fantastic. We've loved the engagement. And there's, we didn't discuss that specifically, we talked about MCP readiness in a sense, MCP server built in, but there's also the X.4.1.2 for agent area monetization around that will also potentially be relevant in the future as well, right? Yeah, X.4.1.2 is honestly one of the reasons that I joined Cloudflare because I was sitting in media companies thinking, AI is going to eat everyone's lunch. We need something to solve this and no one here is thinking big enough. And then Matthew Prince wrote about paper crawl and X.4.1.2 started to kind of be banded together with a bunch of companies and it encouraged me to join this kind of project. So I'm really excited for what that kind of thing can bring, especially to something like MDash. The business model that the Internet was built on for many, many years is under threat. And I think something like X.4.1.2 is going to be the way that we start to create a barrier between the value creators that are creating content and the value creators that are kind of munging everything together to give people very personalized answers to things. You know, both are creating value, but at the moment there's a lot more value going in one direction than the other. Actually it was Jost that actually said about the SEO perspective and you already mentioned a part there that is embedded about the SEO. Actually he says that the SEO foundation of MDash is solid. It has built-in SEO controls, but it's also done so that plugins can actually do more there in the full SEO suite in a sense. What can we say in the plugins area that how can people do their plugins and continue this journey? Well, there are docs in the repo that you can go and look at yourself or you can point the agent out. We're looking to host those shortly. You can contribute directly on GitHub. I would love to have some discussions with folks before they open PRs so we can work out that everyone's going in the right direction. But I think an important part of that is that we are really open to expanding what plugins can do. So at the moment we have a quite fixed list of hooks that you can tie your plugin to react in response to those events happening in the system. We would love people to say, okay, this is the thing I want to build. These are the hooks that I need for that. And then let's all work together to try and make that happen. But yeah, you can build a plugin now. You can build a trusted NPM installable plugin, or you can build a sandbox plugin. Go wild. It's all there for you. This has been great. Anything that we want to say for people to just think about for what's coming in the next few months? We'd really like people just to give this a try and give us the feedback. We've released this in a state where we think that people will be able to try it out. This is far from ready, but what we really need now is people's feedback. Obviously, PRs and issues are great, but a lot of it is going to be just hearing what people are looking for and what their pain points are and what they like and what they don't like and what they would want instead. So please try it out. Come and leave issues on our GitHub and just let us know. Just try it and tell us what you think. That's great. Matt Taylor, do you want to add something there? Yeah. Please do come to the GitHub. It's mdash-cms-mdash and go into the discussions, go into the issues and tell us what you're trying to build. Tell us where you've had success, where it hasn't worked out for you. That's going to be key to helping us build this out over the next couple of months. That was perfect. Thank you so much and let's talk soon about updates and things like that. Awesome. Thank you. All right. Thanks a lot. Thanks. That's a wrap.