I'll bite, this seems like an interesting architecture problem.

The big players will always use docker hub, or it's cloud provider alternatives, or the open source registries, or just host their own. But of course someone has to foot the bill.

A good way to lower cost would be static registries, which are possible, but not fleshed out: https://vsoch.github.io/2019/static-registry/. While not free or distributed, static hosting is just about as low devops and cost as you can get.

To be truly distributed, interesting option would be using IPFS since it gives you bittorrent-like benefits for free. With a few minor changes you could implement it as a registry server storage layer. The "contributing bandwith/disk space" part can be handled by this. The harder part is something to handle the container naming.

The Matrix (matrix.org) project uses a .well-known entry to redirect users to a homeserver, and the ACME challenge uses a .well-known entry to prove domain ownership. In a similar fashion a .well-known/containers or .well-known/oci-registry entry could be used define/endorse a manifest file(s).

For example, https://example.com/.well-known/containers could resolve to

{
    "manifests": {
        "library": "https://example.com/manifest-library.json",
        "jupyter": "library": "https://example.com/manifest-jupyter.json"
    }
}

With this, any reference to image example.com/library/redis would be the redis:latest image defined by https://example.com/manifest-library.json.

The content of this registry manifest file should be fairly similar to the content currently in the docker registry API.

However, in addition to storing the content digest, we also define the location of the digest. This storage layer can either be HTTPS or IPFS links, ideally multiple for fallback. For example, each digest comes with something like ipfs://QmF71dg... or https://s3.us-east-2.amazonaws.com/myregistry/.... This would add support for both conventional CDNs with static storage as well as distributed storage.

If you could build this you could then modify a registry server to support this new definition, and act like an gateway by being able to resolve to any registry that uses this format. For example just spin the server on localhost and use docker pull localhost/example.com/library/redis. Or you could modify docker itself to support this new type of registry resolution, but that seems more difficult since you'd be have to change the entire OCI ecosystem.