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 uh plug-in 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 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. not uh it's actually about a announcement that we did on April the 1st, but it's not a April Fool's uh joke. It's actually a very much a full-fledged product. I'm your host Ronto based in Lisbon, Portugal. And for that, I have two Matts 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 place places, right? Yeah, I'm at home. I'm I'm in London about 20 minutes from the office. Uh Matt is a bit further away, I think. Yeah. More north or south? I'm west. I'm um 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 a April uh 1st announcement and for Calfller that's not a 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 in even in the past in terms of technology. Of course, Apple celebrated the its 50th birthday actually on April the 1st this week as well. And even Gmail was launched also on that day. What can we say to folks about this announcement introducing Nash, the spiritual successor of WordPress that solves plug-in security? What is the main take really? Well, I hope that this can be as impactful as Gmail. Um, I'm not I'm not really sure whether that's going to be the case, but hey, we got to you got to swing for the for the fences or whatever they say. Yeah, I mean, as you said, this M dash is the we we call it the spiritual successor to WordPress. So, it's not a it's not a rewrite of WordPress or a port. It's it's a new CMS that's built with the same philosophy as WordPress. is designed that if you like WordPress, we think you'll love Mdash because it follows we try to bring the the good bits of WordPress because you know we we like WordPress. WordPress is great. WordPress has done you know manages to scratch an itch for millions of sites out there. Um 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. You know 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 CTO, 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. Right. Exactly. Like WordPress has a lot of fans, um, 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. You know, 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 uh 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 like both full stack. You know, you get the entirety of the site, the 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 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 some way. And the other thing is it seems a bit targeted to for you to spend money as well which uh is something I never like 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 like 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 uh from the user as time goes on. Just think about um media space for example, right? 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 the host 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 you would upload to R2 or S3 or some kind of blob storage system like that and you would reference the file via a a locator and that's how of course we've built mdash 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 mdash is built means that it can operate at much greater scales much more efficiently than WordPress is able to say a lot of the things that are the complexity and the cause of the complexity are also the other side are the some of the strengths of WordPress and um a lot of that comes down to the plug-in 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 Mdash 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 uh your past that actually led you here to to this project? Matt Taylor, if you can. Sure. Um, so I have spent before I joined cloud for 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. Uh, I was at the Financial Times before I moved to uh, Cloudflare. And a lot of that time I was working in CMS um 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 kind of WordPress presents and is presented with when is trying to 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 my experience comes at it from another angle because I am still you know I'm currently core maintainer on the on the Astro team and Mdash is based around the Astro web framework but I also previously was on the the Gatsby core team and so I was involved in both of those. has been involved in integrating the web frameworks with CMSs and uh Gatsby in particular had very deep integrations with with WordPress and you know we were on the we worked together with the the teams behind WP GraphQL for example. 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 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 the powers of the modern web technologies built in. That's actually a good uh segue because uh 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 who started it how many um months it took sometimes we had vinex that was done in one week with AI in a sense of course there's in many of these projects there's a whole uh projects before that that actually feed into the project that we announced that 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 how many steps it took in terms of months and teams yeah sure this this is something that um the Astro community and I and the Astrocore team have wanted to do for a very long time um but we've not really been able to devote the resources to it because it is you is a major undertaking. WordPress is is 20 years old more and um you don't just replace that thing in a in a weekend. So I I was discussing this with Dane, our CTO back in January. So he was he was talking to me. It's like how could we get WordPress working? Um and obviously I jumped at 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. So in Astro 6 we launched live content collections and we launched uh 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 V-Ex was you know another project that was an 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 V-Ex was one where it was a deliberate attempt to replace an API. So it was very closely scoped and that 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 the definition of what we were building. We were very deliberately not trying to do a direct port of WordPress. We it 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. That was one of the initial um initial things there is we were thinking we wanted agents to be able to port your site or your theme or your plugins over from from WordPress. So the approach that we took on this is that starting in in January, I spent a long time working out the 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 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 V- Next was something where there was it was like first version in a weekend and then shipping it a week later, which was like um a kind of, you know, something that really blew my mind. That actually happened in the middle of the development of MDH. I'd been when Steve, who's who's my man manager, did um started work on V-Next, it was I was already several weeks into to working on on what became Mdash. So it was like I was seeing him shipping something in 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 3 months working on on this thing now. Um whereas but at the same time it's three months where it was mostly me. I mean, aside from doing the the actual the the code has 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 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 um 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've 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 V-neck 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 funnelized uh thing as well with a different purpose and with WordPress behind that uh gives uh it's like 40% of 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, right, 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 plug-in 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 flywheel rolling much faster than you could previously. You know today I've seen people release plugins and open PRs to to change how works which is awesome um 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 you already mentioned in a way that plugins are securely sandboxed and can run in their own isolated via dynamic workers that 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 coffer ecosystem in this case workers and developers but the ecosystem is there also to support making this uh a bit uh more resilient in terms of those plugins and what they can do in security in a way right Yeah, I mean it was it was an interesting kind of moment when I I'd been obviously the plugins were kind of one of the most important things that we needed to get right. But equally, you know, we know that uh plug-in 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 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 um 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 um these things can execute. And I suddenly thought, wait a moment, that would be absolutely perfect for 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 technologies forward we'll be able to do something that's easier to dis 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 plug-in security problem suddenly appeared and re 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 for WordPress. So I think you know I we say solve it's going to it's still within a particular scope and the certain types of plugins do need to be installed as a 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 um 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 on your servers. These are these are all things that it's not able to do. It's very much fully isolated in terms of the permissions that each plug-in has got and it can't stamp all over the storage of other plugins or 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 Mdash works? And one of them that had this exact vulnerability. You know, admin user can be created was a plug-in 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 that from what we've built, basically that's possible today in this sandboxed 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 plug-in were in Mdash 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 that those are exactly the sort of plugins that this that these sandbox um execution is supposed to um and it's audible as well those plugins in a sense because of that. So that's important right one one thing actually it's it's open source and MIT licensed why is that uh 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 it's published under the 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 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 20 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 is GPL. But at the same time, the 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 with their own code because it then forces that code to adopt the same license. And this this is a problem because you know if you want to release something under the GPL then then that is great but it should be something that you make a specific decision to do. So I was was very clear from the beginning that I wanted to be sure that this was not a derivative work because it's this it goes to the extent that even every WordPress plug-in and theme has to be GPL licensed just because of the way that it integrates with the um with the WordPress core. So I 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 I have to say the amount of work that went in to making sure that we could make this carefully MIT licensed very much vindicates the reasons why we wanted to make this MIT licensed. um 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 these kind of policies you know if people want to write 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 the flexibility and kind of legal peace of mind that you get with a license like like the MIT, you know, really realistically the only requirement in there is that you you give credit. So I think um I think that that has become the the de facto license for a lot of for most most of the web ecosystems 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 license 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 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 Yoast Devalk doing some tests before we launched. And he's the creator of the plug plugin Yoast. I remember using that plugin as a journalist back in the day. using WordPress uh websites specifically and he has a some some thoughts and ideas there. That was an important uh feedback, right? Yeah, it was really fantastic to chat to Yoast when um 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 Mdash kind of praising it for what it brings to the web saying it's you know 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. Um 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 stickked with me that I think is really important and and relevant which is related to the design philosophy that is behind N dash 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 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 and dash with a CMS for 2026 for 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 from working in CMS for so long and from just experiencing the last couple of years outside of Cloudflare looking at 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 they're retrofitting stuff in so you'll see things like a grammar checker kind of like you know claim verifier a write me a headline or title for my post these kinds of things that are kind 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 um 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 plug-in to do a particular job, you could get an agent to do it with the MCP. You can link it up to claude 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. MCP native. I think that what Matt Matt is saying is absolutely right that the the way that people the way that AI has been kind of bolted on to existing CMSs is one of the reasons that people a lot of people are not happy with it and find it 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 the 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 pros. You know, maybe they will be one day, but at the moment it, you know, it's uh it comes out well, you know, this is one of the reasons we called it M Dash. You know, it's it's a it's like a dig at the way that the AI can um write pretty uh generic uh pros with 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 structure things like writing code, for example, porting WordPress plugins to Ecliptic to Mdash. And it's allowing it to do things like handling the the structures for the schema, handling big refactors of of your uh 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 what can we show in terms of the playground? the website, of course, the website, the the blog has a 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 and dash. 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 um it generates you an entire working site that that just lasts for lasts for an hour. So, you can go in there and break as much as you want and play around with it and also but nobody else will ever see it. Um so, this is what the the dashboard looks like. Um it will look quite familiar if you are um if you are used to WordPress. We've got um the content types on here. Um and these are these are our posts. And all of this is is going to be familiar to people that are are using WordPress. Um but we do have things built in um including the SEO. So that is one of the things that comes out of the box. Um it also supports uh i8 out of the box um and and various other things. So, we've got the editor here is a is a block editor by by default. So, you can insert items in there. Um, you can insert reusable sections um into the into the code um into the content. Um, we've got image handling. Uh, we have uh comments with um automated moderation that's uses uses AI moderation. Um, and uh, 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 they were um, stuck with forever. Um, which is the fact that the the content types are fixed and that has led to the fact that basically everyone needs the ACF plug-in in order to um, handle their their their custom content types. Um and that 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 that content types are flexible in here. So if we have a post type we can add um we can add or remove these 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. Um and we can say that this is a C SEO enabled content type as well which means that it get automatically gets the support for titles and descriptions and images and so on. Um and includes it in in the sitemap. So this this part is all um flexible and can be can be handled like that. Um and then we have the plugins. Now I haven't got any plugins installed on this because this is the playground. So the the plugins um are not uh enabled by default. But um this is where you would be able to um include your plugins. So this is an important one. So we wanted to make it very easy for you to move from WordPress and you we we offer a few ways to do that. Now the the most uh portable way is that you can just run your normal WordPress export which every WordPress site has um and then just upload it here and it we map it through and do everything like you know we will read if you do have Yoast installed we will read those fields and map them to the SEO um fields in here. Um or you can install our export plugin um into your WordPress site and then just link them together and it will automatically um authenticate you and export everything. Um or if you are running it on WordPress.com, it will authenticate you through there and use the WordPress.com APIs. So, um, what I'm going to do here as well is have a look at one of these pages. Um, 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 um allows us to click on the on the uh on the the button on the front page while you're editing while you're um 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 your big um your main writing. You'll use the proper main interface in the admin. But what we what you can use it for is for making those little little edits while you're um you know on the front page and just needing to realize that you've made a um uh you know you've made a little uh 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. Um we don't have that in the in the playground but it will allow you to see that and see these things being updated in in in real time. I heard people online saying, "Hey, this looks like WordPress in terms of visually like the aspect. Word WordPress uh 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. Um the the visual aspect of making it simple is also important. And and part of that is is going to be through familiarity. you know, we wanted we wanted it to we we weren't going to slavishly copy the um 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. Um the things that you want are going to be in a similar sort of place in there. um and the 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 where we think that those things can be improved, we will make those in a way that we think is that is going to be helpful for you and to that are going to hopefully be things they're not going to get in your way. They're going to be the the kind of affordances that you would be hoping that WordPress would have. Um what about feedback who we've been having? uh it was published yesterday. We're recording this on Thursday. What's the the main takeaways from the feedback that we got so far? There's two kind of classes of feedback. I think one class is there's 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 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 as said. Um but the other class and it's a much greater volume are people who are Cloudflare fans, Astro fans or 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 plug-in ecosystem being the state that it is is no secret. So, um there's 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 uh reaching out on GitHub with suggestions. Um there's been a couple of plugins that have been created already, which has been great fun to see. Uh 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 don't think we'll merge it, but um it's always open to discussion, right? Uh so yeah, it's it's been fantastic. We've loved the uh engagement. Uh and there's uh we didn't discuss that specifically. We talked about MCP uh readiness in a sense, MCB server buildin, but there's also the X412 for agent era monetization around uh that will also potentially be be relevant uh in the future as well, right? Yeah. X42 is honestly one of the reasons that I joined Cloudflare um 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. Um, and then Matthew Prince wrote about paper crawl and X402 started to kind of be banded together with a bunch of companies and it encouraged me to 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 X42 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 monging everything together to give people very personalized answers to to things. You know, both both are creating value, but at the moment there's a lot more value going in one direction than the other. what actually it was uh Yost that actually said about the SEO perspective and you already mentioned a part there that is embedded about the SEO uh actually he says that the SEO foundation of mdash is solid it has built-in SEO controls uh but is also uh 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 um docs in the repo that you can go and look at yourself or you can point the agent at. We're looking to host those shortly. Um you can contribute directly on GitHub. Um I would love to have some discussions with folks before they open PRs so we can work work out that everyone's going in the right direction. Um, 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. Um, but yeah, you can you can build a plug-in now. Uh you can build a uh trusted npm installable plugin or you can build a sandbox plugin. Um go wild. Uh it's all there for you. Uh this has been great. Uh anything that we want to say for people to just uh think about uh for what's coming in in the next few months. We'd really like people just to give this a try and give us the feedback. you know, we've we've we've released this in a state where we think that people will be able to try it out. This is far from from ready. We but what we really need now is is people's feedback. You know, 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 leave issues on our GitHub um and just just let us know just just try it and tell us what we what you think. That's great. Good day to end. Matt Taylor, do you want to add something there? Yeah, please please do come to uh the GitHub. Uh it's m--cms dash um 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 uh 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. Bye. That's a wrap.