Evaluate using ENS for human-readable Package names
Opened this issue · 3 comments
Zeppelin could install a first-come-first-served subdomain registry (ala aragon-id) and use ENS reverse lookups to get the distribution's contract address.
Something like openzeppelin.zos-distributions.eth would reverse lookup to whatever contract you'd normally have a registry for.
Depending on the subdomain registrar, you could abstract the ENS complexity away with a simple ZepCore#claimDistribution function
With the Package concept we've introduced, and the general direction we're taking, this is starting to make a lot of sense.
If we do this we should take measures against typosquatting (minimum string distance between package names?). Not sure how feasible this is to do in a smart contract. Sounds like an interesting algorithmic challenge!
I expect you could easily code the Levenshtein distance logic into the registrar, as well as things like requiring ascii-only character points (so no unicode obscurity) and such.
The thing is that we should compare the distance against all other names in the registry. Apparently there is a thing called "levenshtein transducers" that does exactly this, by building an automata to compare against all strings of a set. In this case the set would be changing with each addition to the registry though, and I haven't looked into how that would be hadled.