It has always been possible to store immutable data in the DHT, that's partly what it was built for. "This is a sha1 of a content, I want to know what content i

It has always been possible to store immutable data in the DHT, that's partly what it was built for. "This is a sha1 of a content, I want to know what content is behind" There is a BEP (Bittorrent Extension Protocol) for storing mutable data: like all good things in computing, it's just an indirection. Create a pair of asymetrical cryptographic keys for a specific (mutable) content and store the hash of the public key. People will search for that hash, get to some content that is any bytes you want but signed with the private key. What you want is not exactly that, but more of a naming system. The easiest would be to let each image owner be their own source of truth: the redis team puts up an HTTPS server with a well known path, say "/.well-known/docker?identity=redis:2.0" and the reply includes the magnet link. My node would cache the association under the assumption that it never changes (it shouldn't; a change in the image implies a change in the name). As you yourselves discovered, the swarm doesn't solve the naming issue (ie Zooko's triangle), there needs to be a third-party here