Is it time to build a Decentralized Registry of WordPress Plugins?

WordPress, with its extensive plugin ecosystem, has long relied on a centralized repository to distribute plugins to millions of users. This model works well, but the recent controversy around the ownership of WordPress.org and the battle between WordPress.org and Matt Mullenweg against WP Engine—which has included a fork/takeover of the popular ACF Plugin—has led some plugin authors to pull their plugins from the official centralized directory.

In an era where decentralization has become an important aspect of digital infrastructure, it raises a few compelling questions: Is it even necessary to have a centralized directory? And, to the point of this post, Is it possible to create a decentralized registry of WordPress plugins?

State of the Art of Dependency Package Management

To understand the context, it’s worth mentioning that tools like WPackagist already offer an alternative repository for WordPress plugins and themes, allowing users to leverage Composer to manage dependencies. While WPackagist is a valuable resource, it still relies on a centralized infrastructure, which limits its resilience to failures or censorship. Moreover, WPackagist simply mirrors the plugins from the WordPress.org repository, meaning it cannot offer the full independence and freedom that a decentralized registry could provide.

This contrasts with a system like pkg.go.dev in the Go ecosystem. Go modules can be fetched directly from the source (typically Git repositories), with pkg.go.dev acting more as an index than a repository. This model offers more flexibility, where the package index is a reference rather than a centralized store. A similar model for WordPress could increase the flexibility and robustness of plugin distribution.

To imagine a decentralized registry for WordPress plugins, we need to understand the current landscape of package/dependency management systems and the potential benefits of combining these existing approaches. Systems like npm, Composer, and apt represent traditional centralized approaches, whereas Go modules, Entropic, and Deno offer insights into how a more decentralized system might function.

1. Centralized Package Managers with Mirrors: These are systems that rely on a single, central repository for package storage and distribution, but may have multiple mirrors or instances to improve resilience:
   • npm (node.js): npm acts as both a registry and a distribution server, where all packages are stored in a centralized repository. CJ Silverio’s essay highlights the economic implications of this model, emphasizing how control and power are concentrated within a single authority.
   • Composer (PHP): Composer allows for dependency management in PHP, relying on a centralized repository (Packagist) that provides plugins and packages for developers.
   • apt (Debian): The Advanced Package Tool (apt) primarily relies on centralized repositories for installing and managing software on Debian-based systems, but developers can also publish their own .deb packages and distribute them through third-party repositories, introducing the concept of federation and multiple sources of truth, making it more federated in nature.
2. Decentralized or Distributed Systems: These systems aim to avoid centralized points of control and failure:
   • Go Modules (pkg.go.dev): Go’s package management system allows modules to be fetched directly from their source repositories, with pkg.go.dev providing an index. This provides a more decentralized model where the package source is distributed.
   • Deno: Deno allows users to fetch modules directly from URLs, removing the need for a central repository and giving developers more flexibility in where and how they store their packages.
   • Entropic: Entropic was designed to provide a federated model for package management, in contrast to centralized systems like npm. It allows for multiple registries to coexist and collaborate, aiming to distribute control and reduce the risks of centralization.

In a decentralized registry, the key to decentralization lies in the source of the packages, not necessarily the index or indices; there is still a need for a place where authors can add their packages to an index, which helps users discover and manage plugins. Ideally, this index could be replicated across multiple nodes to ensure availability and resilience, reducing the risk of a single point of failure.

How Would Authors Submit Plugins?

A significant challenge in building a decentralized registry is establishing a submission workflow for plugin authors. In a centralized system, submissions are reviewed and maintained in one or a few authoritative locations, ensuring a level of quality and security. However, systems like apt allow for package submission through third-party repositories, which makes the process more federated and allows multiple sources of trust. Composer already offers a method to manage WordPress plugin dependencies, although the available documentation may not be straightforward for new users. This could potentially serve as a starting point or inspiration for handling submissions in a decentralized way.

In a decentralized model, authors could directly publish plugins to a distributed network. This could be facilitated by a command-line interface (CLI) or a web interface, similar to how npm or Composer work but extended for decentralized storage. Some possible submission methods include:

• Direct Git Repositories: Authors could submit plugins directly from a git repository, much like how npm allows publishing from GitHub. This would also make tracking version history straightforward.
• Authentication and Verification: Without a centralized registry, verifying plugin authenticity becomes challenging. It could involve decentralized identity systems or blockchain-based verification to ensure the plugin author is who they say they are.

How Would Distribution Work?

In a decentralized system, distributing plugins and updates to consumers would need to happen without relying on a single point of failure. There are a few ways to tackle distribution:

• Peer-to-Peer Networks: Leveraging peer-to-peer (P2P) technologies, like IPFS, could help distribute plugins across multiple nodes. This would reduce dependency on a central server while ensuring the availability of packages.
• Update Servers or Hubs: Although the system aims for decentralization, certain “update hubs” could be used to help facilitate updates for users who prefer a more traditional way of managing plugins. This approach could provide a middle ground between full decentralization and usability.

One major concern is security. Plugin updates would need to be signed by the author to prevent malicious actors from distributing compromised versions. Systems similar to TUF (The Update Framework) could be implemented to manage the trust relationships between plugin authors and consumers.

Some Philosophical Background

To further explore the potential for a decentralized registry, it’s worth examining Entropic and the ideas presented by CJ Silverio in her essay on the economics of package management in npm. Entropic was created as a response to the growing concerns over the centralized nature of npm, aiming to provide a federated model where multiple registries could interact, reducing the power held by any single entity. CJ Silverio’s essay sheds light on the underlying economic and power dynamics in centralized package management systems, arguing that a federated approach could help distribute control more fairly among contributors and consumers.

The Challenges

The move to a decentralized registry of WordPress plugins is an ambitious one, and it’s not without its challenges:

• Security: Ensuring that plugins are legitimate, up-to-date, and not compromised is a tall order without centralized oversight.
• User Experience: For plugin users, the WordPress admin interface provides a seamless installation and update process. A decentralized alternative should try to match or exceed this level of convenience to gain traction.
• Community Involvement: Decentralization puts more control in the hands of plugin developers and users, but it also requires more participation. Users need to be willing to contribute bandwidth or resources to keep the network functional.
• Developer Experience: The new tools should provide a delightful, robust and safe experience to developers.

The Opportunities

Despite the challenges, decentralizing the WordPress plugin repository has significant benefits:

• Resilience: No central authority means no single point of failure, making the plugin ecosystem more resilient to outages.
• Freedom and Ownership: Plugin developers would have more freedom to distribute their work without gatekeepers, fostering innovation and allowing niche plugins to flourish without centralized policies.
• Global Accessibility: Decentralization could make WordPress plugins more accessible globally, bypassing censorship or geographic restrictions.

Practical Implementation Considerations

I’ve already taken the first steps toward this concept by building a prototype CLI tool called wdm, which retrieves WordPress plugins directly from GitHub. While it’s a proof of concept, expanding it to support a decentralized system requires additional features:

• Support for Multiple Sources: Plugins could be retrieved not only from GitHub but from various sources like GitLab, other git repositories, or even arbitrary HTTPS links. This flexibility is essential to ensure authors aren’t limited to specific platforms.
• Authentication for Private Sources: Some plugin authors might prefer to distribute to a restricted audience or want to offer premium plugins. Adding support for private sources, potentially through token-based authentication, would be key.
• Decentralized Indexing: Without a centralized server, how do you search for plugins? This could be solved by a decentralized indexing service, where plugin metadata is published to a distributed ledger or DHT (Distributed Hash Table) that clients can query.

As Silverio points out, the CLI tool is only a small piece of this machinery, and a rather unimportant one.

Conclusion

Building a decentralized registry for WordPress plugins is an exciting prospect, full of both opportunities and challenges. By combining the technologies of distributed networks, decentralized identity, and peer-to-peer storage, it’s possible to imagine a future where WordPress plugins are truly free and open, with authors in complete control of their distribution.

There’s a lot more work to be done, but the possibilities are vast. The prototype I started, wdm, is a small step in that direction, and I’d love to see more collaboration and interest in this space. What do you think—is the WordPress community ready for this shift?