A Linux Foundation Project
FAIR News

What is FAIR?

This post is based on Ryan McCue's presentation at LoopConf 2025, where he laid out the case for FAIR and explained its architecture to a packed audience of WordPress developers and community members.

Who is Ryan McCue?

Ryan McCue has been involved with WordPress for over 21 years. He is a WordPress core committer, a member of the WordPress security team, and the creator of the WordPress REST API. Outside of WordPress, he created Requests for PHP, a widely used HTTP library, and SimplePie, the RSS/Atom feed parser that powers WordPress's built-in feed handling. His deep experience with WordPress's internals gives him a unique perspective on the problems FAIR is designed to solve.

The dependency problem

WordPress sites depend on wordpress.org for a staggering number of things. Most people think of plugins and themes, but the dependency goes far deeper:

  • Plugins — Discovery, installation, and updates all go through wordpress.org.
  • Themes — Same as plugins: the entire lifecycle is tied to one source.
  • Core updates — WordPress itself checks wordpress.org for new versions and downloads updates from there.
  • PHP checks — WordPress checks whether your PHP version is still supported by making calls to an external API.
  • Browser checks — The Browse Happy feature checks whether your browser is up to date.
  • News — The WordPress dashboard news widget pulls content from wordpress.org.
  • Events — The Events widget shows nearby WordPress events, fetched from wordpress.org.
  • Patterns — Block patterns are loaded from wordpress.org's pattern directory.
  • Translations — Language packs for core, plugins, and themes are downloaded from wordpress.org.

The critical insight is this: wordpress.org is a personal website. It is owned by one person, not by a foundation or community organization. Every WordPress site in the world depends on infrastructure controlled by a single individual. This is an extraordinary single point of failure for software that powers over 40% of the web.

Hidden privacy issues

The dependency problem isn't just about availability — it's about privacy.

Browse Happy

The Browse Happy feature is supposed to warn users when their browser is outdated. In practice, it checks against a list of browsers that hasn't been properly maintained. It flags some perfectly current browsers as outdated while ignoring genuinely obsolete ones. Worse, it sends user agent strings to wordpress.org, revealing information about users' browsers and operating systems.

User agents sent to wordpress.org

Every time WordPress checks for updates, it sends detailed information about the site to wordpress.org: PHP version, MySQL version, WordPress version, active plugins, active theme, locale, and more. This data collection happens silently, without the site owner's explicit consent.

GDPR concerns

For sites in the European Union, these silent data transmissions raise serious GDPR compliance questions. Site owners are responsible for disclosing all data processing activities, but most aren't even aware that their WordPress installation is sending this information to a third party.

Ping-O-Matic

WordPress has a built-in feature that pings various services when you publish new content. This goes through Ping-O-Matic, a service that distributes these notifications to other services. The problem? Most of the services Ping-O-Matic pings are defunct:

  • Google Feed Burner — a service that Google shut down years ago. The pings were never actually used by Google.
  • bl.ogs — a domain owned by Automattic. The ping service is essentially pinging back to the same corporate entity.
  • Several other services that no longer exist or no longer process the pings.

Every WordPress site in the world is making HTTP requests to defunct services every time content is published. This is wasted bandwidth, wasted server resources, and unnecessary external connections.

Technical independence solutions

FAIR provides concrete alternatives for each of these dependencies:

  • Browserslist — Instead of checking wordpress.org for browser data, use the industry-standard Browserslist project. It's maintained by the broader web community, is far more accurate, and doesn't require sending user data to a third party.
  • IndexNow — Instead of Ping-O-Matic, use IndexNow, a protocol supported by Bing, Yandex, and other search engines for instant indexing notifications. It's efficient, modern, and doesn't ping defunct services.
  • Direct php.net API — Instead of routing PHP version checks through wordpress.org, query the php.net API directly. It's the authoritative source for PHP version information.
  • On-site emoji — WordPress currently loads emoji support from a CDN (s.w.org). This can be handled entirely on-site, eliminating another external dependency.
  • FAIR APIs — For plugin and theme discovery, updates, and installation, FAIR provides federated APIs that don't depend on any single provider.

Package management problems

Beyond the dependency issues, WordPress's approach to package management has fundamental structural problems:

  • No admin install for third-party — If a plugin isn't on wordpress.org, there's no easy way to install it from the admin interface. Users have to download a ZIP file and upload it manually. This creates a two-tier system where wordpress.org plugins get a smooth experience and everyone else gets friction.
  • Reinventing update mechanisms — Every commercial plugin developer has to build their own update mechanism. This means hundreds of different implementations, each with their own security implications, each duplicating work that should be handled by infrastructure.
  • No security review — While wordpress.org reviews plugins before listing them, there's no ongoing security review. Once a plugin is approved, it can push updates without further review. And plugins distributed outside wordpress.org have no review at all.
  • Policy restrictions — The wordpress.org plugin directory has policies that restrict what kinds of plugins can be listed and how they can operate. While some policies serve users, others are arbitrary or favor certain business models over others.

FAIR architecture

FAIR addresses these problems with a layered, federated architecture:

Repositories

At the base layer, FAIR Repositories are where packages actually live. Anyone can run a repository — a company, a community, an individual developer. Repositories use a standardized API, so any FAIR-compatible client can discover and install packages from any repository. This is what FAIR Beacon provides: a lightweight, self-hostable repository.

Discovery Aggregators

Discovery Aggregators like AspireCloud crawl and index multiple repositories, providing a unified search and discovery interface. Think of them as search engines for FAIR packages. You don't have to know which repository a package is in — you just search, and the aggregator finds it for you. Multiple aggregators can coexist, preventing any single one from becoming a gatekeeper.

Labelers

Inspired by Bluesky's approach to content moderation, FAIR uses a labeling system for trust signals. Labelers are independent entities that attach labels to packages: security audited, accessibility tested, performance verified, etc. Users and site owners choose which labelers they trust, creating a personalized trust layer rather than depending on a single authority's judgment.

Optional Analytics

FAIR supports opt-in analytics that respect user privacy. Repository operators can offer analytics to plugin developers without requiring data collection at the network level. The key word is optional — no data is collected without consent.

Trust layers

The trust system combines cryptographic verification (ED25519 signatures), decentralized identity (DIDs), and community-driven labeling to create a robust trust infrastructure. Packages are signed by their authors, identity is verified through DIDs, and trust signals are provided by independent labelers. No single entity controls the trust system.

The complete system

When you put it all together, FAIR creates a system where:

  • Developers publish packages to any repository they choose.
  • Aggregators discover and index packages across all repositories.
  • Labelers provide independent trust signals.
  • Users install packages from any source, with cryptographic verification and trust labels to guide their decisions.
  • No single entity controls any part of the system.

Organizational structure

FAIR's governance is designed to be as decentralized as its technology.

Technical Steering Committee (TSC)

The TSC oversees the technical direction of FAIR. It consists of over 40 organizers from across the open-source community. The committee is led by three co-chairs:

  • Ryan McCue — WordPress core committer, REST API creator, and long-time contributor to the WordPress ecosystem.
  • Mika Epstein — Former WordPress.org plugin review team lead with deep expertise in plugin security and policy.
  • Carrie Dils — Experienced WordPress community leader and developer advocate.

Governing Board

The Governing Board provides organizational oversight, manages finances, and ensures FAIR operates in the interest of the community. It includes representatives from member organizations and the community at large.

Linux Foundation

FAIR operates as a Linux Foundation project, which provides legal infrastructure, trademark management, and organizational support. The Linux Foundation's neutral governance ensures that no single company or individual can take control of the project.

Current status

As of Ryan's presentation, the following components were available:

  • FAIR Plugin v1.0 — The WordPress plugin for connecting to FAIR repositories, with DID-based identity and cryptographic verification.
  • Mini FAIR Repo — A lightweight, self-hostable repository that anyone can deploy on GitHub, Gitea, GitLab, or Bitbucket.
  • AspireCloud — The discovery aggregator with search, faceted filtering, and a comprehensive API.
  • AspireExplorer — The web interface for browsing packages in the FAIR network.

Coming features

  • Enhanced labeling system with community-driven trust signals
  • Policy engine for automated repository governance
  • Improved DID management and key rotation
  • Extended CMS support beyond WordPress
  • Plugin security scanning integration
  • Automated compatibility testing
  • Translation management through FAIR
  • Decentralized plugin reviews

Why this matters

Ryan closed his presentation by framing why FAIR matters beyond the technical details:

  • Independence — No single entity should control the software supply chain for 40% of the web. FAIR ensures that no one can pull the rug out from under the ecosystem.
  • Privacy — Users deserve to know what data their software is sending, to whom, and why. FAIR eliminates silent data collection and puts users in control.
  • Competition — A healthy ecosystem needs multiple distribution channels. When one provider controls the marketplace, innovation suffers and developers have no alternatives.
  • The web model — FAIR follows the model that made the web successful: open protocols, decentralized architecture, no gatekeepers. The web works because no one owns it. Software distribution should work the same way.
  • Beyond WordPress — While FAIR started with WordPress, the architecture is CMS-agnostic. The same principles apply to any software ecosystem that suffers from centralized distribution. FAIR's federation protocol can serve TYPO3, Drupal, Joomla, and any other platform that needs independent package management.

Resources

Search