[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley. Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, the future of blocks outside of WordPress. If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to WP Tavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

I’d really like to hear from anyone out there who would like to come onto the podcast and talk about whatever it is that you do with WordPress. It might be that you’re a developer, a WordCamp organizer, a contributor, a designer. Honestly, if it’s about WordPress, I’m keen to hear from you and hopefully get you on the show. Head over to WP Tavern.com forward slash contact forward slash jukebox, and use the contact form there.

So on the podcast today, we have Leonardo Losoviz. He’s here to talk about the block protocol. Ever since WordPress 5.0 was released several years ago. We’ve been using blocks to create content inside of WordPress. More and more blocks have been developed to manage the creation of content, and the display of this content on the front end. With WordPress 5.9, anyone using a block-based theme is able to manage more of their site with blocks. The header, the footer, menus and more. It’s a real shift in the way that content and sites are created and puts the end user in control of the way that their website looks. But the content that you create with your WordPress blocks are limited to your website. It’s not just WordPress that’s using blocks though. Go to almost any modern SaaS app and you’ll see content blocks in use.

It’s such an easy process to understand. You want text, use a text block. Perhaps an image, well use the image block. In this way, non-technical users can build up their content easily. For obvious reasons, every app and CMS, which is using blocks has built their own implementation for their own needs. The needs of their users and their customers.

The block protocol is a new attempt to unify the way that blocks work, so that if you create a block on your WordPress site, the same content could be consumed and used elsewhere, seamlessly. The reverse would be true as well. If you stop to think about it, this is a really powerful idea.

Leonardo talks to us today about the block protocol, what is, and how it might work. We discuss some of the benefits that the protocol might bring, as well as some of the barriers which are undoubtedly in the way of its development and adoption. Who might benefit from using such a protocol, and whether or not we can realistically expect this to be implemented in the near future.

If you’re interested in finding out more, you can find all the links in the show notes. Head over to WP Tavern.com forward slash podcast. And look for episode number 18. And so without further delay, I bring you Leonardo Losoviz.

I am joined on the podcast today by Leonardo Losoviz. Hello Leonardo.

[00:04:02] Leonardo Losoviz: Hey, Nathan, how are you?

[00:04:03] Nathan Wrigley: Very good. Thank you for joining us on the podcast today. We’ll get stuck into the main content a little bit later. We’re going to be talking today about something called the block protocol. But before that a little introduction from you, Leonardo, if that’s okay, how come you’re on a WordPress podcast? What is it that draws you to WordPress? Are you a coder or a developer? What’s your background with tech?

[00:04:24] Leonardo Losoviz: I’m a developer. I’ve been working with WordPress since 2012 I believe. And, I work or I have a plugin that is a GraphQL server for WordPress and I work with that pretty much every day. And as I develop the plugin I have insights on other topics. So in particular, the whole of the block protocol is one of the things that I could connect to because of my background with GraphQL.

[00:04:50] Nathan Wrigley: Thank you very much indeed. Now I’m going to draw everybody’s attention to an article. I will link to it in the show notes. So if you’re not familiar, go to WP Tavern.com forward slash podcast, and today’s episode will be listed there.

And in that set of show notes will be links to all of the bits and pieces that we happen to mention today. And the first one is an article that you wrote on the smashing magazine website called implications of WordPress joining the block protocol. This is an idea that was raised really recently. The idea being that there is this third party idea, it’s not a WordPress idea and it’s called the block protocol.

Would you just like to very, in the broadest possible terms? Just tell us what the block protocol is.

[00:05:37] Leonardo Losoviz: All right. I will try my best.

[00:05:38] Nathan Wrigley: Thank you.

[00:05:39] Leonardo Losoviz: So the block protocol is an idea to get blocks to be interoperable between different applications. So right now, when we are using WordPress, we have the WordPress editor. We are composing a blog post with blocks and seeing the latest version of WordPress, version 5.9. We can also create layouts. We can create the full site, via what’s called a full site editor ,via blocks. Now these blocks that we’re using on WordPress, they can only be used in WordPress.

So there’s this guy, Joel Spolsky a very famous guy. He created a stack overflow., If I’m not, if I’m not wrong. Yeah. So he came up with this idea called the block protocol, and the idea will be to get the blocks in this case from WordPress, but from any other software tool and to port them into whichever other application. Be it based on WordPress or not.

So the idea is that now we can reuse blocks among applications the same way that we can reuse components like JavaScript components nowadays. So for instance if you’re a developer, and possibly you have coded a component for React, and then you have another website for another client, you can reuse the same component.

So the idea is to do something similar with blocks. That you have developed a block for your WordPress site. And the day after tomorrow you have a different application, which is based on Node JS or on a different CMS. And you want to reuse the same block that you have for your WordPress site. With the block protocol, you could do that.

[00:07:15] Nathan Wrigley: So, everybody I would imagine who’s listening to this podcast has some familiarity with the new block editor. That is to say, rewind to WordPress 5.0 in come blocks. Blocks are now the way that we create all content, and increasingly the way that we create everything around our website, especially with the 5.9 release and full site editing and so on.

But what may not be obvious to most users is that that content is, it is completely siloed within WordPress. So as you’ve just described, if you create some text or you create an image, you are really going to struggle in any meaningful way to take that and put it somewhere else. The best you can really hope for is going in and copying and putting it into your clipboard on your computer and then going and pasting it elsewhere.

But the intention, I believe of the block protocol, is to make it so that applications, no matter where they are based, there’ll be able to communicate with each other. And the picture that you put inside of Gutenberg would be available to some other piece of software that’s nothing to do with WordPress. Have I more or less summed it up there?

[00:08:22] Leonardo Losoviz: Yeah. What you have to take into account is that with the blocks, you create content. So when we’re talking about content, you can copy paste it into different application, it’s all HTML at the end of the day. It will work here. It will work there. But blocks, we’re talking about functionality. About being able to use this functionality to create the content in first place.

So think of any block that you might actually think of, say a Google map, that you can point and click on the map, and then you have the location that you want to display. So this is functionality. Like behind the functionality you will be producing HTML, which is the embedding of the Google map. But you’ll know, you need to know how to code HTML to do that. You don’t want to do that. You want to do it with a WYSIWYG. That is, visual that you click on a dynamic map. This functionality is a block, and this is the functionality that we want to port across applications. So this is more than content.

[00:09:21] Nathan Wrigley: Perfect. Thank you so much for clarifying that. Okay. The article, at the beginning, you go to, you go into explain how Joel Spolsky he has got this project called the block protocol. And again, I will link in the show notes to that so that you can go and find the website there. There’s a fairly impressive website where they explain things in pretty good detail with lots of documentation, and so on. But the reason that we’re talking, is that it would appear that fairly recently, Matt Mullenweg reached out to Joel.

I don’t know if it was that way round or Joel reaching out to Matt, but either way some conversation began, I believe it was perhaps on Twitter, where Matt was essentially saying, look, it would be really interesting if we could make all of this work with Gutenberg blocks. So in other words, why don’t we see if there’s some possibility of making your block protocol and WordPress work together. So that stuff can be egress and enter WordPress websites, to other different parts of the web.

Now, in order to understand this better, you then went on to explain how a block is actually created. You’ve got this paragraph entitled what is a block. And I think, for most users of WordPress, if you’re a developer this obviously would be different, but if you’re a casual user of WordPress or you’re a publisher or an implementer, it might be that in the block editor, you just see the block and it’s a little rectangular icon and you click the button and it comes onto the website.

Of course, there’s a lot of incredible technology going on in the background. And I just wonder if you could explain to those of us who don’t necessarily understand, what is a block what’s actually going on in the background?

[00:11:00] Leonardo Losoviz: All right. If you do not understand what a block is, that’s good. You do not need to understand. All you need to do is to be able to use it. So this is, it’s complex in the sense that, you know, the simpler something is to be used, the more difficult it is to implement. Which is the great thing about Apple products. You know, that the box is just white. But that whiteness, they have a huge team of designers to come up with.

So the block, if you’re able to use a WordPress editor, then the book already succeeded. You don’t need to understand how it works or what it is, apart from the fact that you need to use it to create content, which is in this case to write a blog post or, since the later version of WordPress to create the full, the overall site, by clicking at elements.

So then what is a block? It’s a concept. It’s a unit of something, in this case it’s code, that you interact with to create content on the site. If you’re a developer, you will be developing blocks. You can be a designer and that you will be applying styles to blocks. But at the end of the day, it’s a concept. It’s not really an implementation. It’s just this idea of what you said, you know, like a square, that you click on the square possibly, and something will happen on the website. You will have created content. So yeah, it’s one of those things that now it appears everywhere because WordPress is trying to make it widespread.

This is what Matt Mullenweg had attempted to do with his concept of reducing the different interfaces that we have to interact with. So in the past with WordPress, you could create content via short codes or with the classic editor, or with the customizer. The block replaces all of these. You had to learn only one thing, which is the block, the interface with the block, and you’re able to create your website, whatever it is that you need to create.

Maybe you want to add a video. You want to embed a picture, something very simple. But now also we have more functionality, like editing pictures and possibly even editing videos in the future. It’s taking more roles. It is like an application to create cotent.

[00:13:13] Nathan Wrigley: I guess this approach is absolutely lovely. You’ve got a nice little graphic on your website where you talk about the fact that the block is kind of a container for all sorts of child components. So you could have all sorts of different things inside your block. So a block doesn’t just have to be one simple thing. It could be a multitude of layered things which could become incredibly complicated. But the point is the block encapsulates them all, but it’s siloed within WordPress. You can’t easily get it out.

And well, maybe there are ways that you can get it out, but it’s not relatively straightforward for the likes of me. So along comes Joel Spolsky with his block protocol. And the idea is that he would like all of these different bits and pieces to be interoperable. So that a block on WordPress might be able to interact, and I believe on the article that you wrote, you mentioned a couple of things. You mentioned a SaaS product called Notion, which is a bit like a note taking app, but it’s much more complicated than that. You can do all sorts of things like add bullet lists and what have you. And the premise therefore would be well, wouldn’t it be great if we could take the content that we’ve created inside of Gutenberg, inside of WordPress, and we could just have it so that it was completely interoperable and it was transparent. You could throw it over for example, to Notion or anything else. So is that the dream here is that what Joel and his block protocol is trying to enable? To make there a standard set of ways of doing things, such that everything, everywhere can communicate with anything else?

[00:14:56] Leonardo Losoviz: Yeah, you said just right. It is a dream. It’s something that seems to be a bit out of reach. So far it’s a potential, it’s an idea, but from idea to implementation, it’s a long road. In particular, I don’t think that Notion will want to be part of this movement because there’s nothing in it for them. I believe that Notion has spent so much time and money developing their own blocks. So I don’t see why they will be sharing them with the wider world. Basically, if they give us their blocks, we can embed them in our WordPress site and recreate Notion. And this is the same with Medium. I don’t see them participating in this idea.

Now they could still use it, because a block protocol is a protocol. You can use it for your own internal use. That means that Medium or Notion they could have sub applications, or they could have their own internal team, their own development team, that they have internal applications and they could use the block protocol to reuse their own blocks within their own applications. But that will not be shared with us. We are using WordPress and I don’t expect to have Notion give the WordPress users access to their blocks.

[00:16:08] Nathan Wrigley: Yeah. So I guess where you’ve got a proprietary piece of software and their way of creating revenue I suppose, is on their, the system that they’ve built with components and blocks and the ability to have a beautiful UI and all of that. It’s unlikely in your estimation that they would wish to become part of this because it removes that unique value proposition. If it’s simple to put that data in exactly the same form elsewhere, it’s unlikely they would want to be a part of that because it upsets that business model. However, that being said all is not lost. The block protocol opens up the opportunity for lots of different scenarios, not necessarily the SaaS proprietary platforms that we mentioned, but in your piece, you go on to describing in quite a large amount of detail that the types of people, teams, and applications, and so on that you feel the block protocol would fit well with. So should we just delve into this? Who might want to use the block protocol?

[00:17:07] Leonardo Losoviz: Okay. First one is, if you do not have money, which is quite a general condition for a lot of startups, then you would want to use a block, develop protocol to use blocks that are already developed by somebody else, that you can just customize for your own use.

And this is important because coding blocks is labor intensive. You need a dedicated team and that’s money and that’s time. Think about WordPress. The WordPress editor, up to now, it took five years. You have been started five years ago. And now only now after five years we have full site editing. I believe that, that was not their idea when they launch it at the very beginning or when they were planning at the very beginning. They had never expected that it will take five years to be at this stage.

It took that time because high quality software takes time to produce. Think about the accessibility issues that it will have in at the very beginning, which were fixed, but it took time. So once again, if you want to create a website using blocks and you had to create it from scratch. Then you’re going to be spending a lot of money. Now you could alternatively, depend on the block protocol, use the blocks by WordPress and just customize them for your own application. So that’s the first one.

The second one is if you have a website that you want it to be fancy, or you want to be appealing, like Medium, like Notion, but it’s kind of falling behind because, you know, I mean, we all share the same users. So I think that’s Facebook when it came out, it was a sort of tragedy for website developers who didn’t have a lot of money to hire a team because people are expecting the same quality as Facebook. Like interactivity, dynamic functionality. Eventually they released React and we could do the same, but it takes time and it takes effort.

So then once again, you need to compete against these guys. If your website is not looking good, you will fall behind, nobody going to come to your website anymore. And nowadays the technology barrier is quite high in the sense, design is so amazing. Some websites out there are so amazing and they’re are all for free.

So if somebody developed really nice looking blocks and you don’t want to fall behind, you can just use it. So in my article, I was using Mailchimp as an example, because the Mailchimp editor for creating the newsletters, it was kind of falling behind a bit. I had noticed that they were experimenting with a new editor, which was similar to the WordPress editor.

I cannot find it anymore. It was buggy and I just couldn’t use it for long, and I revert back to their current experience. So I was wondering if Mailchimp could benefit from using the WordPress blocks. So you can see WordPress, MailChimp is a multi-billion company. Like, I don’t know, ten billion dollars recently or something like that. So they could benefit from this.

Then I believe that as a content management systems in particular, I quote Drupal, they could use it because Drupal has already expressed interest in using Gutenberg. In using the WordPress editor for creating content. So now with the block protocol, it will be easier to achieve this.

The reason why it will be easier is because WordPress right now, when you develop, the WordPress editor doesn’t need to care about anyone. They just care about themselves. So at the same time that you create the functionality, on the client side, all the dynamic stuff, the layouts and everything. There has to be a backend that can field the functionality. So we have the WordPress Rest API. So whenever you have a new block, possibly the block will need a new Rest endpoint to fetch data and interact with the server. All of that is happening on WordPress and WordPress needs to certify it. But right now WordPress only cares about WordPress.

I know WordPress can certify its own requirements. Then it’s good to go. So Drupal right now needs to be catching up with WordPress all the time. If WordPress 5.8 comes out and Drupal catches up with it, and then on WordPress 5.9, they changed the API and they’re having a bit of changes lately. Then Dupal will need to also change its own API to catch up. So it’s a lot of effort to be playing catch up all the time. But if we, if they go through the block protocol, WordPress cannot go it alone anymore. They will need to satisfy a requirement imposed by a third party. So then Drupal could say, okay, now we’re integrating into WordPress anymore, all I need to do to certify this contract with this clear guidelines, set up by the third party, and as long as I do this and WordPress does the same, then I can use WordPress blocks without having to be always running behind them. So I think it could be a good thing for Drupal in particular, because they showed interest and in general, any content management system.

And finally I said, open source projects, they could use this because I hope that will happen not really with components. So if you’re a React developer and you want to have a select dropdown, you don’t need to call it from scratch. You just go to NPM, to the registry and you can search, React dropdown or React select. And that will be like quite a few components that we can download. You can install and you can have in your application.

So a block, it’s also a component. It’s a high level component, which has a definite functionality and is trying to achieve a certain goal. So I can see that if that happened in the past with components, it will also happen in the future with blocks, that developers will create blocks, which can be used by anyone.

Think of blocks like modifying like editing video or editing images. Or whatever it is really. Games, the could actually create games and published them on blocks as blocks. And then any website will embed them on their own, their own application.

[00:23:13] Nathan Wrigley: It’s a really nice list. I can really see exactly what you’re talking about, especially the sort of time saving, labor saving aspects of this. You know, teams who have a modest budget who can just leverage things which have already been built and contributed out as open source blocks within this block protocol, it’d be really useful. And like you say, applications where the constraints of money or perhaps experience are going to cause it to be really difficult to get over the line. And if you can then just dip into a bunch of prebuilt blocks that other people have already committed, that would be brilliant. And like you say, content management systems and the one that you mentioned Drupal, who’ve gone out of their way to link with Gutenberg and make their own module so that they can use Gutenberg. Yeah. It’s really interesting.

All of that though, is about, it’s about the benefits, I guess, to people if WordPress were to adopt this. So this is about people gaining a benefit, but you go on to describe it in the opposite direction. You talk about the benefits to the WordPress project of the block protocol.

Do you want to just explain your reasoning behind that? Who, well not who, what are the benefits? What are the benefits that will be brought to WordPress as a whole by the block protocol?

[00:24:32] Leonardo Losoviz: All right. The first thing I believe is that WordPress will keep growing. And the reason for that is at WordPress right now, it’s used as a content management system. But if it also provides blocks, then developers can use WordPress on a different role, which is to create the layout, the client site for the applications. So then WordPress will become more entrenched in the toolkit for creating websites. And even though WordPress right now is really quite big, you know, Matt Mullenweg wants to be even bigger, right? Like, so I think that this is a potential outcome that will happen. That WordPress becomes the default tool to create sites. Not just content management system, as it may be the case that right now, but also to create layouts for even static sites, like HTML based sites that were created with JavaScript. Now you can use WordPress for that, which is something quite new. I mean, you’ll then think of WordPress to create static HTML sites via JavaScript. But this could be a possibility.

Then if this were to happen, the modern world of developers will come into WordPress, JavaScript developers, React, Vue, Angular. So they might want to become engaged and become contributors. So I was checking the Stack Overflow survey, and currently there are three times more JavaScript developers than PHP developers in the market. So then think about it. If you’re suddenly opening up the gates to these guys, you’re opening up to, potentially three times of many contributors as we have not right now. I mean, assuming a similar rate of contribution, of course, I mean, this is just pure guessing. But the fact that you’re opening the gates to them can only bring, either nothing happens or they come in and they contribute. So this is a potential good outcome.

Then, you could have blocks available from other parties that you can import into your WordPress site. So if you have an image editor that somebody hacked ready for their own application and they use a block protocol, you can embed it to your WordPress site.

The other aspect is that the WordPress editor or Gutenberg does not live everywhere on the WordPress site. So right now, when you go to the WP admin, you’re interacting with Gutenberg. But in the WordPress site that you’re creating as a developer, you don’t have Gutenberg there. On the client side, on the site that the visitors are accessing, there’s no Gutenberg there.

So the implication of that is that it not so easy to create nice layouts or dynamic functionality, using React or using Vue or using whatever else. So power the website that your visitors are accessing. So if we had a block protocol, we could create this on a much simpler way because now Gutenberg will be talking to the WP admin or to the blocks, via the block protocol.

And the block protocol will be a single API to create websites, whether it is a WP admin, which is already going through Gutenberg, or on the public facing site, that if you’re good with React, you can create a React client that talks to the block protocol. And the block protocol will embed the blocks that you already have provided by WordPress.

So whether you’re gaining from what you already have. The idea with this is that you have this set of blocks that they only have a limited use, which is only from within the WP admin. Now you will also make these blocks available to the site, to the public facing site. Some blocks, they make no sense because they are only for editing content in the WP admin. But think of a game, you can develop a block that is a game and you could embed it on the public facing site.

So then why not? You could. Or an audio player like, this podcast, you can create a block that is a podcast player and you embedded on the site and it’s something that is just one line of code. You just add the block and everything is already existing. So once again, either you gain or nothing happened.

And then I think that blocks could be helpful in that coming phase four Gutenberg phase three, which is still some time to go, possibly 2023. Which is going to be based on collaboration. They’ve yet to use the WordPress editor or to create Google docs like experience. To communicate with other people, to collaborate that you can edit the same document. And then you can add comments on the side and you can integrate the comments or suggestions. You leave feedback. So all of these is going to be the next phase of Gutenberg. As it is now, it can only happen in the WP admin. So if we had a block protocol, all of this could also be brought to the client side. Now, particularly because you will not need to log into the WP admin any more to collaborate.

And for instance, if I have a WordPress site, I don’t give access to random people. I just give access to my editors, or the writers, right. But what if I want to collect input from normal folks from visitors? Right now the only option that I have is comments, but that’s not integrated within the editing workflow. So if you had the block protocol, you could replicate the same workflow, editing workflow experience on the public facing site and allow visitors to give you feedback or collaboration.

And then one other aspect that I mentioned in the article is that you can simplify how you render blocks dynamically, because right now there is an issue that Gutenberg has, which is that you need to create the same logic twice, once in JavaScript to render the HTML, when you’re editing the content in the WordPress editor. And once in PHP, when you’re rendering on the client for the visitor, that’s the dynamic content. So that means that the same call has to be called twice in two different technologies. And for what I have seen in the GitHub issue that was bringing this up, not everyone is comfortable with the two languages.

You might be comfortable with JavaScript, but not with PHP, or you might become comfortable with PHP, and not with JavaScript. So this gives you the alternative to do it only in JavaScript, which is not ideal because, if you do it on PHP, then you can print it on the HTML already, which has better for SEO. But at least you have the possibility to do it.

And if that were to happen, I believe that more React developers could also be engaged with WordPress because they don’t need to work with PHP anymore. They will be basically working React all the way. And it will still be a WordPress site, which is quite interesting.

And yeah, I have one more issue, one more item to mention. Which is that you can bring in developments from outside. So as I was mentioning, I’m working with GraphQL myself and what happened with GraphQL is quite interesting, quite remarkable, that you have produced a huge ecosystem of clients and tools. Which is the couple from each other. They’re not collaborate. They’re not talking to each other,. But all of these tools, they can operate with each other because they all follow the same specification.

So one single case that is quite easy to follow is static documentation of the endpoints that you’re creating with Graph QL. I believe that the same can naturally happen if we use a block protocol, that some developer out there can create a tool to create static documentation of the blocks that then you can use to document the blocks for WordPress. And if that were the case, you don’t need to develop these in-house. So that means that the WordPress contributors, they can free up their time to do something that is specific to WordPress.

[00:32:48] Nathan Wrigley: I do like the idea of people being able to access all of the pretty amazing stuff that’s been created by the WordPress community already. That seems to be really interesting. If this were to happen, all of that good stuff that’s been made would be available elsewhere and not bound distinctly to Gutenberg, but also the idea that you mentioned and somewhat counter-intuitive to me, I wouldn’t have thought about it.

The idea of having all of these blocks on the front end and the notion that you don’t need to be logged in. I guess, all sorts of complex things that are otherwise out of bounds at the moment suddenly become possible. And so as yet, unimagined scenarios potentially will become possible in the future.

Further down in your article, you’ve got a section where you have some nice diagrams which might be worth the listeners actually going to look at. The sections called, decoupling the WordPress editor from Gutenberg. And you make the point that at the moment, the block is bound directly to Gutenberg, you know, there’s an inextricable link between them. And they need to be decoupled. And the block protocol sits firmly in the middle. Is there a lot of work that would need to be done there in your estimation? Does that feel like a huge leap that would happen anytime soon, were this all be pushed forward?

[00:34:12] Leonardo Losoviz: I think it’s going to be a bit difficult, yes. Not because it is difficult, but because the devil is in the details. You know, I believe this is something that you get completely right, or people will not use it. It has to be perfect. And until you get the level of perfectness, it can take five years, like it took with WordPress editor with full site editing, right? Now, I don’t think that they will take five years, but the idea that something so simple can still be quite difficult. I think that will be the case. Now, why do I say this? One thing is what I was saying is that WordPress right now only cares about WordPress, but once it connects with the book protocol, WordPress will need to care about the world.

So it cannot do whatever it wants to do. It doesn’t have that freedom anymore. It will be constrained by rules. And the block protocol is not set yet. It’s a work in progress actually right now is also a draft. There’s no version one dot zero. So these guys are coming up with it. And the best way that you have to come up with it, I guess if I have in a real use case example, right. So I don’t think they have anything on this sort of, because it is still the idea. So you develop an application, they use the block protocol, you will find problems. Problems that had not foreseen.

So what I want to say with this is, the idea is magnificent. The concept is great, but I believe that as they implement it, they will keep finding challenges to make it really usable for everyone in a way that it makes sense, also. You remember bootstrap, right? Like the CSS framework? When bootstrap came out, every single website that was using bootstrap looked the same way.

You can customize it. You have different colors. Fair enough, but all the websites use the same grid system of 12 columns, and you knew it was a bootstrap website. So for instance, one of the difficult things here will be, how do we use the block protocol to create blocks that allow you to create a website that is still personal, that is still unique. That doesn’t look like every other website out there. So everyone that wants to use the WordPress blocks, they don’t want to look like they’re using the WordPress blocks, possibly. They might not want to look cheap. I gave the example of Mailchimp before. Image if Mainchimp used the WordPress blocks and then Mailchimp looked like a WordPress site? It’s like, hey Mailchimp, come on. You are worth 10 billion USD, what’s going on with you? They have to have personality, and a lot of those things, they would be a bit difficult to come up with. Fine, you can have CSS on top of it, but the components that you have inside the block. So as we said before, a block is basically a component, high-level component that is loading other components.

All of that is fixed inside of the block. If you want to have a different functionality, you will need to add it inside of the block. But you cannot add so much stuff because then the block will be bloated. So then it has to be lean, but you still want to have personality that you have to have a functionality that no other website has, et cetera.

So what I want to say is let’s see, let’s see how well, it goes, but I don’t think it’s going to be easy, to be honest.

[00:37:35] Nathan Wrigley: Yeah. It feels like it might be a bit of an uphill struggle. We’d mentioned just before we pressed record on this podcast. To some extent, it brings to mind an XKCD cartoon. I will make sure to link to this in the show notes, but there’s a wonderful cartoon on XKCD where they say the situation is there are currently 14 competing standards. This is ridiculous. We need to develop a universal standard that everybody is covered by that sorts out all use cases. And then soon after that, it says, well, the actual situation after that is, there are now 15 competing standards. And I wonder if we revisited this conversation in a couple of years time, whether or not this would have taken time to move forward, because obviously, you know, the resources to create the Gutenberg project and to push it forward are very limited.

It’s like you say, it took five years to do where we’ve got two so far and I suspect, if we were to rewind to five years ago, the expectation would be that it had gotten a little bit further by then. So I guess I’m just nervous that it might end up being a bit of a dead end possibly and end up consuming a lot of time. The devil, as you say, would be in the detail.

[00:38:51] Leonardo Losoviz: I’m actually hopeful because I think the block protocol is a first attempt to make this. Now it is true, what you are saying XKCD that you have all of the different blocks implemented by different parties, but nobody’s trying to interact with any other block or any other application out there. So this is the first guy who is trying to say, let’s get all the blocks communicating. So in a way, it has credit. Okay, is it not so dire this situation yet? And I’m also quite hopeful because of what happened with Graph QL. That is a specification that, just by complying with the specification, great things may happen.

So what I want to say with this is that the block protocol, you develop it, you put it out there. And you let the community react and they might actually react in ways that you had not foreseen in advance. They can surprise you. You can actually create magic out of this, that you don’t need to coordinate different teams to work together. With the protocol you’re basically working together, and in this case, what you’re actually doing is having WordPress be used by the world outside of WordPress. And at the same time, you have WordPress being able to reach out to code that was not coded for WordPress. So the potential is so good that even though the path ahead may look broken it may look difficult, I think it’s utterly worth pursuing. It depends on the interest from the community. I don’t know if the community is interested to be honest. If you’re from WordPress, maybe there’s not so much for you to gain from this. If all you see is WordPress. If you will have WordPress now, and you only plan to use WordPress forever more. Yeah. Maybe there’s not so much for you. But, if you are open-minded of thinking, hey, unexpected things will happen from this. Then you can get really excited about this. I’m particularly excited myself.

[00:40:44] Nathan Wrigley: Good. Yeah. That’s great. One of the things you mentioned a little while ago was the fact that at the moment, WordPress is kind of inward facing, you know, the Gutenberg, the output of Gutenburg and all of the things that are inside of Gutenberg. WordPress only needs to worry about WordPress. So, that’s kind of looking inside to what the project needs to achieve for its own goals of democratizing publishing. Do you feel that the fact that if it turned outwards and integrated with the block protocol and thereby had to obey the standards that that brought with it, are there any drawbacks to that? Are there any situations you can imagine where there would be a conflict of interests or things would become more difficult or more time consuming or just not done in a way that they’re done so far? That might cause things to stall.

[00:41:31] Leonardo Losoviz: I think the biggest drawback might be that the world out there doesn’t care about this. And you’re spending your energy. So invite them, to welcome them and nobody cares and nobody comes in and so it was a lot of wasted effort. Of course. I mean, that’s always the case with everything. Like whenever you do an open source project, people may show up or they might not. And therefore for you or the same. The thing is that you have to do it because you have a real use case, that if you’re going to do it, it’s because you know that you will benefit.

If this is just a proposition that you think, okay, this looks good. Let’s try and invest a lot of energy to invite others to come in. And then the community out there, they’re like, yeah, I don’t care WordPress, and I’m happy with what I’m using right now. You know, they moved on to different technologies and you’re trying to convince others and they don’t care then. Yeah, I think that, that’s the biggest issue that if we’re going to do this, there has to be a clear cut use case for WordPress to benefit. Now I did try to say many, several use cases in there in my article, but of course, I mean I’m and dreaming of sorts. If you have an application that can reuse blocks across two different technologies, for instance, WordPress and something else and you already had that. So for instance, okay, you have a technology, a company like Stripe that they need to cater to different technologies, they cater to PHP and they cater to JavaScript, to Go and to everything else because they provide APIs to connect with them and they have an interface or they maybe have different applications powered by different technologies.

Then they will certainly benefit. So we need to be sure that when we go for, forward with this idea, that we have a real use case that we wanted and that we’re not trying to impress all the time to somebody and then they don’t get excited. They don’t come in and, it was wasted effort. I think that’s the biggest potential drawback. Conflict of interest that you mentioned.

I don’t know. I don’t think so. I haven’t thought about it, but Matt Mullenweg way was to make the open web open, open, open. Just now, he created, he bought the Openverse. Yeah. Yeah. So you might actually think conflict of interest. Yeah. I’m sure he will have conflict of interest that doesn’t stop him. As in if he has to give something for free, that will compete with some paid commercial product, or there, he will do it anyway.

I cannot think of a conflict of interest in this case, but I don’t think that that would be a reason enough to know to not do it. At least based on previous experiences.

[00:44:14] Nathan Wrigley: When we’re recording this, which is in March 2022, as far as I’m aware, there’s been no more public outpourings of whether this will go on. The debates, not debate, but the Twitter thread that was begun between Matt and Joel, I don’t think it’s been updated too much. Do you have any insight or is it exactly where we were a couple of weeks ago?

[00:44:36] Leonardo Losoviz: Yeah, I don’t have any insight. I believe that we are where we were, yeah. I wrote the article on this Smashing in part to try to start this conversation with the community, and yeah, they need to take it up.

I actually, I keep checking the block protocol, the project on the website. They are still developing it, but once again, it’s still a draft. So you can expect this to take a long time, many months still. So this might actually be slow and it ,might be a slow and steady process. I believe.

[00:45:11] Nathan Wrigley: Well, so be it, if that’s the way it needs to be. Really really interesting project. You’ll find all of the links that we mentioned in the show notes.

You also talked about the fact that it would be nice to get this conversation begun. That’s why you wrote the piece. With that in mind, is there anywhere that you make yourself available? Perhaps a Twitter account or some email address or public facing website? Is there a particular place that you would like to mention where we could find you?

[00:45:39] Leonardo Losoviz: Right. Yeah, my Twitter is my surname, which is Losoviz, and my personal website is leoloso dot com. And then my plugin is Graph QL dash API dot com. And then, yeah, basically I’m always around, and I like email, I’m not so, I’m not so big on social media myself. I don’t participate so much. You will not see me really on Twitter.

But if you send an email to me, which you can do through my personal website, I will certainly reply.

[00:46:10] Nathan Wrigley: Thank you very much Leonardo for joining us on the podcast today. I really appreciate it.

[00:46:15] Leonardo Losoviz: Okay, thanks so much, Nathan. Very, very happy that you invited me.