You're basically describing a name service: a way to associate a stable name (like "Yuzu" or "PGP:ABCDEFG..." or whatever) with a changing, mutable identitfier (like a Git commit ID, an immutable IPFS URL, a Bittorrent magnet link, etc.).
The most obvious example is DNS, which is technically capable of this, but is mostly not set up in the ways we'd want. It's pretty centralised: so whilst anyone can host their own DNS servers, serving any data they like, it's unlikely the "main" DNS network will connect to it; and will consider you malicious if your data disagrees with the centralised records. Things like DNSLink can be useful for associating as DNS name with names in other systems, but that's still vulnerable to hijacking/poisoning without an out-of-band way to verify it.
The GNU Name System seems better suited, since it can use public keys for stable names, which therefore can't be hijacked/poisoned. Associating these to pet names is also less centralised, feeling more like /etc/hosts than "the" DNS; with recursive resolving, so e.g. I can look up "Yuzu" based on what you think it is, etc. That seems to provide a nice balance between decentralised control, versus relying on side-channels to find public keys. I'm currently experimenting with this.
There's also IPNS, but in my experience its lookups are incredibly slow and unreliable. It could get better, and I know various studies are being performed and experiments with different approaches and parameters are being tried, so I'm hopeful something will come of it.
As far as I remember, the main reason Radicle diverged from these approaches (and IPFS/IPNS in particular) was to allow peers to negotiate delta transfers, like (non-dumb) Git HTTP servers do. That's more efficient than using something like IPFS/IPNS, where the root address keeps changing, and we need to fetch a load of the Merkle tree to find out which blocks we already have.
The most obvious example is DNS, which is technically capable of this, but is mostly not set up in the ways we'd want. It's pretty centralised: so whilst anyone can host their own DNS servers, serving any data they like, it's unlikely the "main" DNS network will connect to it; and will consider you malicious if your data disagrees with the centralised records. Things like DNSLink can be useful for associating as DNS name with names in other systems, but that's still vulnerable to hijacking/poisoning without an out-of-band way to verify it.
The GNU Name System seems better suited, since it can use public keys for stable names, which therefore can't be hijacked/poisoned. Associating these to pet names is also less centralised, feeling more like /etc/hosts than "the" DNS; with recursive resolving, so e.g. I can look up "Yuzu" based on what you think it is, etc. That seems to provide a nice balance between decentralised control, versus relying on side-channels to find public keys. I'm currently experimenting with this.
There's also IPNS, but in my experience its lookups are incredibly slow and unreliable. It could get better, and I know various studies are being performed and experiments with different approaches and parameters are being tried, so I'm hopeful something will come of it.
As far as I remember, the main reason Radicle diverged from these approaches (and IPFS/IPNS in particular) was to allow peers to negotiate delta transfers, like (non-dumb) Git HTTP servers do. That's more efficient than using something like IPFS/IPNS, where the root address keeps changing, and we need to fetch a load of the Merkle tree to find out which blocks we already have.