Hi everyone, I am Huy and I am going to talk about InterPlanetary Wheels,
a project that I have been working with in the last few months.
It aims to distribute software more resiliently.
To be more specific, it is Python packages that we are distributing.

Currently, the most common way to get your Python software is to install it
from PyPI.  While there are several other sources, such as the distros
packages, or Anaconda, but distros packages are not something that most
programmers use for their development, and Anaconda is not really free
software, so let's not consider these alternatives for the moment.

One of the main problems with PyPI that we are trying to tackle is
centralization, which leads to it being a single point of failure.  When PyPI
undergoes an outage, Python developers simply cannot get the packages they need
in time.  Another problem with centralization is that having checksum and URL
from the same origin is not really a secure thing.  Another problem with
getting packages from PyPI is that whenever you install a package from it, pip
has to resolve the dependency, which is a costly execution yet not
future-proof.  Last but not least, while being centralized, PyPI is not a
curated repository: anyone can publish a package.  It is therefore prone to
typosquatting and malware, which is a problem JavaScript developers have
suffered at least twice with the left-pad incident, and more recently, the
faker.js and color.js being turned soft-malware.

As for outages, it is not unprecedented.  In fact, it happened at least twice,
each lasted for hours and gravely affected Python developers.

Many developers have come to some workarounds, such as:
pinning dependencies, though this often leads to conflicts;
replicating checksum hashes, though this is quite cumbersome;
or running a mirror, but this requires hand-picking the packages for the project

We came up with a different approach to this problem: we cherry-pick packages,
making a curated repository, kinda like how distros packaging works.  More
importantly, we want to decentralize our repository.

To build our repository, we implement Python simple repository API, a standard
defined in PEP 503. It requires a HTML view of directory-like tree, where
wheels for each package resides in the same directory.

To store our repository, we use IPFS, which is a peer-to-peer network, so there
will be no single point of failure.  Because the content-addressing is done in
global namespace, IPFS clients are organic mirrors.  IPFS makes use of Merkle
DAG, which means that given a parent ID we can be sure its child contents are
not tampered with.  Additionally, it has an HTTP gateway with a directory tree
in HTML, which is conveniently suitable for implementing the chosen Python repo
API.  Using IPFS for storing repository is not something unique to our project,
though: any kind of software repository can be stored on it, and in fact there
have been attempts to create an OpenBSD and a pacman mirror on IPFS.

With these decisions, we came up with Floating Cheeses, which are often found
in the flying circus.  A more serious name is InterPlanetary Wheels.  As I said
previously, it implements PEP 503 and is stored on IPFS, which gives its name.
Additionally, we ensure that the wheels are platform-unique and
singly-versioned, kinda like how distros work.  It uses a declarative index,
which is similar to how packaging is done in nix.

Firstly, for each package we write a declaration with this format (though this
format might be subject to changes).  After that, we run checks for criteria to
ensure the properties we defined previously.  Finally, every week we publish
releases from these declarations on top of previous versions to one single CID.
If a package is not updated, it will be shared between releases, thanks to how
IPFS work.

So, how to use these packages?  Firstly, you need to get the latest CID from
our repo.  Then, set up an IPFS gateway, then configure pip to install
from this gateway.  After that, installing packages is quite straightforwards.

I have tried these packages for some of my other projects, and I am quite
satisfied with how fast it is to install packages, thanks to not having to
resolve dependency and also thanks to caching.  Though, more important is that
it is more secure and reproducible, which is an important part of being
resilient.  In addition to ensured integrity and being always available, we can
be sure that we execute no untrusted code from source distributions.
Reproducibility is also more easily ensured with one CID instead of multiple
versions and hashes.
Package integration is also a breeze with floating cheeses.

In the spirit of Free Software, collaboration is also encouraged:  as
downstream maintainers, we're more eager to contribute to upstreams.  Users of
InterPlanetary Wheels are encouraged to collaborately self-host to increase
availability.

The repo is not without its drawbacks.  Currently, we're lacking maintainers,
so we don't have the human force to review and test each packages.  It also has
a small number of packages, currently about 600, and 100 of which are outdated.
We also have a limited support matrix: so fare, only x86-64 platforms are
supported.  It is also lacking mirrors, though this is a matter of popularity
and adoption.

To address these issues, we plan to run packages test suites in the future and
invite more participants to our project.  We also aim for reproducible wheels
and plan to implement environment self-markers, which will helps us support
more platforms.

You can help us by running a mirror, which is as simple as pinning the latest
CID on IPFS.  You can also contribute to our repository at this link.
We welcome your questions and feedbacks at our mailing list, in our matrix room
or IRC channel (ipwhl).

Thank you for listening.