Identifiers and Naming, part 1

Selfreferential_vanity_plate identicon.png

Current Situation

  1. Tezos addresses can be used as ID, but there is no way to associate arbitrary information with them.
  2. Tezos addresses are hard to remember and compare. This is bad, because it makes confirming that an address is yours require more trust than needed.
  3. There are no vanity names linked to addresses (e.g… having galfour linked to my address). This is bad because some people love them. I personally doesn’t mind as long as it doesn’t interfere with other seemingly identical names (galfour vs gaIfour, DICTATOR vs DlCTAT0R).

Proposed Improvement

Basic Information on Smart Contracts

Naive Idea

Once we have views, it will be very easy to query information from a smart contract (SC). From this, we can simply have a SC exposing a big map from addresses to string. Anyone can then query the information, as only operations coming from the address can change the information associated to an address.

This should already be very practical for a variety of purposes. For instance, if the string associated to an address could be something like

  "twitter" : "LigoLang" ,
  "public-name" : "Galfour" ,
  "ip-v4" : "" ,


The problem with the naive idea is that this data cannot be used from within the chain, as there is no way (at least, not within gas limits) to parse JSON. (We would like to be able to do so, because that data might link to other addresses, which would then be used by other contracts.)

An alternative would be to use maps of strings to bytes, which can be used to encode objects. { "foo" : { "bar" : 42 }} would be encoded as map [[](> bytes_encoding_of_42 ] (PascaLIGO syntax). This is better than the previous solution, as it would now be possible to access data from other smart contracts.

However, it is still a temporary hack because

  • Some of the encoded values are not valid (you can have a foo key and a []( key), and
  • It requires PACKing and UNPACKing a lot of values.

A more stable solution would be to have an actual JSON-like type in Michelson. Given that we have to wait for a coming amendment for views, it’s not really a problem to wait for JSON too, assuming it’s added in the same amendment.

Unique Identifiers

Good Naming Schema

We want Tezos addresses to have a representation that is at least:

  1. Easily distinguishable from each others. So that people can’t try to impersonate you by creating a name similar to yours.
  2. Easily remembered. So that you can actually check if it’s yours from memory.
  3. Easily transcribed. So that you can easily input it on forms.

For instance:

  • Regular text, like domain names, satisfy 2 and 3, but don’t satisfy 1. It’s very easy to confuse galfour and gaIfour.
  • Hashes, kind-of-like Tezos addresses, satisfy 1 and 3, but don’t satisfy 2. It’s very hard to remember a tz1.
  • Identicons satisfy criteria 1 and 2, but not 3. Most people can’t reproduce/transcribe an identicon.

We could use a list of random words belonging to a list where all words are very different from one another. (We have investigated naming schemes a bit and are releasing a post about them soon.) Key considerations are:

  • The more words there are on the list, the harder it is to make sure they actually are very different from one another.
  • The longer the list is, the harder it is to remember its elements.
  • The more elements that have to be transcribed, the longer the list of words will be.

Naming Contract

The last consideration makes it important to constrain the name space.

There are vastly fewer addresses that will be in use than potential Tezos addresses. That’s why we want a namespace which size is comparable to the number of addresses in use than all the potential addresses.

A way to do is is to have a naming contract, where people can get a name. It should be priced, but only to avoid spam / squatting. So the price should be as low as possible, so that as many people as possible can get a name. Additionally, once you have a name, you have it forever, you can’t lose it.

The proceedings could then be used in a community DAO, a prediction-market based DAO, a Moloch-like DAO (which would incentivize tooling around names, as more tooling would result in more names being bought) or any other similar experiment. This is a nice organic opportunity to try something new!

Protocol Built-in

It might be possible to do this directly in the protocol with dedicated operations instead of a smart-contract, as this is such a core feature. However, before having a stabilized minimal API, it seems easier to experiment at the smart contract level.

Side note: Vanity Name Systems

At this point, we might notice that DNS blatantly fails some of these criteria for a good naming schema, because:

  • It is easy to confuse domain names (gaIfour vs galfuor)
  • Domain names can be lost (if you don’t renew it)
  • Domain names can be expensive (because of squatting / some domain being inherently expensive)

It’s because DNS is actually a Vanity Name System. The goal of DNS is not to easily find a website (this is done by Google) or to have prettier links (which I can already do with Markdown or HTML, like this). It is mainly to provide a vanity name, name that is mostly compulsory nowadays (imagine if Tezos Agora did not have a domain name!), so this is mostly a form of economic rent.

This in itself isn’t bad! It is simply not a good fit for a naming system that aims to provide identities for everyone and all.

To put a fair price on names in a vanity name system, which is manufactured scarcity, it might be a good idea to try something like a Harberger Tax, which was designed with a similar purpose in mind. Studying the effects of a Harberger Tax even for this toy product would be greatly beneficial, as a kind of a real-world economic experiment.

The main alternative to Harberger Tax is DNS, by giving ownership of a domain to its first claimant, incentivizes legal or illegal squatting of names and rent seeking behavior in general. By having to settle disputes itself, it also incentivizes centralization. To be honest, I hardly imagine any new proposed system doing worse than this.

(Remark: I imagine there is some wider point to be made about land.)

We are currently building the smart-contract for ID management, and will gladly let others build the Vanity Name System!

If you want to participate in any of those efforts (as a dapp developer, documentation writer or for wallet integration for instance), or simply be in the loop, please make yourself known :slight_smile:


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

The way i see it, even IF all exchanges, dapps, wallets, delegation services and tools implement it, it would still just be a very minimal improvement to UX.

What would be an example use case that makes this more than just a nice-to-have ?
And what would be an example use case of improved UX using this that can not be more elegantly solved by Wallets?

A few notes:

  1. 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…
option (or int (or string (or (list bytes) (map string bytes))))

The recursive type definition is achieved using bytes, but we always know what type those bytes should be deserialized to, so we can process the MSON values recursively if need be. There may be runtime typing errors when extracting the Json value, but only if it’s invalidly formed.

  1. 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.

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.

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.

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.)

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