Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Evaluate using ENS for human-readable Package names #81

Open
shrugs opened this issue Apr 11, 2018 · 3 comments
Open

Evaluate using ENS for human-readable Package names #81

shrugs opened this issue Apr 11, 2018 · 3 comments
Milestone

Comments

@shrugs
Copy link

shrugs commented Apr 11, 2018

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

@spalladino spalladino added this to the v0.2.0 milestone Apr 12, 2018
@frangio frangio changed the title Evaluate using ENS for human-readable Distribution names Evaluate using ENS for human-readable Package names Apr 22, 2018
@frangio
Copy link
Contributor

frangio commented Apr 22, 2018

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!

@shrugs
Copy link
Author

shrugs commented Apr 22, 2018

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.

@frangio
Copy link
Contributor

frangio commented Apr 28, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants