Add ENS support

[Arachnid]

With ENS support, you could allow users to choose easily memorable names that are associated with their public key or hash.

[0xc1c4da]

Great idea something we've been thinking about for sure, we'll certainly enable ENS for the !browse command when we deliver Swarm support, for username maybe something similar would work, not sure if an auction for name registration is super ideal? What are your thoughts?

[Arachnid]

No need for an auction - you could register 'mystatus.eth', and set up your own first-in-first-served registrar that lets people instantly register 'myname.mystatus.eth' and point it at their newly generated wallet.

[rabbit]

if you wanna get really crazy you can also register 'xn--os8h.eth' which is 💬.eth so I can then be 🐰.💬.eth and emoji shortcut my way in 😅

[0xc1c4da]

@Arachnid of course! I'm not sure why I didn't think of that, we were thinking of doing exactly this for an unannounced feature, Moments, using Swarm.

@rabbit that is actually super cool, I'm going to register it today!

One thing we're trying to figure out, is what is going to be the status.eth domain we use, since it's only 6 characters and we need 7. Best thoughts so far are statusg.eth and statusim.eth but eh...

[rabbit]

I'd recommend statusim.eth as its most consistent with your branding or as Nick suggested mystatus.eth parses well. Alternatively, statusapp.eth follows well known web conventions. Unless I'm mistaken it's a situation that would only last for maybe a year or so before you can get status.eth so nbd

[0xc1c4da]

Followed http://docs.ens.domains/en/latest/auctions.html and have setup 2 auctions 👍

[Arachnid]

if you wanna get really crazy you can also register 'xn--os8h.eth' which is 💬.eth so I can then be 🐰.💬.eth and emoji shortcut my way in 😅

I'm afraid ENS stores unicode directly, instead of using Punycode - so you can register that, but nothing ought to resolve to it.

[0xc1c4da]

but the punycode version passes the 7 character limit hurdle, and we can clean it up in the frontend, of course this creates a problem if a single unicode char could be registered

[Arachnid]

If you do that, though, you won't be compliant with the spec, and your users will get different results for domains that contain unicode characters compared to users on other platforms.

[0xc1c4da]

yeah :) I understood that before posting, my point was, it's easier for us to implement punycode on the client and have a fun name in ENS than to have what we want.

I'm really looking forward to a more effective solution against the first mover advantage than imposing an arbitrary limit on the amount of characters (what about the other 34% >7 words in googles english top 10000 word frequency list), my understanding the current plan is to deploy the current implementation to mainnet and revisit in 2 years?

Specs aside, we are talking about branding, and making pretty, accessible names resolving to ugly objects. It was hard enough to get status.im as a domain and it's not status.com, and I find myself applying the same 'creative' domain hackery on a new system before it's even deployed.

I'm very excited to use ENS as <username>.status.eth even though I understand that a dispute system opens up a whole can of worms.

[rabbit]

I obviously meant this as a one off silly suggestion but I don't understand, @Arachnid a browser would be doing the conversion prior to any request, no? storing unicode domain names sounds like a supremely exploitable problem. I thought that was the point of punycode.

[rabbit]

situation is worse than I thought seems to be a series of contextual rules? not great...

[Arachnid]

I'm really looking forward to a more effective solution against the first mover advantage than imposing an arbitrary limit on the amount of characters (what about the other 34% >7 words in googles english top 10000 word frequency list), my understanding the current plan is to deploy the current implementation to mainnet and revisit in 2 years?

That's right. We're acknowledging that we can't build a perfect system first off, so we want to get things off the ground with a simple system that works, and give people time to propose better long-term solutions.

It's even possible we'll reduce the minimum length before the switchover, but it'll certainly start out at 7 characters. Unless you can propose a way to hand these out fairly when the system is still in its infancy. ;)

I obviously meant this as a one off silly suggestion but I don't understand, @Arachnid a browser would be doing the conversion prior to any request, no? storing unicode domain names sounds like a supremely exploitable problem. I thought that was the point of punycode.

The point of punycode is to support Unicode domain names in a system that only reliably transports 7-bit ASCII. ENS doesn't have this issue, so it encodes Unicode directly instead. Resolvers shouldn't do punycode encoding before doing lookups for this reason.

Nameprep normalises equivalent names (case folding, etc), while browsers or registrars are expected to prohibit homoglyphs in names. Because doing this is so complex, and because the onchain system works with hashes, we're punting the latter to browsers. Fortunately, this seems relatively well established; see Mozilla's algorithm for example.

[0xc1c4da]

Hmm, okay, but that these algorithms revert to displaying punycode otherwise, so we'd be implementing it anyway, meaning that xn--os8h.eth would be a valid domain. Talk about a rock and a hard place.

For reference here is how Chrome handles it.
http://www.chromium.org/developers/design-documents/idn-in-google-chrome

[Arachnid]

Hmm, okay, but that these algorithms revert to displaying punycode otherwise

Good point; perhaps some other alternative would make more sense here, like highlighting the problematic characters?

[rabbit]

my head has exploded enough over this. character encodings and time are the bane of our existence. I defer to others.

[0xc1c4da]

Just registered statusim.eth

Alex Van de Sande @alexvandesande 20:46
@jarradh don't forget it's testnet only now. You should create a subregistrar so your users can immediately claim myusername.statusim.eth

[masterial]

+1

[jeluard]

Relates to #4747 and #5028

[chadyj]

As @jeluard mentioned we are actively workign on ENS resolution support in chat and wallet, as well as ENS registration. I'll close this in favour of the more granular issues.