Peer-to-Peer Package Managers can Solve Open Infrastructure's Problems

The OpenSSF published a joint statement in collaboration with numerous public package registries addressing a problem caused by rising costs without an increase in funding or support. These rising costs (largely attributed to the rise of generative agentic AI) have raised serious issues with the current model of public package registries like crates.io, PyPi. The OpenSSF statement advocates for commercialization and private partnerships to bolster the current structure. This is risky and out-of-line with the Open Source ethos. We can better solve these problems with peer-to-peer package manager, specifically built on Hypercore, written in Rust.

What's Wrong in Package Registry World

Modern programming languages are expected to have package registries that are fast, open, secure, and (very importantly) free. These package registries are an interesting intersection of vital infrastructure, community governance, and commercial incentives. Funding comes from commercial entities or from Foundations like the Rust Foundation which manages crates.io or the Python Software Foundation which manages PyPi. However these foundations also depend on commercial philanthropy for their survival. There is no direct profit incentive for a firm to fund a registry, because after all, they're expected to be free. However a registry outage can be extremely costly. So foundations (like the Rust Foundation) solicit funding in the form of memberships from firms. The income helps the foundation fund the registry maintenance, and in exchange the firm gets influence over the foundation (up to getting a seat on the board of directors).

Despite this funding, it isn't enough. The management of package registries depends heavily on volunteers, there are paid roles but it's mostly contract work, and often paid at below the current (USA) market rate. So underpaid, understaffed communities have been carrying the burden of running these registries, and they’ve recently been confronted with a higher demand, along with less "open" use, as the OpenSSF statement details:

Automated CI systems, large-scale dependency scanners, and ephemeral container builds, which are often operated by companies, place enormous strain on infrastructure. These commercial-scale workloads often run without caching, throttling, or even awareness of the strain they impose. The rise of Generative and Agentic AI is driving a further explosion of machine-driven, often wasteful automated usage, compounding the existing challenges.

On top of the increased demand, the nature of the content distributed has been changing: instead of free and open source software, registries are increasingly being used to distribute binary blobs for for-profit proprietary software.

In other words, private companies are exploiting public registries for their own financial gain, while driving up hosting costs for non-profits that run these registries.

OpenSSF Proposes More Commercialization

To solve this problem, OpenSSF advocates for a commercialization of registries, proposing access models and paywalled features, giving corporate benefactors further influence over package registries. We don't need to do this! Peer-to-peer is such a perfect fit for these problems, and it avoids further entangling community and commercial interests. We can fix this by building a hybrid peer-to-peer / server-client package manager, built on Hypercore, written in Rust. Almost all of the “modern expectations” for package registries listed by the OpenSFF could be addressed by this. Let me explain by going through some of “expectations” listed by the OpenSFF, explaining what it can address, what it would and wouldn’t do.

1. Dependency resolution and distribution must be fast, reliable, and global.

   Peer-to-peer applications are well known for being able to quickly and reliably deliver high-demand content, in fact, the higher the demand, the more efficient its delivery. But what about content that isn’t “high-demand”? We can use a hybrid approach: package registries act as long term seeders - they would always be available to download a package from (the same way they are now). Basically we would fallback to centralized package management for less popular content.

2. Publishing must be verifiable, signed, and immutable.

   This is a first class feature of Hypercore. Hypercore is a public key cryptosystem. When the owner of the secret key adds data, it includes an ed25519 signed blake2b hash, which is stored in a merkle-tree-like structure.

3. Continuous integration (CI) pipelines expect deterministic builds with zero downtime.

   Hypercore has no single point of failure to cause downtime, and the immutability of data provides the determinism.

4. Security tooling expects an immediate response from public registries.

   Things like vulnerability advisories, yanked or deprecated versions, key revocation etc. can all be distributed quickly and easily in a centralized or peer-to-peer way.

5. Governments and enterprises demand continuous monitoring, traceability, and auditability of systems.

   Hypercore, being an immutable, cryptographically signed data structure, covers a lot of this. But more interesting are things like attributing a key to a legal entity. The next item is related.

6. New regulatory requirements, such as the EU Cyber Resilience Act (CRA), are further increasing compliance obligations and documentation demands, adding overhead for already resource-constrained ecosystems.

   More regulatory requirements. There are many ways you could layer compliance onto a peer-to-peer system. There is still work to do to figure this out, so I'm leaving this up to future implementors.

7. Infrastructure must be responsive to other types of attacks, such as spam and increased supply chain attacks involving malicious components that need to be removed.

   These security issues require a centralized authority to address, this would be the registry. It would manage the global package namespace and so it would handle package removal, and typo squatting.

So Hypercore could address some major needs, while simultaneously dropping server costs and maintenance work. Addressing issues of compliance, security, and social concerns, is up to the community, and Hypercore is a tool in whatever solution they choose.

What would a peer-to-peer package manager look like?

Take Rust’s cargo as a concrete example. Here is a simplified version of how it could work.

Publishing

From a developer’s perspective, publishing looks the same. On the registry side, it’s just a Hyperbee (a key/value B-Tree built on Hypercore) keyed by package name and owned by the registry. Each entry in that namespace points to a second Hyperbee, keyed by version, that is owned and controlled by the developer. Claiming a new package name means the registry adds an entry pointing to the developer’s public key. Publishing a new version means the developer appends to their own Hyperbee.

Because each Hyperbee is an append-only, cryptographically signed log, every entry is immutable and verifiable by anyone. The registry holds the secret key for its namespace Hyperbee, which lets it remove package names to deal with things like typosquatting or malicious actors. However, the registry cannot alter package contents or history, because the secret keys to the packages themselves are held by the package authors.

Dependency resolution

For a client to resolve a dependency like tokio = "1.48.0", it starts by looking up tokio in the registry’s namespace Hyperbee to get the developer’s public key. Basically this is hb.get("tokio"). With that public key the client can query the DHT to fetch tokio's Hyperbee. The structure of this Hyperbee is a map from versions to package contents. Since map is ordered, the client can traverse the keys until they find the version they want: 1.48.0, then they can begin downloading the package data from peers.

Hostile networks: client fallback

Many corporate networks block p2p traffic. In cases like this, the client could fall back to centralized downloads, just like plain cargo. Any real package manager would need to work on networks that aren’t p2p-friendly, so I think a centralized fallback mode would be a hard requirement.

Low-demand packages: registry fallback

P2P only works when peers are online, and obscure packages might not have any. One solution would be to have the registry owner act as a seeder for all packages as a fallback. This is effectively what crates.io already does. I don’t have data to back this up, but I expect that most downloads are of the most popular packages, so most downloads could be peer-to-peer for free. While most packages are unpopular, they are not most of the downloads. For these packages, the registry owner would be the seeder of last resort, or the client could fallback to a regular download.

Privacy and Money Making

The OpenSSF proposed "value-added capabilities" and "tiered access models" as ways to generate revenue for package registries, but this risks giving corporate benefactors further influence over the registry, which is precisely the conflict of interest we should be trying to avoid. A peer-to-peer hybrid model offers a cleaner path: charge for the non-p2p option, and keep the p2p path free and open by default.

And they will pay. The biggest reason is privacy: Hypercore is secure but not private, and peers can associate package downloads with IP addresses.

For some corporate users this is a non-starter. Exposing which packages you use and when you download them could be used to infer what you're building, your release cadence, or map internal tools and processes. Additionally many enterprise networks block p2p traffic outright.

Fortunately these corporate users, for whom p2p might be the least suitable, are often users who are willing to pay for software. There is an opportunity here to create a sustainable revenue model without compromising open access. Individual developers, open source projects, any one who is okay with p2p's security model gets their packages for free. Users for who p2p is a no-go can pay for centralized downloads.

Why we Need Rust

The de facto Hypercore implementation is written in JavaScript. That works for integrating with npm, but not for something like cargo: you can't call into a JavaScript library from Rust. More broadly, JavaScript has no reliable path to being language-agnostic. Rust does: it compiles to a C library, and C libraries can be called from virtually any language. A Rust implementation of Hypercore could be a foundational building block for integrating Hypercore into any existing package ecosystem.

For the past few years there has been an effort to rewrite Hypercore from the ground up in Rust, and I've been leading that work. As of early 2026, the major pieces are in place: peer discovery, peer-to-peer replication, and Hypercore itself. We're now in the process of wiring them together into a cohesive whole, so we can provide a stable, ergonomic API which will feel familiar to developers coming from the JavaScript implementation.

The open source infrastructure that the broader ecosystem depends on is at a crossroads. If this work matters to you, please get involved: check out github.com/datrs and reach out. If you'd like to contribute financially, consider sponsoring on GitHub. This is one concrete path forward, and it needs people to build it.