Interesting thought.
But honestly, all I can now think of is 5e336907a3dda5cd58f11d162d8a4c9388f9cfb2f8dc4b469c8151e379c63bc9.npub ... xD
nostr:note10zyv7cjjwa2m2d29dfulym4pz06vfc5yr0xfehchdmpxg9qwydfqskulqx
Today I saw a reply from nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 and I couldn't see the note he is replying to, until I manually took the event key and relay mentioned in the reply tags and queried that relay myself.
If the original poster migrated relays since (think forum comments from a year back) then there would be no way to find that note again.
Even worse nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj himself can't actually migrate while ensuring all his notes moved, because Nostr events aren't In an authenticated data structure, full sync is impossible to verify.
While this works fine for what Nostr was invented for, to replace the general usecase of the Web, we need to a proper sovereign DNS equivalent like #pkarr, and we need user's data to be durable, not just host agnostic.
And yes ed25519 + key delegation is a must, and they will absolutely pay for their complexity by providing long lasting identity, and anyone who says this is not practical is bearish Bitcoin because Bitcoin doesn't mean shit for anyone who can't keep a key cold.
Discussion
It is not enough to just make up a TLD, who is going to run that TLD? What happens when they censor you just like existing DNS can? How to stop spam and sybil?
All these questions are exactly what pkarr.nuh.dev was made to answer.
1. Bittorrent DHT is how you maintain ultimate censorship resistance
2. If you don't keep republishing your DNS-like record it gets dropped by the nature of the DHT, so that solves spam and Sybil
3. Your relay/hosting provider(s) who you already pay for keeping your data, periodically refresh your records on the DHT
Most importantly I tested all of that and showed that a small server can keep up to 100k users records alive on the DHT with >95% availability
Once you add aggressive caching, it is a solved problem.
But it will demand switching to ed25519 as the root identity