canales.io

Author: vcanales

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

    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?

  • If the shoe fits

    If the shoe fits

    Used to tell someone that unpleasant or critical remarks which have been made about them are probably true or fair. And, yeah, that’s the Colosseum in the background.

  • Ordinário had extraodinary views

    Ordinário had extraodinary views

    Ordinário was a bar located next to the Tagus river in Lisbon. I went there in the summer of 2022, and caught this shot of a person running across the door. It was a great place to sit and contemplate life, and even though you can’t visit it anymore, that area is full of other good places to sip wine and cope with the heat of Lisbon in the summer.

  • Modena

    Modena

    I had the chance to visit this city in June. I spent a few days of a month-long trip in Europe here, taking in the views of the city center, and trying to have a few peaceful days. I went to the market for supplies, and was really amazed by how cheap produce is, specially the fresh Mozzarella.

    A corner in Modena, with some signage.

  • The perils of the long-haul flight.

    The perils of the long-haul flight.

    Because of my job at Automattic, I travel a few times a year internationally. It’s not something I’m used to, even though I’ve always known that traveling around the world appeals to me; I only started actually doing it when I joined the company. The most recent adventure took a multi-team group and me to Sepang, Malaysia, an hour or so away from Kuala Lumpur, towards the strait of Malacca. 

    With everything going according to plan, the flight from my home base, Santiago de Chile, is 30 hours long with a minimum of 2 stops. On the way there, Iberia took me to Madrid first, and Qatar Airways took me to Doha and Kuala Lumpur. It was a long albeit quiet journey.

    Jet lag didn’t have as significant an impact as it has before, even on shorter flights; I think that this might be related to my inability to rest in planes and that I crashed in my room as soon as I could, which led to a full 8 hour night sleep. The week started off great; many productive discussions were had, delicious meals were eaten, fun games were played, and new connections were created.

    Problems would only arise on the way back, which in a way, I’m thankful for as it meant that I was able to get the most I could out of meeting my colleagues in person.

    The first leg of the trip would see Malaysia Airlines take me from Kuala Lumpur International Airport back to Doha, Qatar, where I had approximately 2 hours to catch the next flight to Sao Paulo, Brazil. This would not be the case; boarding time came and went, and when the scheduled departure time arrived, airline staff let us know that the flight would be delayed due to technical issues and that more information would be available in 30 minutes. 45 minutes later, staff let us know that the flight would be delayed precisely an hour until 3:45 am. This seemed unlikely, as we were close to the new departure time, yet no efforts had been made to board the plane. And unlikely it was, since when the new time came, the flight was again delayed until 4:45 am.

    Logic would follow that they would start boarding immediately; the plane was a Boeing 777-300ER, and it usually takes close to an hour to board and depart. This was, much in theme with the current state of events, not what happened. We started boarding at around 4:50 am and departed 45 minutes after that. Misguided hope set in since I was now supposed to land at least 15 minutes before the next flight’s departure; I failed to consider that gates close 20 minutes earlier, meaning that the connection flight was 100% gone.

    I landed at 8:00 am on Doha, precisely 20 minutes before the next flight’s departure. I could see the status indicator go from “last call” to “gate closed” while I was headed to the Transfer Desk to determine the next steps. I could see that Qatar had already re-booked my flight to 2:15 am, Monday 23rd, so at this point, I was mainly looking for them to give me a meal and a place to stay while I waited, which they did.

    Little did I know that this was just the first half of the adventure and that Brazil would not treat me that much better than Qatar did.

  • Doha, Qatar

    Doha, Qatar

    I was stranded in Doha, Qatar, for a day (post incoming), so I took it as a chance to see the Museum of Islamic Art and the surrounding areas. These are some unedited sights.