What's Fair Is FAIR ![rw-book-cover](https://i.ytimg.com/vi/zOtOy3oIuXE/maxresdefault.jpg) ## Metadata - Author: [[LoopConf]] - Full Title: What's Fair Is FAIR - Category: #articles - Document Note: --- tags: [WordPress, Open Source Governance, Package Management] author: [MISSING] source: YouTube reference: [https://www.youtube.com/watch?v=zOtOy3oIuXE] date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} --- # 🏷️ Title: What's Fair is FAIR ## 🧰 Action Inbox - [H1] Publish FAIR overview for GoDaddy OSPO — context/https://www.youtube.com/watch?v=zOtOy3oIuXE #articleseed - [H2] Map WordPress.org touchpoints to FAIR replacements — context/https://fair.pm #xref - [H3] Draft privacy note on dashboard UA telemetry — context/https://browsehappy.com #addendum - [H4] Propose Browserslist-based checks for wp-admin — context/https://github.com/browserslist/browserslist #articleseed - [H5] Replace Ping-O-Matic pings with IndexNow — context/https://www.indexnow.org/ #articleseed - [H6] Write “decentralized discovery” explainer for devs — context/https://fair.pm #share - [H7] Define labeler policy for moderation layers — context/https://docs.bsky.app/blog/moderation-service #articleseed - [H8] Start FAIR composer-integration RFC outline — context/https://github.com/FAIRpm #xref - [H9] Prep The WPCC microgrant brief for FAIR pilots — context/https://fair.pm #share #articleseed - [H10] Candidate KPIs for OSPO adoption dashboard — context/https://fair.pm #xref ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - FAIR project home: https://fair.pm - FAIR GitHub org: https://github.com/FAIRpm - IndexNow protocol: https://www.indexnow.org/ - Browserslist docs: https://github.com/browserslist/browserslist - caniuse-db (usage data): https://www.npmjs.com/package/caniuse-db - Ping-O-Matic: https://pingomatic.com - Blo.gs transfer note: https://blog.apievangelist.com/2014/04/25/the-transfer-of-blog-from-yahoo-to-automattic/ - Chrome UX Report overview: https://developer.chrome.com/docs/crux/ *(If blocked, use web.dev summary.)* - Verge reporting on wordpress.org ownership claim: https://www.theverge.com/2024/10/9/24243509/wordpress-automattic-jonathan-bossenger-matt-mullenweg-lawsuit - Bluesky moderation service/labelers: https://docs.bsky.app/blog/moderation-service ## 📝 Summary - Ryan McCue presents FAIR at LoopConf. - FAIR targets secure, decentralized WordPress package distribution. - The plan removes single-entity control in key supply-chain steps. - It proposes privacy-preserving checks and modern discovery. - The bottom line: safer installs, plural governance, and user choice. ## 📖 Main Content - FAIR stands for Federated And Independent Repositories. It proposes discovery, moderation, analytics, and repos as separable nodes. The architecture reduces central chokepoints and vendor capture risk. See FAIR materials. (https://fair.pm) - Technical independence replaces wordpress.org dependencies with site-local checks and open standards. For browser checks, use Browserslist and caniuse usage data. This removes unnecessary telemetry. (https://github.com/browserslist/browserslist, https://www.npmjs.com/package/caniuse-db) - Content pings move from Ping-O-Matic’s defunct targets toward IndexNow. IndexNow is an open submission protocol backed by search engines. (https://www.indexnow.org/, https://pingomatic.com) - Discovery becomes a search-like aggregator rather than a gatekeeper. Users can find packages, then update directly from origin repos. (https://fair.pm) - Safety uses stackable labelers, inspired by Bluesky moderation services. Labelers add attestations for security, copyright, and compatibility. (https://docs.bsky.app/blog/moderation-service) - Analytics live off-path, like Chrome UX Report’s model for the web. Participation stays optional to preserve privacy. (https://developer.chrome.com/docs/crux/) - Governance follows Linux Foundation patterns. Technical and business tracks stay separate to balance influence. (https://github.com/FAIRpm) - McCue notes controversy around wordpress.org control claims. Reporting indicates ownership ties to an individual, raising governance concerns. Treat this as reported, not adjudicated. (https://www.theverge.com/2024/10/9/24243509/wordpress-automattic-jonathan-bossenger-matt-mullenweg-lawsuit) ### 🗒️ Notes #### ⏱️ [00:00:28](https://www.youtube.com/watch?v=zOtOy3oIuXE&t=28) FAIR intro and goals ### [H1] FAIR targets secure decentralized distribution > [!quote] [What's Fair is FAIR](https://www.youtube.com/watch?v=zOtOy3oIuXE) by [an unnamed author] via [[YouTube]]. Published [MISSING]. Accessed {{date:YYYY-MM-DD}}. > “Our goal with FAIR is to improve security in software distribution.” - Security and decentralization sit at the core. - Emphasis on independence from single entities. #### ⏱️ [00:03:11](https://www.youtube.com/watch?v=zOtOy3oIuXE&t=191) No single controller ### [H2] No single entity controls supply chain > [!quote] [What's Fair is FAIR](https://www.youtube.com/watch?v=zOtOy3oIuXE) > “Establish a model where no single entity controls the entire supply chain.” - Aligns with LF norms and OSS resilience. - Reduces systemic risk. #### ⏱️ [00:09:06](https://www.youtube.com/watch?v=zOtOy3oIuXE&t=546) Version checks critique ### [H3] WordPress dashboard sends browser UA telemetry > [!quote] [What's Fair is FAIR](https://www.youtube.com/watch?v=zOtOy3oIuXE) > “Every time you load the dashboard, your browser user agent gets sent.” - McCue argues Browse Happy’s checks lagged. - Proposes site-local checks using industry data. #### ⏱️ [00:12:12](https://www.youtube.com/watch?v=zOtOy3oIuXE&t=732) Browserslist swap ### [H4] Browserslist enables private, current checks > [!quote] [What's Fair is FAIR](https://www.youtube.com/watch?v=zOtOy3oIuXE) > “We can build a regex from Browserslist and run it locally.” - Use caniuse-backed data, not hardcoded lists. - Improves accuracy and privacy. #### ⏱️ [00:13:35](https://www.youtube.com/watch?v=zOtOy3oIuXE&t=815) Pings and search ### [H5] Legacy ping targets no longer help indexing > [!quote] [What's Fair is FAIR](https://www.youtube.com/watch?v=zOtOy3oIuXE) > “FeedBurner APIs don’t work properly anymore and never influence search data.” - Replace with IndexNow for real indexing. - Remove unnecessary data flows. #### ⏱️ [00:16:01](https://www.youtube.com/watch?v=zOtOy3oIuXE&t=961) Data flows to third parties ### [H6] Pings reveal site activity to third parties > [!quote] [What's Fair is FAIR](https://www.youtube.com/watch?v=zOtOy3oIuXE) > “They now have a map of every WordPress site and all the content.” - Privacy risk and competitive data leakage. - FAIR favors minimal disclosure. #### ⏱️ [00:18:52](https://www.youtube.com/watch?v=zOtOy3oIuXE&t=1132) Package reality ### [H7] Real installs already come from many sources > [!quote] [What's Fair is FAIR](https://www.youtube.com/watch?v=zOtOy3oIuXE) > “The reality really looks something like this…multiple sources.” - Mirrors, GitHub, and vendors already exist. - Policy must match reality. #### ⏱️ [00:25:25](https://www.youtube.com/watch?v=zOtOy3oIuXE&t=1525) Discovery aggregator ### [H8] Discovery acts like a search engine > [!quote] [What's Fair is FAIR](https://www.youtube.com/watch?v=zOtOy3oIuXE) > “Introduce a discovery aggregator to find packages.” - First-time find via discovery. - Updates flow directly from origin. #### ⏱️ [00:30:02](https://www.youtube.com/watch?v=zOtOy3oIuXE&t=1802) Stackable moderation ### [H9] Labelers add independent safety signals > [!quote] [What's Fair is FAIR](https://www.youtube.com/watch?v=zOtOy3oIuXE) > “We can have multiple labelers…security, copyright, compatibility.” - Inspired by Bluesky’s model. - Users choose strictness. #### ⏱️ - Summary: Ryan McCue, Director of Product at Human Made and Altis, introduces the FAIR Project — a new initiative to make WordPress more secure, independent, and future-proof. FAIR (Federated and Independent Repositories) aims to decentralize WordPress’s software supply chain, reduce reliance on WordPress.org, and give the global open-source community shared governance over its infrastructure. Learn how FAIR promotes technical independence, enables federated plugin and theme management, and builds a resilient, privacy-respecting ecosystem inspired by the decentralized nature of the web. What You’ll Learn: • What the FAIR Project is and why it matters • How it reduces reliance on WordPress.org • How “technical independence” and package management work in practice • Real examples of privacy-focused, open-source innovation in action - URL: https://www.youtube.com/watch?v=zOtOy3oIuXE Ryan McCue: Thank you very much. hopefully you can all hear me FAIRly well. I will try and project, but microphone should help. So yeah, thanks for, thanks for being here. As Brian mentioned I kind of helped more initiate than organize the event to be honest. But it is so exciting to be here back at LoopConf again. I love LoopConf. I loved all the previous iterations and this one in particular I think is gonna be fantastic. So. I am here today gonna talk about the FAIR Project. Quite a few have heard of it, which is great. So you might have heard maybe the name, you might not know all the details. Today we are gonna go in and have a look at what FAIR is in general and have a look at some of the details, how it works technically, how it works organizationally, kind of impacts that it might have on the things that you all do. Apologies for this not being in full screen. Google slides is terrible, but it's the tool that I had. So we are gonna stick with it. so as Brian already mentioned, I am the VP of Product at Human Made and Altis. We are an enterprise WordPress services agency and hosting company or just entirely working with the enterprise. Um, I'm also the co-chair of the technical steering committee for the FAIR Project which is what I'm talking about today. Also, a core committer to WordPress, though I think it's emeritus committer these days haven't really committed in a while. I'm a member of the security team for WordPress as well. Um, I created and co-led the WordPress Rest API project through kind of initiation as a, a kind of standalone project and then merging into WordPress core itself. I created and originally maintained a request for PHP. I was also the project lead for Simple Pie for a while, and I actually just ran outta room on this slide. There were a few other things I couldn't include, but I have been working with or on, or contributing to WordPress now for I think about 21 years, something like that. It has been like two thirds of my life or more than that. So I've been around in the WordPress space quite a while now, you know, it is, it is my life and I care a lot about the, the WordPress project, about making it successful. So that was really you know, where I started getting into this project called FAIR. So you might have heard of FAIR already. certainly it seems like plenty of you have, you might not know the details. We announced FAIR in June at WordCamp Europe. actually the site event called Alt Control Conference and FAIR, if you don't know, stands for Federated And Independent Repositories. Right? So it's about this concept of sort of decentralization and you know, a few other kind of things around that, around. You know, how do we, how do we kind of create this ecosystem of, you know, independent parts that kind of talk to each other, kind of like John's you know, ecosystem with, with Ghost at the, the center or the Ghost Foundation at the center and then this ecosystem around it. Um, and our goal with FAIR is to improve security in software distribution and establish a model where no single entity controls the entire supply chain. so this is really, you know you might know some of the history of why this kind of project came about. I'll talk about that a little bit, but not too much. It's not, not really the, the kind of point but this is our goal is, is to improve the security and, and kind of remove any central control. We are part of The Linux Foundation which you might have heard of. We have 40 plus organizers. so those are voting members of the technical steering committee. That includes people that you think of as kind of code committers as well as contributors in other technical aspects. So people who write documentation or, you know, help maintain the website or all of those sorts of things. You know, all of that is kind of technical and so we give people the ability to vote and be part of the organization of the project. In terms of technically how the project kind of breaks down. So we have two kind of key components to the project. The first one of those is what we call technical independence. and that is a full replacement for wordpress.org. so you might already know this, WordPress depends on wordpress.org. and it's kind of key part of how things are delivered in WordPress. We wanna make sure that WordPress can exist independently of wordpress.org. and so we have our project for technical independence. And then a big part of that as well is how plugins and themes get distributed. So you know how you install those all of those sorts of things. And that's what we call our package management side of things. And then overarching all of that is the organization, which is the FAIR Web Foundation that is part of the Linux Foundation, as I mentioned, and that has both the technical side and the business side. So we're gonna dive deep into what all of these things mean and you know, how they all kind of fit together as well. But before we do that, let's talk about why FAIR exists. so some of you might already know, you know, some of the background for this. As I mentioned, WordPress depends on wordpress.org. You know, if you've used WordPress, if you open it up right now it will be talking to wordpress.org and using things from there and it needs those in order to run, you might already know that when you go to install plugins and themes, for example, it's pulling those from wordpress.org from the repository, right? Um, but there's also some other things and you know, we kind of had this idea, and I think people maybe generally know that WordPress does some other stuff with wordpress.org, but how much actually is there that talks to wordpress.org? So part of our project was diving deep and finding out all of these places where WordPress relies on wordpress.org. You know, we knew about the plugins, the themes, the core updates, but what are all these other bits? And so we found quite a few other places, you know, places where maybe we're pulling in news or events or things like that. You know, we kind of already knew about a lot of those, but there are things in here that, you know, even I didn't know about and I've been contributing for 20 years. So I suspect a lot of people don't know about these all of these pieces. So, you know, a lot of this relies on wordpress.org. You may have seen that as of September last year a bunch of, kind of controversial stuff has started happening with wordpress.org. I think the, the key kind of piece of that is really this realization that WordPress is Matt Mullenweg's personal website, right? It is not a project or a part of the WordPress Foundation. This is specifically from a legal case that is ongoing and as you can see here, separate from the WordPress software, from Automattic and from the Foundation is a website that Matt supports called wordpress.org. It is not part of the official WordPress project. Now, WordPress.org is great. It has given us very many things over the past, you know, 20 years. but it's very clear that this is a personal website and we are a massive project, right? WordPress runs 40 something percent of the web. We are at a point where we need to be taking ourselves seriously and we need to have alternatives to, depending on a single person and on any single entity in order for, you know, our, our kind of software to exist and to thrive. So we're very grateful for this service that's being provided. But you know, it's time to grow up because not only does WordPress depend on wordpress.org, but we all depend on wordpress.org. And this ecosystem is too important to leave to any one particular entity. So how do we go about fixing this? This is where FAIR starts to come in. As I mentioned, we have a project called Technical Independence, and this is a group that we started basically at the start of the year. We've been talking kind of, you know, over the holidays, you know, since September last year really about kind of doing something about this and we started working on this technical independence project to work out, you know, what are all the pieces of wordpress.org that we need to go and fix that we might need to replace you know, that we need to come up with alternatives to. Obviously as part of this, we discovered brand new things as well. like I mentioned, even I didn't know all of the things in here, and in fact, I think I missed out a couple of things on this slide. I think that, I forgot the, the block patterns, for example. Yeah, those are, those are not in here. So there's a huge amount of functionality and it's really difficult to keep track of all of this. But let's dive in and, and see actually, you know, what do all these things do, right? How critical are they to the operation of WordPress and what are they actually doing on the backend as well? So if we have a look at two kind of parts of this, we have version checks, the WordPress kind of does. So the first one of these is the PHP version checks basically saying, Hey, are you running a supported version of PHP? Is it secure? You know, all of those sorts of things. That seems pretty straightforward, right? We want people to be running the latest and greatest version of PHP. We want 'em to be nice and secure, you know, all of those sorts of things. We also have browser version checks as well. So every time you load up the WordPress dashboard your browser user agent is being checked to see, Hey, are you up to date? You know, are you staying safe on the web? And this is a really noble goal. It comes from a project called Browse Happy which is brought to you by WordPress. Which WordPress, I don't know. It, it's hosted on WordPress.org. So this is part of, you know, Matt's personal website. You might have heard of this project before. It has been around a really long time. It kind of comes from before we had auto updates in browsers, in fact, when this was much more a concern, right? You know, you actually had to think about when you updated your software. and if you are ever running a version of your browser that's out of date, you see this big notice in your WordPress admin. Has anybody in the audience seen this notice in their admin kind of pop up? One. So, so if you have, you must have been in using WordPress for a while because the versions in here have not been updated in almost 10 years. These versions were released in 2017, 2016, and were discontinued about the same time, you know, only a few months later. This is the source code for Browse Happy. This is what runs every single time. So this is clearly not protecting users, right? This is not actually checking anything practical. These versions are hard coded. They're not tied to usage data, they're not tied to any kind of real world usage or anything like that. But that said, the data still gets sent anyway, so every time you load up your dashboard, your browser user agent gets sent to wordpress.org. And this gets collected as analytics on wordpress.org. There is no other purpose for this data to be sent to wordpress.org. As we just saw, the version checks are not being used for anything. Just the user agent getting collected for analytics data by wordpress.org, which again, is one person's personal website. Now, many people probably don't know that this data gets collected. I certainly did not realize when I loaded up my WordPress dashboard, my browser user agent was getting sent off to wordpress.org. and we have no idea how long this data is retained for. We don't know, you know, the details of how it's stored. This source code could even be wrong, right? You know, this might not be the source code that's actually running on the server. Um, so we have no guarantees about any of this. I'm not sure that this is even disclosed in the privacy policy for WordPress org. It's not really considered, you know, user data, and you know, it's possible that it might even breach GDPR. So this was something that we identified we absolutely need to replace this. The good thing is we have solutions for this. So you might already have heard of Browserslist. It's a tool that gets used by things like Webpack, Babel, all those sorts of kind of development tools. And it works using real world data from can I use and from the browser vendors themselves to work out what are the latest versions of browsers, what's actually in use kind of across, you know the, the kind of deployed web I guess. Um, and so this data is kept up to date and its industry standard. Now we can take that kind of data. We can take the information that Browserslist gives us and build a regular expression and build that into your site so that when you load up your site, the checks for, you know, is your browser up to date, run entirely on that site, which you're already accessing anyway, and don't get sent anywhere else. So this preserves privacy. we're not sending data off to a random third party. but also it fixes the user behavior. Right now we actually have something that is useful and in fact we have started getting some issues coming in. People saying, oh, actually like. It's kind of annoying, right? Like now it's actually telling me to update 'cause I haven't restarted Chrome in like three years, right? So this is a case where we can not just, you know, protest something or say we're gonna build, you know, a one-to-one alternative, but we can actually make things better for users throughout the FAIR project. Let's take a look at a different feature. so this is one that you might've heard of as well. This is the pinging system in WordPress. So every time you publish a piece of content on any WordPress site, your WordPress site will send off pings. And the idea of pings is that they tell external services like search engines, Hey, I published something. Come and index me. Make sure that you're up to date with all of this data. Now, again, this is a great sort of this idea for a project. These days, you know, search engines tend to index things very rapidly, so, you know, maybe it's, it's not used quite as much, right. this is a WordPress Foundation project, as you can see in the footer there, WordPress Foundation brainchild, whatever that means. Um, and you know that, that sounds great, but it turns out this is hosted on dot org as well. So this is also on Matt's personal website. but what does this service actually do, right? We can see down here, we have some common services. We have bl.ogs, Feed Burner, spinn3r and Superfeedr, and you might have heard of at least one of these, in particular Feed Burner, right? Feed Burner was a service for updating RSS feeds, indexing those, making sure that they get out to people and it was acquired by Google, right? So surely that data is kind of feeding into the Google search engine. It's helping, you know, Google stay up to date with your site, all those sorts of things. Well, we spoke to some people at Google and they confirmed Feed Burner data is never used anywhere. It's a discontinued product by Google. The APIs don't work properly anymore and it never influences any kind of search data. So this is actually just defunct, right? It's not used anymore at all. But it turns out that's actually not the only one. If we have a look at the other services here, you might not have heard of these, and that's because at least two more of them have also been discontinued. Spinn3rs website no longer works at all, so I don't even know where that data gets sent and Super Feeder, I think was also acquired by somebody kind of shut down, kind of doesn't really work either. So that leaves us with one service left over that we're pinging which is called bl.ogs or B-L-.-O-G-S. so every time you know, you're publishing a piece of content, you know, pings are getting sent by your site to ping-o-matic. Those go off to bl.ogs. Does anybody wanna guess who owns bl.ogs? That's right, it's Automattic which is Matt's company. So every time you publish a piece of content on your site, it sends a ping off to wordpress.com and to Automattic that says, Hey, I've published a piece of content. This is extremely valuable data, right? They now have a map of every WordPress site and all the content that's getting posted everywhere. that is not good for privacy and it's also not achieving the user aim here. This is not actually helping any search engines kinda keep their index up to date. So again, let's replace it. Let's not just replace it with our own kind of system. Let's replace it with something better. And it turns out there is a something better for this. It's called Index Now. It's an open standard that was created by search engines themselves, including Microsoft, Bing which feeds data into a lot of other search engines, right? They make their index available and this is a kind of decentralized sort of protocol. So a bunch of search engines joining on this. You send a ping off to one and it, it kind of copies that out to all the others as well. This is an actual standard that gets used by actual search engines, and so it's actually useful. Um, and this is again, fixing that kind of user issue as well. So we're actually improving the functionality that we have, not just protesting or, you know replacing it for the sake of it. So this again, is just one of those other pieces. If we have a look at all of these services that are getting sent to wordpress.org and you'll also note as well, there's Gravitar is in here as well. Gravitar is a great service, but it is run by Automattic. It's worth noting that. We can start thinking about the replacements for all of these services and come up with something that looks a little like this. Now, I recognize this is not the most readable slide in the world but you can see on the left hand side there's a few items that now run entirely on your site. So data never gets sent anywhere else. We preserve privacy, we kind of keep all of that stuff within your site. And then for the other kind of aspects, we use the industry standard kind of best technology that exists. Ideally things that we don't have to run ourselves, you know, like John said, it is a pain kind of running actual services and having to keep things up. Um, certainly I get annoyed when I get pinged on my phone that the site has gone down. So we want to run as little as possible. Now we do have to run some, in particular, the news and the community events. We have to run APIs for that 'cause. No one else has that data. But for things like PHP version checks, well what if we talk to php.net directly? Right? They have an API. For things like emoji, for example, rather than using who knows what, we can actually use a common CDN that people might actually have cached in their browser. So this is all about kind of technical independence work. And we launched this back in June as part of our kind of first public version that we released, which was 0.3. Um, but let's zoom in on one part of this that I haven't kind of touched on, which I guess is a, a kind of very big part of this which is plugins and themes. So in this diagram you, you might be able to read at the top, maybe not, it's a little small. Sorry. We swapped this out for a service called AspirePress, which is a mirror of WordPress dot org's packages. Um, but you know, we kind of wanna get a little bit more complex than that. We don't just wanna kind of copy what was there before. We wanna actually improve the ecosystem. So this is where the second kind of half of FAIR comes from. This is package management. So every time you think packages, that means plugins and themes. They're kind of the same and so we call them packages just to kind of make that a little more simple. So in this diagram, in in kind of your brain, you might be thinking, okay, yeah, when I get plugins and themes, I download those from the WebPress.org repository. I install those, you know, maybe I open up the WordPress dashboard, I hit, you know, add plugin, those sorts of things. You know, packages come from wordpress.org. Right. Now, particularly since September and since, you know, people have started realizing that depending on dot org, it's maybe not the best thing in the world. A lot of hosts have started running mirrors of this. And so actually your sites might be getting it from a mirror of wordpress.org instead, right? Not actually going to WordPress.org. But practically speaking, that is still controlled, you know, the same way. Right? It's all part of this one you know, big entity. But this mental model of thinking about, you know, we download our packages from dot org is wrong, right? You know, I'm sure that everybody here has downloaded at least one plugin from GitHub, right? You might have premium plugins that you are, you know, buying from a third party, installing those, et cetera. You might have private code as well. So the reality really looks something like this, right? So we have multiple sources multiple repositories that we're getting all of our packages from. Once you install those you know, maybe you're only installing it once, then you have to go download it again each time. But in a lot of cases, these packages now start to include their own self update, right? So they might update directly from GitHub. They might you know, talk to the premium plugin API, check your license key and also see, you know, are there any updates available. So in practice what this means is a lot of our sites are talking to a lot of these sources, a lot of these repositories all the time. But this model has some problems. So the first one is that third party packages can't be installed, right? When you go and find something for the first time, you have to go find it somewhere else. You can use Google, you can go check GitHub. You know, maybe you use something like WP Beginner to find out you know, what kind of great plugins are available but you have to go get those from somewhere else and then bring them into WordPress. That is really not a great user experience, right? The best user experience would be I open up the plugin screen, it shows me all the plugins that are available. I search for, you know, SEO or something like that. and I go and install that. Great. That's that's solved my problem. So this is a bad user experience more than anything else, right? It's also terrible for developers because you know, you have to kind of think about how that whole system is gonna work and everyone is gonna build a solution to that differently, right? You might include a self updater kind of library in your, your code. you might include something like EDD software licensing or getup data or, or those sorts of libraries. Or you might go build something yourself. So this is, you know, really inefficient for us as developers, but it's also really inefficient for your site, right? Because now it's got, you know, if I have 20 plugins installed, it might have 20 different update kind of processes that are built in all talking in different ways to these kind of external services. It's also hard to stay safe, right? We wanna make sure that users are protected against malware, against, you know, bad kind of plugins that might be masquerading to be something else. Um, you know, we know WordPress doesn't always have the greatest kind of security reputation, and a lot of that comes from the entire ecosystem, right? Um, the, the WordPress ecosystem is massive. you know, we talk about, oh, there's 60,000 plugins. Well, that's just on wordpress.org, right? You know, there are probably the same number again, if not more hosted elsewhere. Um, but everything that's not on wordpress.org, we can't kind of keep users safe from that, right? There's no, there's no kind of middle ground here. It's either fully moderated on wordpress.org where, you know, there's a team that kind of looks at these things. Or there's nothing, right, there is just whatever guarantees some random website has kind of told you. That's no human review, no automated scanning, no vulnerability checking, all of those sorts of things, and even the mirrors that I mentioned before could also be unsafe as well. Right now, mostly you tend to trust your host, but you know, there's nothing that says that they couldn't, you know, change a package, for example, um without you knowing about it. And the fourth problem is that developers can't even offer a solution to this, right? The wordpress.org policy say you can't go and get updates from somewhere else. You can't, you know, actually build a, another kind of store or something into WordPress itself. So there's not even a, a good kind of solution to this that users can kind of go and use. Um, and there's some good reasons for that, right? Like some of the safety issues, right? We don't want people installing things outside of dot org you know, 'cause they could be unsafe. But the reality is users are already installing these things anyway and so, you know, how, how could we actually keep them safe, recognizing the reality of the situation? So if we go back to this kind of worldview, you know, this is how the system already works, right? This is not a, a system that we're trying to create. This is what, you know, your sites what the ecosystem already looks like. So we already have a bit of an idea of this alternative of, you know, not dot org, right? Some sort of decentralized thing. So what if we could like, adapt this into some sort of system? What if we could standardize this? all of these parts here, you know, they have different names, but fundamentally they're the same, right? They are repositories, they are places where we go to get these packages from. Um, now does this system already exist? Is there something similar to this? you know, maybe not even in packages. Maybe there's just I don't know, some sort of analogous system elsewhere. And it turns out that this system is kind of like the web itself, right? You open up your browser, you go to a website, that browser talks to that website. There's no other third party involved. You know, you don't need to go ask for permission to go view your website. You just open it up, type the URL in and, and you're good. But this also kind of, you know, reveals a part of the same problem that we have as well, right? How do I find a website in the first place? You know, if I don't know that the facebook.com exists, how do I go and find the Facebook? Um, turns out we kind of solved this problem for the web already, right? We invented search engines which allow us to say, I've got a vague idea of what I'm looking for, you know, go and show me all the solutions for this. And that's great. That's exactly what users are looking for. And we also, you know, if you are a very old school web, you might think about like a web index or a web directory, right? Um, that might even point the way for, I don't know what I'm looking for yet, I just wanna see what's available. So we've kind of solved this concept to some degree. We use a search engine the first time to discover brand new things. And then once we know about those, once we've found out, hey, these exist, we can just go directly to them from then onwards. So we can take that model and we, we apply it to the system that we have, right? We have the repositories that are hosting all of these packages. We can introduce a new kind of search engine or what we call a discovery aggregator. Now this is a way for users to find these packages, right? This can go out and it can kind of index the web in a way, right, you can go and find all the repos that exist and users can use this discovery aggregator to find out about new packages. Um, now again, just like that web analogy, once the sites have found these packages, they can still do updates and they can talk directly to the repositories, which again is the system we already have. The great thing about this though, in particular. Is that there can be multiple of these discovery aggregators, right? Just like there are multiple search engines, right? You might use Google and Bing and is it pronounced Kagi? I have no idea how you pronounce it, but there are all these sorts of alternatives that are available, and that is one of the beauties of the web, right, is that there is no central authority over the web. There is a, you know, this ability for things to exist next to each other, right? We can have a WordPress and a Ghost. We can have a Google and a Bing. and this allows for competition between these, right? We can see which of these is the best. Users can pick. Hey, I like this one better. You know, maybe the search results on this engine are worse, but there are other benefits, right? Maybe it's an eco search engine or something like that. So, you know, this sort of decentralized system is something that we're already used to with the web, but this system also has some challenges of its own. And the first of these is analytics and feedback, right? We rely on things like. How many installs does a plugin have? or what is the rating on that? And that gives us a kind of idea of, you know, is this a safe plugin? Is it a good plugin? Right? How do we keep track of that in a decentralized world where there's no kind of, you know, central authority telling us what to think about these things. The second is moderation and safety. So already kind of mentioned that, you know, the, the safety of these sorts of things can be quite difficult when we're looking at you know, things that are hosted elsewhere. How do we still kind of retain that and how do we keep that, you know, over time, basically? Um, and in a decentralized system as well, how do we make sure that users are getting the right package, right? The one that they intended to get and not someone that is just pretending to be someone else, right? The web does have this problem, right? You know, we, we all hear about phishing attacks all the time. How can we go about solving those sorts of things? So if we take a look at the first of these problems, part of the issue with, with getting analytics and finding out what things are used is that there's no kind of central place that knows about the entire system, right? There's no one kind of entity that we can ask for all of this data. But what if we introduce something like this, right? You know, we can have a decentralized system, but have this analytics kind of central piece off to the side. Now if we do that, we need to make sure that it's critical that that is not a key part of this. The whole system can work without it. but it allows us to kind of learn some things about it. And this is quite similar to say, on the web. You know, we have the Chrome user experience report, right? That tells us about how Chrome users are using the web. It's not a critical part of the web. It's not necessary for any, any parts of the web to actually function. But it gives us really interesting and useful data about the web by being this kind of side service. By having this as a, a kind of independent third party as well, it can be kind of neutral, right? It can collect this data and it can give that out to you know, anybody who asks for any of that data. Um, that also makes it really easy for users to opt out of any kind of data collection if they want to. So then secondly, how do we tackle the problems of moderation and safety, right? how do we keep users safe no matter where they're kind of pulling packages from? Turns out a lot of smart people have already been thinking about this. And in particular, Bluesky has created this, what they call a stackable approach or what we can kind of think of as layers of, of moderation. Where you can have multiple services that you subscribe to that each give you different information about, you know, the things that you're looking at or, or et cetera. Um, they call this a labeler because it basically says, Hey, here is you know, a user account, or here's a post or something like that. and here's some labels that we might apply. So that could be like, oh, this violates copyright, or this is unsafe. Or, you know, it can also be positive things. Right? You know, this is being verified to be true, or something like that. So we can take that same kind of system and apply it to ours. So again, we can have a service off to the side called a labeler which, you know, tells us about all the packages that might exist. Now to do that, we have to have unique IDs for all the packages that we have, but once we have that, then any kind of labeler can exist. And in fact, we can also have multiple of these labelers, right? We might have one that checks for security scanning, right? Um, or we might have something that checks for copyright violation. We might even have human moderation involved in here as well. You know, your web host could offer a labeler that says, Hey, this is compatible with our platform, or it's not. Um, and an important point here as well is none of this goes to the repositories, right? You can't control how people are talking about you. You can't control, you know if you're a hotel, you can't control you know how people talk about you on TripAdvisor, right? These are independent parties that are checking, verifying, and labeling. Um, so this system allows us to introduce this concept of moderation and safety into a decentralized system. And we can also give users the choice on how to handle some of these things, right? You know, you might wanna say, Hey, look, I don't wanna install anything that's unsafe or insecure. but if it's just incompatible with the platform, well, I can probably work around that, so I'll ignore those warnings. Right? Again, borrowing from the Bluesky concept here of this decentralized labeling. So this offers users a even better experience. So this is the approach that we are taking with FAIR, it is built in moderation. So we are gonna offer a moderation service of our own with some sort of human review and allow additional layers of that kind of labeling to be built on top. Um, we're going to kind of make this available to the ecosystem and users can kind of pick exactly what they want to use, how they wanna build their experience and part of this as well is that we can also make a choice on who we federate with, right? You can have a fully open network but particularly when you're a small network, you might wanna keep that controlled. This is something Bluesky did. They kind of built out the decentralized aspects and it's something that we're doing as well. So we're taking a cautious approach to federation. We're only gonna bring in repositories that we know are kind of trusted as we start up and then expand that to a fully open system over time. Once we build additional trust layers on top. So this approach helps us solve both the kind of moderation problem and the provenance problem as well, making sure that users have the right package, but we need some additional kind of solves for the provenance problem, right? Making sure people have the right package. So one of these that we can take, again, from that same social media concept where, you know, this is a very common thing, is to use domain validation, right? Users already have a concept of a domain being correct or something like that. and so we can build on top of that with DNS verification. we can also show the host information, right? We can show where is this coming from and is that something that I as a user might want to trust. Now, not all users are gonna care about this. That's fine. We need to make sure that we're kind of giving them the information though so that they can make a decision. and by giving everything a completely globally unique id, we can make sure that no matter where this moves, you know, we're always kind of keeping it the same. We know exactly that it's the same package. And this is something where we can expand this over time. So we have a working group that is working specifically on trust to try and build out additional layers and additional systems on top of this. So if we put the whole system together, this is how this kind of looks. We now have our discovery, we have our labeler, we have our analytics service, and we have a bunch of repositories as well. And our sites talk to all of these all the time. So it's a very decentralized system. Practically speaking, we are gonna run one of each of these kind of nodes as well. So we'll run a discovery service, we'll run a moderation service. We will run a repository so you don't have to go and, you know, run all the infrastructure yourself. And we'll also run the analytics service. But anybody can go and run a repository and there's nothing that says that you can't run any of these as well yourself, right? You would just set them up next to ours instead. So this is how we build this decentralized system. But if we're gonna run these services, you know, we have to prove that we are kind of worthy of this trust as well. So, you know, that's where we then get into our organization and the structure, how the project kind of comes together, basically. So how do we make sure that we are trustworthy if we're gonna run these things? How do we create open, transparent governance which supports and balances both the community and the commercial with structures to make clear consensus decisions? Well, we start out just like any other open source project, you know, we maybe have a couple of, of groups of people who are working on different things. You know, a couple of repositories, some releases of code within those, and the contributors as well. But then we take the best practices that the ecosystem and the kind of community have already been thinking about, right? We are not alone in this, you know, just like the concept of kind of reaching out to make sure that nothing is an island. We should have a look at what's happening in open source. And it turns out there are models for this. there is a particular model where we have a technical steering committee. So this is people who are common contributors, who are well-known contributors to the project get the ability to become organizers. You know, you can kind of think of them as kind of the committers, right, in WordPress. but this includes things like documentation and et cetera as well. Where, you know, they're not necessarily writing code, but they're still technical contributions. These then form the technical steering committee, which is, you know, the group of all the contributors and they get to vote on who leads that group. So we have three co-chairs, that's myself, Mika Epstein, and Carrie Dills. We were elected a couple months ago onto our second term to kind of lead this body. For the most part, we still make decisions, just like any other open source project where it is all consensus based. but then the co-chairs can kind of break any ties if needed. We introduced the business side of things as well. So we can have corporate sponsorships through a governing board. And this is all handled as part of the Linux Foundation where we kind of keep the, the business side, you know, a little separate to the technical, right? We don't want any one party to have any, you know, strong control over the technical side. we wanna make sure that you know, this is, this is all kind of handled nicely while still providing us feedback and, and, you know, money at the end of the day, right? These things cost money to run. So we want to have this sort of corporate structure. So that governing board can fund the project, they can provide guidance, and they can also do things like outreach, right? So that includes marketing efforts or running events or you know, PR or things like that. But they don't have to handle that all themselves. We can still have our kind of volunteer teams as part of that as well. So we kind of can build everything together in that way. So if we put all those pieces together, it's gonna look a little complex. We have this big diagram and this is a bit complex, right? But this is what, you know, kind of mature, large projects look like. And that complexity is there for a reason, right? We're separating out the business side from the technical side to make sure that we keep that kind of independence. It's a model that is used by Linux Foundation projects and it's used very widely throughout the ecosystem. Um, so this is something that, you know, there's a lot of experience kind of doing. So how kind of does it practically come together? We have several different projects and loads of contributors. We have three primary projects in the FAIR project. We have the plugin, which you can go and install on your site. We strongly recommend doing so. you can go and download version 1.0 which just came out this week. There's also the mini FAIR repo, so if you are publishing plugins or themes, you can run that yourself to kind of make them available in the FAIR ecosystem. And then we have our discovery aggregator which is AspireCloud. So they kind of join forces with us and we're all working together as part of the FAIR project. All of these are obviously open source. You can download them, you can run them yourself and try them out. We have some other projects kind of around as well. AspireExplorer allows us to browse that kind of just on the web fare.pm/packages. We have a website and we have those other aspects that I mentioned, the labeling or moderation service, and the analytics service coming soon as well. So you can find us on GitHub, uh github.com/FAIRpm. or you can find us, us on Slack at chat.FAIR.pm, open Slack. Anybody can kind of join in and we would love to see anybody and everybody there as contributors. So thanks very much. Brian Richards: Amazing. Thank you Ryan. we do have a couple of minutes. Do you wanna take a couple of questions? Ryan McCue: I'm happy to take questions. Yes. Brian Richards: Okay. Another dangerous moment. Who's got some awesome questions? I saw this hand first. Oh, we got a lot of questions for this one. Okay, here. Question: Thanks. thanks Ryan. That's really clear at helping me think about how the FAIR Project works. One thing not mentioned that's quite a dependency in the WordPress ecosystem is W packages. you know on the developer, I install most things through composer and never touch the plugin install screen. So is there gonna be a way for the discovery aggregators to expose that to Composer? Ryan McCue: Yeah, absolutely. So it's something that we've been thinking about. There's I didn't mention, but on our GitHub, there's a whole discussion section. There's actually already a discussion about the integration with Composer. Certainly for, you know, a lot of developers, including myself, composer, is the way that we install packages. So something that we're very, very kind of focused on thinking about. We haven't built anything to integrate with it yet, but the way that the system works is actually partially modeled on Composer. So including things like requirements for other packages and things like that. So we hope to be able to bridge those in the future and make it available both ways effectively. Um, and that would still give you, you know, all the benefits of the FAIR system, the fully decentralized system. It's worth noting as well, actually, composer is not really decentralized by default, so it relies on a service called Packagist which is you know, a great service, but it is a central service. Um, and so there are ways actually that we can potentially benefit the Composer ecosystem out of this as well. Now we don't have the technical solution for all of this yet, but I think we have an idea of how we wanna head there. So, you know, if you're interested in you know, seeing how that might work, we encourage you to contribute and come join us. And, you know, even if that is just discussing ways that it might work and, and thinking about possibilities, we are open to all contributions. You know, we would love any help that you might be able to offer. Brian Richards: Amazing. All right, perfect. Courtney. Question: Courtney Robertson at GoDaddy. As a contributor to FAIR, one, can we ask those that participated to stand for just a short second? Ryan McCue: Yeah. If, if you're in the FAIR project, please stand up. I think I know who you are in this room. It includes Courtney who's asking the question. so it's a bit of a plan. Question: Come, come talk to us later. That'd be great. Other question, now that. Version one has been deployed and we're going to probably see an uptick in organizations that are testing this and plugin theme companies getting out there. There's a lot of work to be done. Could you share maybe any specific areas that we're seeking contributors in, not just come contribute whatever you could contribute, but like what are the big needs that we have right now? Ryan McCue: Yeah, good question. I mean, to be honest I'd almost throw the question back to you because because I feel like maybe you have things in mind, but we have a huge amount of work to do. You know, we are building an ecosystem from the ground up here and we're designing this not just for WordPress, by the way, this is usable by any CMS. I'm looking at a couple people in particular. We are designing a, a very big system here, and so there's a lot to do, right? We have not started on the, the labeling services yet. We know kind of how we're gonna head that direction. Bluesky is open source, so there's a lot that we can take from them, but there are things that we'll need to solve ourselves as well. So around moderation and trust, there's a huge amount of work yet to be done there and as well with the kind of policy aspects, right? You know, what do we trust? How do we kind of think about that? So that, that is a big area we could use contribution. We need more documentation, right? We have been heads down focused on actually building a lot of this, and documentation is something that we have been working on, but it's still very much needs help. And, you know, with all documentation you know, the, the kind of more, you know, eyes that you have on that, the more aspects that you can consider you know, the better that that is. So there are certain people in the audience who are on the, the documentation working group. I'm looking at Courtney and Taco. You, you can both kind of help people. So that is something that, that we very much do still need help with. And a lot of the core protocol itself, right? We're, we're going very rapidly through building this and we still need more help building out the plugin and AspireCloud and AspireExplore. We only launched 1.0 this week. Right. I, yeah. Thank you. Thank you again, plant clap. But yeah, we only tagged 1.0 on Tuesday, so, you know, we are just starting this long journey. As I mentioned, I've been around WordPress for more than 20 years at this point, right? I am very invested in this ecosystem and I don't wanna see it, you know go anywhere bad, right? I don't want to, I don't want it to collapse or anything like that. So, you know, I'm very invested in making sure that this is a project for the long term. And I think all of the contributors, you know, many of whom are, you know, long term contributors as well, are all very invested in this ecosystem. So we see a long journey ahead of us and we're looking for loads of contributors and we wanna grow this over time. And yeah, we, we think that we have the right structures in place, but we also think that we haven't got everything perfect. So, you know, we'll have to iterate on that as well. Brian Richards: Amazing. Okay. another round of applause for Ryan. Thank you., What's Fair Is FAIR, LoopConf, 01k982g2gp5tfvg68wthtdpzsz.