## Theme This lecture introduces the FAIR project, a federated and independent repository ecosystem for WordPress. It aims to eliminate single-entity dependencies on WordPress.org, enhance privacy and security through local checks (e.g., Browserslist) and modern indexing (IndexNow), and deliver decentralised, standards-based package discovery and management. Governance is transparent with a technical steering committee and foundation support. Initial components, including a WordPress plugin 1.0, discovery services, labelling, and analytics, are open source and self-hostable. ## Takeaways 1. Introduction of [Speaker 1] as CEO of a WordPress services agency, host, co-chair of the technical steering committee for the FAIR project, WordPress core committer, and member of the WordPress security team. 2. [Speaker 1]’s 21 years of involvement with WordPress, including creating and co-leading the WordPress REST API as a standalone project prior to merging into Core; previously led Simplify; extensive workflow leadership. 3. FAIR project announced in June in Europe at the SIAMEC World Conference; FAIR stands for Federated and Independent Repository. 4. FAIR’s overarching goal: improve security, reduce single-entity dependency, and support a federated, independent ecosystem for WordPress-related infrastructure and distribution. 5. FAIR organisation: Fair Work Foundation, part of the Mixed Foundation; technical steering has 40 plus organisers (voting members) spanning core committers and broader technical contributors (implementation, website maintenance). 6. Two key components of FAIR: 1) Technical independence (a full replacement for WordPress.org dependencies to ensure WordPress can operate in any model), 2) Package management (modernising plugin/theme distribution beyond WordPress.org). 7. Problem statement: WordPress (software) relies on WordPress.org (a website not part of the official project) for numerous functions (plugins/themes repository, news, events, patterns, version checks, etc.), creating centralised dependency and privacy risks. 8. Version checks highlighted: PHP version checks (ensure supported, secure PHP), and browser version checks (BrowseHappy), which send the browser user agent to WordPress.org on every dashboard load. 9. BrowseHappy data staleness: versions hard-coded from 2016–2017; not tied to usage data; not updated in almost 10 years; effectively not protecting users; user agents collected for analytics without clear disclosed purpose or retention; potential GDPR issues; source authenticity uncertainty. 10. Proposed solution for browser checks: use Browserslist with real-world data from Can I Use and browser vendors; generate a regex embedded in-site; perform checks locally to preserve privacy and provide accurate, actionable guidance (e.g., prompting users to update browsers). ## Highlights - ` "This ecosystem is too important to leave to anyone in particular."-- [Speaker 1] 《FAIR project lecture (announced at the SIAMEC World Conference in June)》 ` - ` "We are taking a cautious approach—only bringing in repositories we can trust as we start up, and then expanding to a fully open system over time once we’ve got additional cross layers on top."-- Speaker 1 ` ## Chapters & Topics ### FAIR (Federated and Independent Repository) overview > FAIR is an initiative to reduce WordPress’s dependence on WordPress.org and other single-entity services by building a federated, privacy-preserving, standards-based ecosystem. Announced in June in Europe at the SIAMEC World Conference, FAIR operates under the Fair Work Foundation within the Mixed Foundation and has 40 plus organisers as voting members of its technical steering. It targets both technical independence from central services and a modern package management model for plugins and themes. * **Key points** * Announced in June at the SIAMEC World Conference (Europe). * FAIR = Federated and Independent Repository. * Governance: 40 plus organisers with voting rights; includes core committers and technical contributors (implementation, website maintenance). * Organisational umbrella: Fair Work Foundation under the Mixed Foundation. * Two pillars: technical independence and package management. * Goal: security improvement, privacy, removal of single-entity dependency, and better UX for distribution. * **Explanation** [Speaker 1] framed FAIR as a response to structural risks created by reliance on WordPress.org, a website separate from the official project that nonetheless provides critical runtime services (plugins/themes repo, checks, news/events). By establishing a federated model, FAIR allows multiple providers, open standards, and localised functionality to replace or complement centralised services. Governance via a diverse technical steering ensures community input and reduces unilateral control. * **Examples** > In June, FAIR launched version 0.3 of technical independence, introducing replacements for functions previously tied to WordPress.org. Examples include reworking version checks to avoid external analytics and adopting open standards for indexing (IndexNow), while keeping some unique data services (news, community events) within FAIR-run infrastructure due to their specificity. * Identify functions tied to WordPress.org (version checks, pings, repository access). * Replace with local and/or standards-based alternatives (Browserslist, IndexNow, authoritative sources like PHP.net). * Retain unavoidable unique-data services under FAIR stewardship. * **Considerations** * Maintain privacy by avoiding unnecessary telemetry (e.g., user agents to WordPress.org). * Prefer open standards with broad vendor support (e.g., IndexNow) over proprietary endpoints. * Ensure governance remains multi-stakeholder (40 plus organisers with voting). * Minimise operational burden by leveraging authoritative sources (PHP.net) and robust CDNs where possible. * Acknowledge some services require hosting due to unique datasets (news, community events). * **Special Circumstances** * If a service is uniquely tied to community data (e.g., events), how should it be addressed? Host limited FAIR-run endpoints with transparent governance and policies. * If external replacements exist with better data quality (e.g., PHP.net, Browserslist), how should integration be handled? Integrate directly and keep processing local to the site. ### Technical independence from WordPress.org > A systematic replacement of WordPress runtime dependencies on WordPress.org with local, authoritative, or standards-based solutions to improve security, privacy, and resilience. * **Key points** * Identify all touchpoints where WordPress calls WordPress.org (plugins/themes, news, events, version checks, patterns, emoji, etc.). * Replace browser version checks: stop sending user agents to WordPress.org; use Browserslist + Can I Use/vendor data locally. * Replace PHP version checks by querying PHP.net or embedding authoritative version policy locally. * Replace pinging with IndexNow instead of legacy endpoints (Blogs/King-o-Matic, FeedBurner, Spinner, Superfeed). * Shift some functions to run entirely on-site to preserve privacy; use industry CDNs for assets like emoji when appropriate. * Recognise Gravatar and similar services as external dependencies and evaluate alternatives or mitigations. * **Explanation** [Speaker 1] detailed how legacy mechanisms like BrowseHappy are outdated (hard-coded versions from 2016–2017, not updated in almost 10 years), yet still collect user agent data on every dashboard load for analytics without clear privacy disclosures. Technical independence replaces such calls by embedding accurate, current logic derived from Browserslist within the site. Similarly, the legacy ping infrastructure largely targets discontinued or irrelevant services and routes to an Automattic-owned endpoint, creating privacy risk. IndexNow provides a modern, decentralised method aligned with actual search engine practices. The broader effort audits and replaces each dependency, launching initial deliverables in 0.3 (June). * **Examples** > Instead of sending user agents to WordPress.org, the site embeds a Browserslist-derived regex compiled from Can I Use and vendor data. Browser checks happen locally; users see up-to-date prompts (e.g., being told to update Chrome after years), improving security and privacy. * Gather authoritative browser usage and version data via Browserslist. * Compile a regex or equivalent and bundle with the site. * Perform checks locally; store no telemetry externally. > WordPress’s publish pings currently notify multiple services, many of which are defunct; the remaining Blogs/King-o-Matic endpoint routes to wordpress.com (Automattic). FAIR proposes IndexNow pings, which propagate to multiple search engines (including Microsoft Bing) and reflect current indexing practices. * Remove/disable calls to defunct endpoints (FeedBurner, Spinner, Superfeed). * Implement IndexNow client logic to notify a single endpoint that fans out to participating engines. * Validate delivery and monitor effectiveness via search engine documentation. * **Considerations** * Audit all WordPress.org touchpoints, including less-visible ones (patterns were noted as missed initially). * Preserve privacy by default; no data sent externally unless essential and disclosed. * Use authoritative sources for versioning (PHP.net), and well-governed CDNs for static assets. * Minimise operational overhead by avoiding running services unless data uniqueness requires it. * Document GDPR considerations and update privacy policies where any telemetry exists. * **Special Circumstances** * If an external endpoint’s source code cannot be verified against production, how should risk be handled? Treat it as untrusted; move checks local or to verifiable authoritative sources. * If privacy policy omissions are discovered (e.g., user agent analytics), how should compliance be addressed? Cease external data transmission; update policies; implement local processing. ### Federated package management for plugins and themes > A model where WordPress sites can discover, install, and update packages from multiple repositories (WordPress.org, GitHub, premium vendors, private sources) via a discovery layer analogous to web search, improving UX, security, and repeatability. * **Key points** * Reality today: sites source packages from .org, GitHub, premium APIs, and private code with fragmented update paths. * Problems: poor in-dashboard discovery for third-party sources; inefficient and varied update mechanisms; security/malware risks; trust issues with mirrors; policy constraints hinder better solutions. * Vision: introduce a discovery layer (search engine-like) that indexes multiple repositories; enable in-dashboard search/install; updates pulled directly from original repositories. * Interim: SpirePress as a mirror of WordPress.org packages; longer-term: true federated ecosystem beyond mirroring. * Security improvements: verification, provenance, optional moderation layers rather than a single central gate. * **Explanation** [Speaker 1] mapped the current fragmented ecosystem where users often Google or manually fetch GitHub zips for first installs, then rely on many different update mechanisms, creating a poor UX and security lapses. FAIR proposes a discovery service that indexes multiple repositories, allowing users to search (e.g., SEO) and install directly within the dashboard, while updates come from the authoritative sources. This mirrors how the web evolved: decentralised hosting with discovery via search engines. It acknowledges policy constraints and seeks to formalise safe multi-source workflows. * **Examples** > Just as the web doesn’t require permission to visit any URL, the package ecosystem can remain decentralised. Discovery services index repositories and present results inside WordPress admin, while installations and updates occur directly from the source repositories. * Define a standard package metadata schema consumable by discovery services. * Implement in-dashboard search backed by federated indexes. * Route updates to the authoritative repository endpoints, preserving provenance. > Move from binary moderation (only .org reviewed vs. zero review elsewhere) to layered trust signals (signatures, provenance, vulnerability disclosures, optional community or third-party moderation), applicable across repositories. * Adopt signing and provenance standards for packages. * Integrate vulnerability feeds and disclosures into discovery and update flows. * Allow optional moderated feeds without enforcing a single gatekeeper. * **Considerations** * Design metadata standards and APIs for repositories and discovery services. * Preserve user choice while surfacing trust signals and warnings. * Provide clear UX for initial install from third-party sources within admin. * Ensure compatibility with premium vendor licensing/update models. * Support mirrors like SpirePress as fallbacks while encouraging direct authoritative sourcing. * **Special Circumstances** * If a repository becomes unavailable, how should updates proceed? Fall back to mirrors (e.g., SpirePress) with clear provenance warnings. * If a package has mixed trust signals (e.g., unsigned but widely used), how should it be addressed? Present risk information and allow informed user choice with safeguards. ### Privacy, security, and compliance implications > FAIR’s replacements aim to eliminate unnecessary data collection, align with GDPR principles, and improve practical user security (accurate browser prompts, modern search indexing). * **Key points** * User agent telemetry to WordPress.org on every dashboard load is unnecessary for protection and potentially undisclosed; may break GDPR. * Local checks (Browserslist) improve privacy and utility. * IndexNow aligns with current search engine practices, replacing privacy-invasive, obsolete pings. * Mirrors can be untrusted if not verifiable; provenance and signatures mitigate risk. * Documentation and transparency are essential for compliance. * **Explanation** The lecture noted that BrowseHappy’s hard-coded versions from 2016–2017 mean the external checks are not used to protect users; instead, they function as analytics collection of user agents. Moving checks local removes exfiltration and provides real protection. Similarly, replacing legacy pings with IndexNow ensures data is sent to services that actually use it while avoiding sending content activity to Automattic endpoints. Security benefits extend to package management through verification and standardised update paths. * **Examples** > On each dashboard load, WordPress sends the browser user agent to WordPress.org though the stated purpose (protecting users with version checks) is not fulfilled due to staleness. Retention and storage details are unknown and may be undisclosed in privacy policies, posing compliance risks. * Cease transmission of user agents. * Perform checks locally and document any remaining telemetry. * Audit privacy policies for disclosures and retention details. * **Considerations** * Minimise and document any telemetry; prefer opt-in. * Use cryptographic verification for packages to counter mirror tampering. * Adopt clear data retention and transparency policies for any FAIR-run services. * Align with search engine standards (IndexNow) to ensure functional benefit. * Educate users on trust signals and update hygiene. * **Special Circumstances** * If legacy code paths still transmit data, how should migration be handled? Provide patches and backports to disable telemetry and guide site owners through updates. * If regulators request data handling details, how should response proceed? Provide transparent documentation of collection, processing, retention, and legal bases. ### Decentralised ecosystem architecture for plugins and packages > A multi-service, decentralised architecture encompassing discovery, layered moderation, analytics, and provenance, designed to work across WordPress and other CMSs. It aims to balance user safety, trust, openness, and scalability by relying on independent services, globally unique identifiers, and domain validation. * **Key points** * Discovery services that do not rely on a single central authority * Layered moderation with independent labelling services (e.g., verification, signatures, copyright) * Analytics service designed to be opt-in, privacy-respecting, and potentially operated by an independent third party * Provenance through DNS-based domain validation and visible host domain, plus globally unique IDs * Running one node per service by the FAIR organisation while allowing others to run their own nodes * **Explanation** The lecture outlines the lack of a central point for plugin/package analytics and feedback, which complicates safety and moderation. To address this, the FAIR ecosystem proposes separate services for discovery, moderation (labels provided by independent bodies), analytics (with easy opt-out and third-party operation), and provenance (DNS/domain validation and GUIDs). This decoupled approach mirrors social media models like BlueSky’s layered moderation. The system starts with trusted repositories before expanding to full openness as more trust layers are added. Users receive transparent information to make informed choices about safety and risk acceptance. * **Examples** > Multiple independent services provide labels on packages, such as verification of signatures or copyright status. Users can select which labels to trust and how to act on them (e.g., exclude unsafe/insecure items or tolerate certain categories depending on income considerations). Labels are issued by independent bodies; no single entity controls discourse. * Define label categories (e.g., verified signature, copyright compliance). * Register independent labelling services and their criteria. * Expose labels in discovery interfaces. * Allow users to configure policy: reject, warn, or accept based on labels. * Audit and publish labelling service provenance to maintain trust. > Use domain validation (DNS) to associate packages with a host domain users may trust. Display host domain provenance information in discovery/installation workflows. Assign globally unique IDs to packages so that identity remains stable across decentralised mirrors. * Implement DNS-based ownership checks for publishers. * Store and display host domain in metadata. * Generate and manage globally unique identifiers. * Ensure GUID consistency across repositories and discovery services. * Educate users on interpreting provenance indicators. * **Considerations** * Ensure easy user opt-out from analytics data collection * Maintain independence of moderation/label services to avoid centralised control of discourse * Start with trusted repositories to mitigate early-stage risk before expanding openness * Provide clear, actionable provenance information (DNS, host domain, GUID) * Structure governance to separate technical decision-making from funding and marketing influences * **Special Circumstances** * If encountering conflicting labels from different moderation services, how should it be addressed? Provide user-configurable policies and transparent label sources to resolve conflicts. * If a repository fails provenance checks (e.g., DNS validation), how should it be addressed? Flag the package, restrict installation by default, and allow override with explicit user consent and warnings. ### Governance and organisational structure > FAIR adopts open, transparent governance separating technical leadership from business operations. A Technical Steering Committee composed of contributors leads the technical roadmap, while a foundation-backed governing board supports funding, guidance, marketing, events, and PR without controlling technical decisions. * **Key points** * Technical Steering Committee with elected leadership * Three co-chairs: [Speaker 1], Mika Epstein, Carrie Dills * Governing board handles funding, guidance, marketing, events, PR * Separation of business from technical to avoid undue influence * Model aligned with foundation projects widely used in open source * **Explanation** The project begins like typical open source efforts but formalises governance to ensure trustworthiness while operating decentralised services. Contributors elect co-chairs to lead the Technical Steering Committee. The governing board, under a foundation, supports non-technical needs while maintaining boundaries from technical decisions. This structure is intended to build trust if FAIR itself runs discovery/moderation/repository nodes. * **Examples** > Three co-chairs—[Speaker 1], Mika Epstein, Carrie Dills—were elected months ago for a second term to lead the committee of contributors and committers across code and documentation. * Hold elections among recognised contributors. * Define term lengths and re-election processes. * Document responsibilities and decision-making procedures. * Publish meeting minutes and decisions for transparency. > A governing board under the meetings foundation funds the project, provides guidance, and handles marketing/events/PR, while volunteer teams continue execution and technical control remains with the technical committee. * Establish legal and financial structures within the foundation. * Define clear boundaries to prevent technical capture. * Create funding mechanisms and reporting. * Coordinate volunteer teams for operations and outreach. * **Considerations** * Avoid any single party exerting strong control over the technical side * Document governance processes and publish decisions for transparency * Use widely adopted models from foundation projects to leverage experience * Enable corporate sponsorship without compromising technical independence * **Special Circumstances** * If sponsorship attempts to influence technical decisions, how should it be addressed? Enforce governance boundaries, escalate to the technical committee, and disclose any conflicts. ### FAIR project components and current status > FAIR consists of a WordPress plugin, a mini FAIR repository for publishers, and discovery via Aspire Cloud, alongside associated tools like Aspire Explorer and services for labelling/moderation and analytics. Version 1.0 of the plugin launched this week (planned on Tuesday). All projects are open source and can be self-hosted. * **Key points** * WordPress plugin version 1.0 launched this week (planned on Tuesday) * Mini FAIR repo for publishers * Discovery via Aspire Cloud * Aspire Explorer for browsing .pm packages * Labelling/moderation service and analytics service available as part of the ecosystem * Open source; downloadable and runnable by anyone * Community presence on github.com and chat.com * **Explanation** The lecture announces the 1.0 release of the WordPress plugin and describes complementary components. Aspire Cloud collaborates on discovery. Aspire Explorer enables web browsing of .pm packages. Labelling and analytics services form part of moderation and feedback infrastructure. The ecosystem invites broad participation via publicly accessible repositories and chat. * **Examples** > The WordPress plugin reached version 1.0 this week, with planning set for Tuesday, marking the beginning of the long-term rollout. * Tag release 1.0 and publish release notes. * Coordinate announcements via community channels. * Solicit feedback from early adopters. * Track issues and prioritise post-launch fixes and enhancements. > Aspire Cloud has joined forces for discovery, enabling FAIR to leverage existing infrastructure and expertise for decentralised package discovery. * Define API interfaces and protocols for discovery. * Deploy discovery nodes and monitor performance. * Integrate with labelling and provenance metadata. * Provide web interfaces via Aspire Explorer. * **Considerations** * Maintain clear documentation for installation and publishing workflows * Ensure compatibility across CMSs beyond WordPress * Provide discoverability for .pm packages via web interfaces * Encourage community self-hosting to strengthen decentralisation * **Special Circumstances** * If users cannot access central services, how should it be addressed? Provide instructions for running local/self-hosted nodes and offline mirrors. ### Composer and decentralisation > Composer is widely used by developers, including [Speaker 1], but is not decentralised by default due to reliance on Packagist. FAIR is exploring ways to interoperate or enhance Composer with decentralised models, though no technical solution is implemented yet. * **Key points** * Composer integration is considered but not yet built * Composer relies on Packagist (central service) * FAIR’s model may bring decentralised benefits to Composer workflows * Open invitation to contributors to co-design integration approaches * **Explanation** In Q&A, the speaker acknowledges the importance of Composer and the opportunity to bridge it with FAIR’s decentralised approach. The system model, including requirements handling, could integrate in future. Community input is sought to explore feasible designs and benefits for Composer users. * **Examples** > Future work might include local availability of packages and metadata, preserving FAIR’s decentralisation benefits while integrating Composer’s requires and dependency resolution. * Map FAIR metadata to Composer’s package schema. * Resolve dependencies across decentralised repositories. * Cache and mirror content locally for reliability. * Define fallbacks when central services are unavailable. * **Considerations** * Acknowledge current centralised dependencies while designing decentralised complements * Invite early technical discussions to avoid misalignment * Plan opt-in migration paths for existing Composer users * **Special Circumstances** * If Composer users rely on Packagist outages, how should it be addressed? Provide decentralised mirrors and local registries integrated with FAIR’s discovery. ## Assignments & Suggestions * Contribute to moderation and trust services design, including policy definitions of what is trusted * Join documentation efforts; review and expand docs across workflows and protocols * Help build out the core protocol, plugin, and Aspire Cloud components post-1.0 * Participate in discussions on Composer integration and decentralised dependency resolution * Operate or experiment with running discovery, moderation, and repository nodes to validate decentralised operations ## Transcript Hello everyone, I am the CEO of Product, I am a host, we are an enterprise WordPress services agency, and we are just in time to work with you. I'm also the co-chair of the technical steering committee for the FAIR project, also a core committer to WordPress, I'm a member of the security team for WordPress as well. I created and co-leveled the WordPress REST API for initiation as a standalone project for merging into WordPress Core itself. I created and originally maintained, I was also the project lead for Simplify for a while, and I actually ran out of workflow. I've 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. It is my life. I care a lot about the WordPress project. That was really where I started getting into this project called FAIR. So you might have heard of FAIR already. We announced FAIR in June in Europe at the SIAMEC World Conference. And FAIR stands for Federated and Independent Repository. It's about a few other kind of things around that, around how do we kind of create this ecosystem of. So this is really, you know, you might know some of the history of why this kind of project came about a little bit, but not really the kind of point, but this is our goal is to improve the security and kind of remove it. We are part of a legislation, which you might have heard of. We have 40 plus organisers, so those are voting members of the technical steering, including people you think of as code committers, as well as contributors in other technical. implementation, or helping maintain the website, all of those sorts of things. All of that is technical, and so we give people the ability to vote and be part of the corporate world. 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 called technical independence, and that's a full replacement for WordPress. So you might already know that WordPress depends on WordPress as a kind of key part. We want to make sure that WordPress can exist in any WordPress model. 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 can install those, all of those sorts of things. That's what we try to tackle. Overall, all of that is the organization. The Fair Work Foundation, and that's part of the Mixed Foundation, as I mentioned. So we're going to dive deep into what all of these do and how they work here. But before we do that, let's talk about why there is. So some of you might already know some of the background for this. As I mentioned, Word depends on WordPress.org. If you use WordPress, if you open it up right, it will be talking to WordPress.org and using things from there. And it needs those in order to run them. 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. But there's also some other things. How do you have this dive in deep and finding out all these places that WordPress relies on? you know we knew about the audience that they used to ignore our things but what about this and so we. found quite a few other places you know places where we're calling news or events or you know we've kind of already looked at a lot of those but uh different years that you know you can hide in fact a lot of people uh so you know a lot of it relies on you may have seen uh. i think the the key kind of piece of that is really this realization that, wordpress is and as you can see here separate from the wordpress. is a website that supports WordPress.org. It is not part of the official website. Now, WordPress.org is great. It has given us very many things over the past 20 years. It is very clear that this is a personal website. We are at a point where we need to be taking ourselves seriously. We need to have alternatives. We don't need to be depending on a single company or any single entity in order for our software to exist. We are very grateful for this service that has been provided. It is time to grow up because not only does WordPress depend on WordPress.org, but we all depend on WordPress.org. This ecosystem is too important to leave to anyone in particular. This is where, 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 the last year already, 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 log that we need to be able to fix and replace, you know, that we need to come up with alternatively. And obviously, as part of this, we discovered brand new things as well. Like I mentioned, you know, I didn't know all the things in here. In fact, I think I missed out a couple of things on this slide. I think that I forgot the log patterns, for example. Yeah, those are not in here. So there's a huge amount of functionality. It's really difficult. Let's dive in and see actually, you know, what's all these things. to the operation of WordPress. What are they actually doing on the back end? So if we have a look, two kind of parts of this. We have version checks that WordPress does. So the first one is the PHP version checks, basically saying, hey, we're running a supported version. Is it secure? All of those sorts of things. That seems pretty straightforward, right? We want people to be running the latest and greatest for PHP. We want them to be secure, and all sorts of things. We also have browser versions as well. So every time you load up the WordPress dashboard, your browser user agent is being checked to see, hey, how you are today. You know, how you've stayed. And this is a really noble goal. It comes from a project called Browsing, which is brought to you by WordPress. Which WordPress, I don't know. It's listed on WordPress levels. This is part of, you might have heard of this before. So if you have, you must have been 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. This is the source code for BrowseHappies, what runs every single time. So this is clearly not protecting the users, right? This is not actually checking anything, frankly. These versions are hard-coded, they're not tied to usage data, they're not tied to any kind of real world. So every time you go down to the dashboard, your browser user region gets sent to WordPress.org. And this is collected 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 region getting collected for analytics data by WordPress.org. Which again, is one person to personal website. Now, many people probably don't know that this data gets collected. I certainly did not realize, when I looked it up on my WordPress dashboard, my browser user was getting sent off to WordPress.org. And we have no idea how long this data is retained for. We don't know the details of how it's stored. This source code could even be wrong, right? This might not be the source code that's actually running on the server. So we have no guarantees back. I'm not sure that this... This was even disclosed in the privacy policy for WordPress at all. It's not really considered user data. And it's possible that it might even break GDPR. So this was something that we identified we actually need to replace this. The good thing is, we have solutions for this. So you might already have heard of Browser's List. It's a tool that gets used by names like Webpack, Babel, all those sorts of creative development. And it works using real-world data from CanIUse and the browser members themselves to work out what are the latest versions of browsers. What's actually in use across the kind of deployed web, I guess. And so this data is kind of being handed. Now we can take that kind of data. We can take the information that Browser's List gives us and build a regular expression and build that into your site. So when you work on your site, you can export it. So, you know, if you see a browser on today, entirely on that site, which I've already accessed anyway, and don't get sent anywhere else. So this preserves privacy, not sending data off to a random third party, but also it fixes the user barrier. We actually have something that is useful. In fact, we've started getting some issues coming in, people saying, oh, actually, Hangpoint, now it's actually telling me to update, so I have to restart 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 a one-to-one alternative, but we can actually make things better for our users. Let's take a look at a different one. So this is one that you might have heard of as well. This is the pinging system in West. 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, yeah, publish something, come in here. Make sure that you're up to date with all of this stuff. Again, this is a great sort of idea for a project. These days, you know, search engines tend to index things very rapidly. This is a WordPress foundation, as you can see in the photo there. A WordPress foundation brainchild, if that means. And, you know, that sounds great. But it turns out this is hosted on blog as well. So this is also hosted on the website. But what does this service actually do? Well, we can see down here we have some common services. We have Blogs, FeedBurner, Spinner, and Superfeed. In particular, FeedBurner. FeedBurner was a service for updating RSS feeds, indexing those, making sure they get out to the internet. It was quite like Google, right? So surely that data is kind of feeding into Google search engine. It's helping, you know. Well, we spoke to some people at Google, and they confirmed feedback data is never used. 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 a funt, right? It's not used anymore at all. But it turns out that's actually not the only one. If you look at the other services here, you might not have heard of these, because at least two more of them are also being discontinued. Spinner's website no longer works at all, so I don't even know where that is. And Superfeeder, I think, was also acquired by somebody, kind of shut down, and doesn't really work. So that leaves us with one service left over, which is called Blogs, or OTS. So every time you're publishing a piece of content, things are getting sent by your site to King-O-Matic, those go off to Blogs. Does anyone want to guess who owns Blogs? That's right, it's on... So every time you publish a piece of content on your site, it sends a ping off to wordpress.com and to automatic 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 a user identity. This is not really how any search engine can keep their internet stuff today. 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 it is a something better. It's called IndexNow. It's an open standard that was created by search engines themselves, including Microsoft Bing, which feeds data into a lot of WordPress. And this is a kind of decentralized sort of protocol. So a bunch of search engines join in on this. You send a ping off to one and it 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. And this is again, fixing that kind of user use-plus, or actually improving the role that we have, not just protesting or replacing them for the sake of it. So this again is just one of those other pieces. So if we have a look at all of these services, that are getting sent to WordPress.org, you'll also notice as well as, Gravatar is in here as well. Gravatar is a great service, but it is run by Web2Web. We can start thinking about replacements for all of these services, and come up with, something that looks a little like this. Now 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 that gets sent anywhere else. We preserve privacy, keep all of that stuff within your site. And then for the other kind of aspects, we use the industry standards, kind of the best technology that exists. Ideally, things that we don't have to. Like John said, it is a pain kind of running actual services and keeping things up. Certainly, I get annoyed, I get pinged on my phone, the site has gone down. So we want to run as well as possible. And we do have to run some, in particular the news and the community events, we have to run a few guys for that because no one else has that data. But for things like PHP version checks, or PHP.net directly, right, they run it online. For things like emoji, for example, rather than using who knows what, we can actually use a common CDN who might actually have it. So this is all about kind of stateful independence work, and we launched this back in June as part of our first 0.3. But let's zoom in on one part of this that I have kind of touched on, which I guess is a very big part of this, which is plugins and themes. So in this diagram, you might have already noticed, It's a little small, sorry. We swapped this out for a service called SpirePress, which is a mirror of WordPress.org's package. But, you know, we kind of want to get a little bit more complex than that. We don't just want to kind of copy what was there before. We want to actually keep the system. So this is where the second kind of path for FAIR comes from, it's package management. So every time we think packages, that means projects and things. They're kind of the same, and so we call them that, a little more simple. So in this diagram, in kind of your brain, why do you think, okay, yeah, I've got plenty of things. I download those from the repository, I install those. Maybe I open up a WordPress dashboard and add a plugin, those sorts of things. You know, packages come from WordPress.org. Now, particularly since September, and since people have started realizing that depending on .org, it's maybe not the best thing in the world, a lot of posts have started coming in. So actually, your sites might be getting F1 mirror instead, right? Part of this point, going to be here. But this mental model of thinking about, you know, downloading our packages from .org is right. I'm sure that everybody here has downloaded at least one plugin from GitHub, right? You might have a premium plugin for your, you know, buying from a third party, installing those, etc. You might have private code as well. So the reality really looks something like this. So we have multiple sources, multiple repositories that we're getting all in our package. Once you install those, if maybe you're only installing it once, then you have to go download again each time. But in a lot of cases, these packages now start to be where they're only self-populating. So they might update directly from GitHub. They might do a premium plugin API. Check it once a year and also see if there's no other way. In practice, what this means is a lot of our sites are talking to a lot of these sources or these repositories all the time, but this model has some problems. So the first one is that third-party use can't be installed, right? When you go and find something for the first time, you have to go find it somewhere else. Google, you can go check GitHub, you know, maybe use some of the other ones that are available. But you have to go get those from somewhere else and then bring them into WordPress. This is really not a great user experience. The best user experience is when I go on the blogging screen, it shows me all the bloggings that are ready. I search for, you know, SEO or something like that, and I go and install that. Great. That solves my problem. So this is a bad user experience, more than anything else. It's also good to be able to repeat. You might include something like E-Software-like something, or hitup data, or those sorts of So this is, you know, really inefficient because if I have 20 plugins, this folder might have 20, all 12 in different ways. It's also hard for the users to protect against malware, against bad plugins that might be. masquerading in some way. You know, we know that we don't always have the greatest kind of security requirements from the API. The WordPress business is massive. That's just on the world, right? I mean, there are probably the same number of games, if not more, posted elsewhere. But everything works at all. There's no kind of wheel around it. It's either fully moderated on the world, where, you know, the game looks at these things, or there's nothing. Whatever guarantees some randomness. That's no human review. No, what I mean is, again, no vulnerability in all of those. And even the mirrors that I mentioned before can also be unsafe as well, right? Now, most of them are trustworthy, but, you know, there's nothing that says that they can, you know, change a path. And the fourth problem is that. developers try to offer solutions, right? The WordPress model of policy say you can't go and get updates from somewhere else. You can't, you know, actually build another kind of solution. So there's not even a good kind of solution going on. And there's some good reasons for that, right? There's safety issues, right? A lot of people are installing things outside of the world. To be honest, users are already installing things. And so how could we actually recognize them in reality? So if we go back to this kind of world view, you know, this is already, this is not a system that I created. This is what, you know, your sites, what they've been forwarding us. So we already have a bit of them here in this alternative, not normal, right? So what if we could, like, pack this into some sort of system? All of these parts here, you know, they have different, right? There are, of course, places where we can pack them. Um, you know, because this system is something similar to, you know, maybe not even, maybe there's just, I don't know, some sort of analogous system. Elsewhere, it's kind of like the web itself. You open up your website, you go to a website, you report to that website, you know, you don't need to go ask permission to go to your website, you just open it up, type in your URL, but this also kind of, you know, reveals part of the same problem that we have as well, right? Um, which allows us to say, I've got a URL that I'm looking for, um, go and show me all the solutions for this, and that's great, that's exactly what you're still looking for, and we also, If you're very old school web, you might have a web index that might even point the way for, I don't know, people yet. We've kind of solved this problem. We use a search engine for the first time to discover brand new things. We know about those, we know about anything that exists, we can just go to the right. But why use this in the wind? We have a repository that are boosting all of these packages. We can introduce a new kind of search engine, or we can call it a discovery. Now this is a way for you to supply your music and go out and, you know, you can go and find a little bit, and you can use this. Now again, just like that, once the site... You can find these packages with updates and talks directly to the repository. It's the thing for running apps. The way that this works is that there can be multiple ways. Google and Minion and Taggy Mac. But there are all these sorts of alternatives, right? The reason for the web is that there is no sexual barrier. There is even this ability for things to exist, right? It's kind of Google and the thing. And it's the best. You just can pick. Hey, I like this better. Maybe the search results in this engine are worse. But it's interesting. So this sort of system we're already using. But the system... The first of these is, how do we get some feedback, right, we rely on things like, how many installs does a plugin have, or what has been written on that, and I think this is kind of an idea of, is this a safe point, how do we conceptualize well, where there's no kind of 10-4 argument, the second is moderation, you know, the safety of these sorts of things can be quite difficult when we're looking at things that are usually lost, how do we conceptualize that, to keep that, you know, room and time, and conceptualize, you know, the safety of these sorts of things can be quite difficult when we're looking at things that are usually lost, how do we conceptualize that, to keep that, you know, room and time, and conceptualize, you know, the safety of these sorts of things can be quite difficult when we're looking at things that are usually lost, how do we conceptualize that, to keep that, you know, room and time, and conceptualize, you know, the. safety of these sorts of things can be quite difficult when we're looking at things that are usually lost, how do we conceptualize that, to keep that, you know, room and time, and conceptualize that, to keep that, you know, room and time, and conceptualize that, to keep that, you know, room and time, and conceptualize that, to keep that, you know, room and time, and conceptualize that, to keep that, you know, room and time, and conceptualize that, to keep that, you know, room and time, and conceptualize that, to keep that, you know, room and time, and conceptualize that, to keep that, you know, room and time, and conceptualize that, to keep that, you know, room and time, and conceptualize that, to keep that, you know, room and time, and conceptualize that, to keep that, you know, room and time, and conceptualize that, to keep that, you know, room and time, and conceptualize that, to keep that, you know, room and time, and conceptualize that, to keep that, you know, And part of the issue with getting analytics and finding out what things are used is that there's no kind of central place that knows about these types of things, right? There's no one main thing to ask for or to start with. But what if we need something like centralized systems? But have this analytics made a spot for the site? Now, you can do that, and you can make sure that it's free, which is not a key part of this. But, and this is quite similar to, say, on the web, the Chrome user experience tells us about how it's not a critical part of the web. It's not necessary for any part of the web to be interested in useful data by any kind of science. If I had an independent third party as well, You can collect this data and give that out to anybody who asks for any of that data. That also makes it really easy for users to opt out of the data claim. So then, secondly, now that we have all the problems of moderation, how do we keep users safe no matter where they're at? It turns out a lot of smart people worry. In particular, BlueSky has a back-up operation called Layers of Moderation, where you have multiple services that you can give you different information about the things that you're looking at, etc. They call this a link line. Here is a user account, and this one. So that can be like, oh, this is my link. you know this is being verified so we can take that set of clients and so again we have a service also assigned to our label which compels us about all the packages now to do that we have to have e-pid's for all the packages but what happens that there are many random labels and in fact we can also have multiple it might have one that checks for signature and we might have something that checks for copyright it might even have to be involved in here as well. because your web has to offer a label that says they have it without that form and in here as well, none of this control how people are talking about you can't control you know your hotel you can't control uh you can't control that one these are independent bodies that are being verified so this system allows us. We can also give people the choice of how to handle someone. You might want to say, hey, look, I don't want to involve anything that is unsafe or insecure. But if it's just income, well, I can probably involve them in a lot of different forms. Again, this is the approach that we have taken with FAIR. It is built in Monterey, here, and I offer a moderating service of our record of human review. And there are additional layers of that kind of legal industry built on top. We're going to make this an available solution and get exactly what they want. As well as a good choice. But particularly in Europe, you might want to keep that in control. This is something that Blue Sky did, as they kind of built out the decentralized aspects. That's something that we're doing as well, so we're taking a cautious approach. We're only going to bring in repositories that we can trust in as we start up, and then expand that to a fully open system over time once we've got additional cross 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 a right. But we need some additional kind of solves for the provenance, making sure that they'll have their way. So one of these that we can take, again, from that same social media concept, where it's a very common thing, is to use domain validation. Users already have a concept, and so we can build on top of that with DNS Go. We can also show the host domain. We can show where is this coming from. because that's something that I as a user might want to trust. Now, not all users are going to care about this, so that's fine. Make sure that we're kind of giving them the information that they can make it to. And by giving everything a completely globally unique ID, we can make sure that no matter where this group is, we're always kind of keeping it the same, we know exactly when it's the same path. 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. So if we put the whole system together, this is how this kind of looks. We now have our discovery, we have our label log, we have our analytics service, and we have our science talks, all of these all the time, so it's very decent. Actively speaking, we are going to run one each of these nodes as well. So we'll run a discovery service, we'll run a moderation service, we will run a repository, so you can go and run them. So this is how we build this decentralized system, but if we're going to run these services, we're going to prove that we are kind of worthy of this trust as well. So that's where we then get into our organization and structure, how the project comes together. So how do we make sure that we are trustworthy if we're going to run it? How do we create open, transparent governance? How do we support some balances for the structures to make a clear consensus decision? Well, we start out just like any other open source project. We maybe have a couple of groups of people who are working on different things, a couple of repositories and releases of code and a few other things. But then we think of best practices that the ecosystem, the kind of community that we're already in. We are not alone in this. Just like the concept of three years of man reaching out to make sure that nothing is an island, we should have a look at what's happening at source. 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 or well-known contributors to the Committers in WordPress. But this includes things like documentation in Excel as well, where you can get ourselves writing code. These then form a Technical Steering Committee, which is a 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 months ago, after our second term, to lead this body. For the most part, we're still made to see if it's just like any other open source project. We introduce the business side of things as well so we can have corporate sponsorship for a governing board. This is all handled as part of our meetings foundation where we kind of keep the business side a little separate. We don't want any one party to have strong control over the technical side. We want to make sure that this is all handled nicely, also providing us feedback and money. We want to have this sort of board. The governing board can fund the project, they can provide guidance and they can also do things like marketing or running events or PR. But they don't have to handle that all themselves, we can still have our volunteer teams. We can build everything together. So if we put all those pieces together, it's going to look a little complex, we have this big diagram, and this is a big complex, right, but this is what, you know, we kind of ensure a large project, and that complexity is there for us, right, we're separating out the business side from the technical side to make sure we keep that kind of internet. This is a model that is used by these foundation projects, and it's used very widely, so this is something that, you know, there's a lot of experience. So, how kind of does it practically come together? We have several different projects, and loads of content. We have three primary projects in the FAIR project, a plugin, which you can go and install on your site, I strongly recommend doing so, you can go and download version 1.0, which just came out this week, and there's also the mini FAIR repo, so if you are publishing, you can go and download version 1.0, which just came out this week, and there's also the mini FAIR repo, so if you are publishing, you can go and download version 1.0, which just came out this week, and there's also the mini FAIR repo, so if you are publishing, you can go and download version 1.0, which just came out this week, and there's also the mini FAIR repo, so if you are publishing, you can go and download version 1.0, which just came out this week, and there's also the mini FAIR repo, so if you are publishing, you can go and download version 1.0, which just came out this week, and there's also the mini FAIR repo, so if you are publishing, you can go and download version 1.0, which just came out this week, and there's also the mini FAIR repo, so if you are publishing, you can go and download version 1.0, which just came out this week, and there's also the mini FAIR repo, so if you are publishing, you can go and download version 1.0, which just came out this week, and there's also the mini FAIR repo, so if you are publishing, you can go and download version 1.0, which just came out this week, and there's also the mini, And then we have our discovery, which is Aspire Cloud, so they kind of joined forces with us, and we're all working together. All of these are obviously open source, you can download them, you can run them yourself. We have some other projects around as well, Aspire Explorer allows us to browse that on the web with their .pm packages. We have a website, and we have those other aspects that I mentioned, the labeling, or moderation service, and the analytics service as well. So you can find us on github.com. You can find us at chat.com. We would love to see anybody in here as one. So, thanks very much. Thank you Ryan. We do that. Okay. So the danger is not in the system. And then first, what we apply. Right. I'm not sure if that's a real question. How's it going here? Is everything okay? Yeah, absolutely. So it's something that we've been thinking about. There's a, I didn't mention, but I don't know if there's a whole discussion. There's actually one in Poser. And certainly for, you know, a lot of developers, including myself, Poser is the way that we install hacking. It's something that we're very, very kind of focused on thinking about. We haven't built anything to integrate with it yet, but the weight of the system is actually part of the model. So including things like requires. I think that's a really good question. So, we've always got to bridge those in the future and make it available locally and that would still give you all the benefits of a fair system, a fully decentralized system. Worth noting as well, actually, Composer is not really decentralized by default, so it relies on ServiceBook, which is a great service, but it is a central service. And so there are ways, actually, that we can potentially benefit Composer even. We don't have a technical solution for all of this yet, but I think we have an idea of how. If you're interested in seeing how that might work, we would love for you to come join us. Even if that is just discussing ways that it might work and possibilities, we are open to all contributions, your love, any help. Courtney Robertson at GoDaddy. As a contributor to FAIR, one, can we ask those that participated to stand for just a couple of seconds? 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 plug-in 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 can contribute, but what are the big needs that we have right now. Yeah, good question. I almost threw the question back to you, because I feel like maybe you have things in mind, but we have a huge amount of work to do. We are building an ecosystem around out here. We're designing this one just for WordPress, by the way. This is usable by any CMS, a couple people in particular. We are designing a very big system here, so there's a lot to do. We have not started on the... services yet. We know kind of how we're going to head that direction. Blue Sky is a good resource. There's a lot we can take from there. 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. And as well, the kind of policy aspects, right? What do we trust? So that is a big area we can use contribution. We need more documentation, right? We've been heads down and focused on actually building a lot of this. And documentation is something that we have been working on, but it still very much needs help. You know, with all documentation, the kind of more eyes you have on that, the more aspects you consider, the better that that is. So there are certain people in the audience who are on the documentation working group, like Courtney and Taco, who can both kind of help people. So that is something that we very much do still need help with. And a lot of the core protocol itself. We're going very rapidly through building. and we still need more help building out the plugin and the spider cloud. We only launched 1.0 this week. Again, we planned that, but we have 1.0 on Tuesday, so we are just starting this long journey. As I mentioned, I've been around WordPress for more than a year. I am very invested in this ecosystem, and I don't want to see it going to the back. I don't want to collapse with that. I'm very invested in making sure that this is a project for the long term. I think all of the contributors, many of whom are long-term contributors as well, are all very invested. So we see a long journey ahead of us, and there are loads of contributors, and we're going to grow this over time. We think that we have the right structures in place, but we also think that we have a better... Amazing. Okay, another round of applause. So we have now arrived at our first sketch.