Identifiers and Naming, part 1

[galfour]

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" : "127.0.0.1" ,
}

Extension

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 [[foo.bar](http://foo.bar)-> 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 [foo.bar](http://foo.bar) 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

[Johann]

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?

[murbard]

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.

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

[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

[zamrokk]

Going to revive this topic after 3 years

Lets’ have a simple approach with a real use case : the Shifumi mobile game (Tezos Shifumi - YouTube)

When you create a new game, you need to invite an opponent , i.e a tz1… address . Ideally, we should be able to select a list of names or pseudonyms and the tz1 address should not be eventually visible to the end user
On the video, for the sake of ease, we see the web base version showing 2 players playing on the browser (So I cheat doing a “copy to clipboard”). But the real game is a mobile game, so just imagine how hard is to write a tz1 address by hand at this stage.

It is a real problem today to not have a contact list feature in Tezos.
Let’s see potential solutions :

1. DNS-like base : like .tez domains
   Good : we have the basic name to address feature, information is available onchain
   Bad : not free, identities can change over time, speculation, few number of users

2. on chain contact list : deploy a KT1 exposing a contact list map where each key (=address) is protected on write over a list of encrypted contacts (made by user private key)
   Good : one place, on chain, can bring more feature that just .tez domain, forever storage with no fees
   Bad : still (very low) gas cost to update the map, malicious actor could potentially try to link an update of a map with a close transfer based on timing and so, identify a contact (well public identities should never hold a huge balance to avoid to be hackers honey pots), wallets/beacon would have to propose a “decrypt” feature decrypt(payload : bytes) : string

3. off chain contact list : Metamask contact list-like. Today, Tezos wallets allows to add our own accounts, not other people hashkey addresses
   Good : secure totally off chain feature that could be in a browser extension or mobile app so we cannot link blockchain interactions and contract list accesses
   Bad : requires to push a new standard/protocol for each wallet <-> dapp conversation to get access to the contact list, need a sync mechanism between the browser extension and the mobile app to avoid to duplicate this list over x different devices or OS (like Temple does today), no forever storage (if you lose your mobile or your computer, you lose your contacts)

I would like to have feedback on which solution you think is matching your needs

1 : exist already
2 : can be done but requires beacon/wallet update
3 : can be done but requires standard writing and then wallet update

[Dibididabdabduu]

@zamrokk

DNS-like base : like .tez domains

Like you stated - this exists already and imo plays perfectly into your third mentioned solution:

@zamrokk

off chain contact list : Metamask contact list-like.

I see this as the better approach. We should not pollute the protocol with fiddly features like contact lists - it should only offer means/endpoints for dapps to do so. Dapps should be able to easily fetch contacts and be able to rely on a standard format (if more than just the tezos addresses is of interest). The Beacon interface could aid with this, just as it does with for transaction signing.

Pre-installed contact apps on smartphones usually also provide the option to add custom contact identifiers (instead of plain phone numbers). This would be a possible place for saving tezos addresses, which multiple wallet apps or the beacon interface could rely on for scanning.

[zamrokk]

@Dibididabdabduu

ct apps on smartpho

The closest field I found on Android is the nickname

[zamrokk]

Same field for iOS, nickname sounds the best option

[zamrokk]

Only problem I have with this is that is stored by a Cloud provider (Google or Apple), so at the end, it not 100% personal information … (Cloud Act , etc …)

This maybe ? Introducing Encrypted Contacts for Android and iOS, now available through Proton Mail’s mobile app | Proton

EDIT : I sent a request to Proton team
maybe using Android function : Getting a result from an activity  |  Android Developers

[zamrokk]

@AirGap_it : have you tried to implement option 3 “Standardize address book on the wallet side” like Metamask is doing ?