Identifiers and Naming, part 1

[galfour]

@Johann

This is not a new idea, and some old ideas, like ENS, although implemented almost universally, basically don’t get used.

Attaching information to an address via a name is indeed not a new idea. This post is more about how to do it well, and explaining why we do it with a name in the first place.
However, if you were referring more precisely to the address -> practical name -> vanity name architecture, we’d be interested to hear more about this (for instance, ENS is pure vanity, and Urbit does not fix the price of its names).
The next post will cover what we encountered in our research, and we simply have not found this.

@Johann

What would be an example use case that makes this more than just a nice-to-have ?

Although attaching a name to an address is only part of the suggestion. It has to be done well and is actually quite complicated, hence the focus on this. The use-case of attaching a name to an address is akin to the one of a phone number, an email address or a website domain: establishing first contact in a way that is reliable over all media.
For instance, let’s say we used QR Codes instead of names. I can’t really communicate a QR Code over a phone call, write it on a piece of paper. It also far from trivial to copy it from my phone to my PC, or from a picture to a form.

So, as a canonical representation of an address, a name is quite good. And, if it looks like I’m overselling it, I actually am not, this is pervasive for a reason. Although most apps, websites and services, automatically attach an incremental/hash ID to most users, they still ask for a nickname and use it everywhere. Because it’s just that practical.

---

But even then, attaching a name to an address is only part of this. More important is to attach arbitrary information. For instance:

• An IP address
• The information needed for a Bakers Registry
• My Agora handle

I actually expect most of the use-cases to come after this is built. Like, it would be possible to build in isolation all those things as separate registers and their own apps. But it seems like painful redundancies, especially with regard to integration in apps and wallets.

@murbard

You can already create JSON-like types in Michelson. For instance, you can define a "MSON "value as either an integer, a string, an array of bytes representing MSON values, a map between strings and bytes representing MSON values, or nothing…

You are right. We can have a lot of things in Michelson working with dynamic typing embedded in bytes (recursion, for instance, iirc), but I don’t know how far we want to go in that direction. (For instance, I might prefer a single bytes type, and deferring type checking to upper level languages. While others might not.)

@murbard

It’s not that hard to ensure that a list of words is sufficiently distinct, you can for instance mandate a minimum Levenshtein distance of 3 between any two words. Compiling a list of merely 10,000 words would probably be enough to identify all addresses for a very long time if they are assigned sequentially.

We talk about this in the next post, I guess it will be better to discuss it there. But yeah, once we get to an explicit list of constraints/considerations, we could:

• Start with this
• Filter it down with the constraints/considerations that can be computed
• Have people experiment with samples