If you want to do anything decentralized, I highly recommend to read all of the scientific papers from the gnunet authors. They theoretically solved a lot of problems a long time ago that modern distributed projects keep repeating.
About the name system: It is a bit more complex than that. Everybody can "create" a domain, but others must import it's public key, somewhat compatible to a hosts file. The trick is that each domain can have arbitrary subdomains, also stored in the DHT. Now one can construct arbitrary deep trees. And everyone can choose a list of their trusted TLDs, and use them to resolve names. Say site.alice.bob.gnu (where .gnu is shipped with the client as default) and if I personally decide to trust Alice directly, I put her public key into my config file and from now on I can use site.alice instead without ever touching bob.gnu or .gnu again. Their DHT comes with unusual privacy guarantees due to clever cryptography. Furthermore gnunet already researched filesharing using content addressed blocks to allow for deduplication. Very clever. Unfortunately the implementation is not very usable and kind of stale. Some of these file sharing concepts are also better implemented by Freenet, which is a kind of anonymous decentralized web, even somewhat usable. A pity that those projects seem kind of stuck.
> The trick is that each domain can have arbitrary subdomains, also stored in the DHT. Now one can construct arbitrary deep trees. And everyone can choose a list of their trusted TLDs, and use them to resolve names. Say site.alice.bob.gnu (where .gnu is shipped with the client as default) and if I personally decide to trust Alice directly, I put her public key into my config file and from now on I can use site.alice instead without ever touching bob.gnu or .gnu again.
Which is ridiculous -- it makes names unreliable as public identifiers. Sure, you can refer to Alice's site as "site.alice", but nobody else can resolve that name unless they share your configuration. Worse, it means that anyone who has a different key mapped as "alice" might see "site.alice" resolve to something completely different than what you see.
In practice it'd probably end up like the sources.list in Debian. E.g., an enormous number of users just use whatever pasta is copied in there by default. Then special devs change it or copypaste a Debian spell to magically add repos for whatever special cases they have.
And let's be honest-- if someone on HN were to post, "OMG the security updates repo got DDOS'd in Debian" it's not like the entire comment section is going to be filled with confused responses like, "Wait, do you mean the security updates for the gitlab repo that I added for my gitlab instance, or Debian's security repo for Debian the Universal Operating System?"
If you like the idea of both the decentralized resolution and using the DHT as a PIR, you might look into it.
Also-- if you find it's the case that it's not currently usable (which I'm guessing is the case), it might be worthwhile to mention on your README that you looked at this as an option and then briefly state the reason(s) why you can't use it in practice. If enough prospective users of gnunet do this it may motivate the maintainers to do something about the current state of the documentation and usability...