Human-Friendly User Identification (HFUID) is a problem commonly encountered in various multi-user communication networks. HFUID consists of several essential requirements, namely: Uniqueness, Memorability, Comparability, Stability, and Embedability.
In this is article, I will discuss existing practices and explore possibilities for our new unique scenario.
Glossary
Phrase
Definition
Human-Friendly User Locator (HFUL)
A string which is used to uniquely identify a specific user in a multi-user communication network and is easy to remember and compare.
Uniqueness
An HFUL should be unique. It should be collision-free at a large scale. And the uniqueness should not be harmed when the deployment model is a non-authority network or a federated network.
Memorability
An HFUL should be memorable. For example, although a UUID is unique enough, it is not memorable. To be memorable, the HFUL should allow meaningful substrings. Also, the meaningfulness should not be restricted to a single language.
Comparability
An HFUL should be comparable. For example, If "I" (Uppercase ASCII letter between H & J) and "l" (lowercase ASCII letter between K & M) appear often, the string is hardly comparable with other similar strings. In many scenarios, this requires the involvement of the user.
Stability
An HFUL should be stable. It should not be easily changed when the user updates the Display Name.
Embedability
An HFUL should be embedable. It should be safely included in URLs and other common carrying formats without escaping or encoding. For example, if "#" and "?" are allowed in the HFUID, it cannot be embedded in a URL.
Classification of Existing Practices
Overview
Existing Practices can be divided into 5 categories, as sorted by Customizability (descending):
Cat1: Bare Username
Cat2: Namespaced Username
Cat3: BattleTag
Cat4: QQ Number
Cat5: OpenPGP Public Key Fingerprint (Including Shorter Versions)
As the Customizability decreases, the Stability increases.
Cat1: Bare Username
A user can manually choose a username as long as it is not occupied by another user already. This username is unique to the entire network and has no namespace applied. The collision management requires a central authority to allocate usernames.
Cat2: Namespaced Username
Email addresses are essentially usernames with Namespace. Email is a federated network. Each server is an independent node and manages its own usernames within its namespace where the namespace is its hostname. On a larger scale (Internet), hostnames require a series of hierarchical hostname authorities (TLD) to allocate. Also, in an autonomous network, local TLD consensuses can be reached.
In the Email ecosystem, the TLD NIC does not directly manage each email user. This provides the flexibility and reduces the burden of the central authority of the top-level namespace. However, this practice unnecessarily binds the user to a particular server, and this has been increasingly unfavorable over the recent years, as the right of migrating and synchronizing data across servers has gradually establishes its importance.
Cat3: BattleTag
A BattleTag consists of 2 parts, the Display Name and the Suffix; and they are joined by a "#" character. The Display name is arbitrarily selected by the user, and the Suffix is appointed by the server (4 digits, non-sequential).
This practice allows up to 9999 users to share the same Display Name . When more users use the Display Name , 5-digit Suffixes can be appointed. The space is then upgraded to 99999.
The dynamic length offers reasonable flexibility for distinguishing the users who share the same Display Name. However, this could harm the uniformity of the non-customizable part, which is often expected to be uniform.
It is also important to note that Display Name (or Nickname) should be designed as a volatile property. Changing the Display Name should have no side effects. In this practice, the changing of the Display Name usually leads to the changing of the suffix.
In western societies, the space character should generally be allowed to put in the Display Name field, since writing a full legal name can involve spacing. The dot character shares the same statue, since components like "Jr." can appear and the middle name is often abbreviated as a single uppercase letter and a dot character (for example, from "Joseph" to "J."). This creates a dilemma. If the space character is allowed in the Display Name, the BattleTag is scattered like "Donald J. Trump#1234", and this leads to the difficulty in finding the correct left boundary of the BattleTag; if it is not allowed in the Display Name, we will be imposing unreasonable cultural oppression on users with western backgrounds.
For Battle Net and Discord, this is a minor issue since they are not designed to be formal communicating solutions (comparing with LinkedIn), but we at Tessercube would like to achieve some neutrality on this matter and avoid deciding whether formality is welcomed here.
Cat4: QQ Number
A QQ Number is a sequential Base10 integer appointed by the server. The user has no control over its value or length.
This practice ultimately eliminates the slightest possibility of collision, but introduces a great challenge on Memorability, especially for users of languages which has multi-syllable pronunciations for numerals.
Cat5: OpenPGP Public Key Fingerprint (Including Shorter Versions)
An OpenPGP Public Key Fingerprint (Full Fingerprint) is a 40-char hex string (SHA-1). Its shorter versions include the 16-char version (Short Fingerprint) and the 8-char version (Key ID).
The 8-char version is not much collision-free. Collisions sometimes happen, and the user has to be super cautious when using this.
The 16-char version is often collision-free enough, but the user should also be alarmed of faking.
The 40-char version is confidently collision-free.
In this practice, the user has no control over the HFUL, but the allocation does not require a central authority. In different scenarios, different versions can be used; for example, one can search with the Key ID and choose among colliding users by comparing the Full Fingerprint.
Root of Trust
In Tessercube, one requirement is to implement authorityless end-to-end encryption. This requires the sender to know the public key of the recipient. Several ways can lead to this goal. That means, any information of a keypair, including its canonical HFUL, should be either declared by the keypair owner or derived from the public key itself.
In the example of OpenPGP, the canonical HFUL (Fingerprint and its variants) is derived from the public key itself, and one can safely trust a Fingerprint and consider whatever the corresponding public key signs as canonical information from the keypair owner.
In Tessercube, we should ensure that public key is the ultimate internal identifier, while other metadata come from the keypair owner itself (signed declaration or mathematical derivation) and not any server in the middle. Namely, the public key itself (since it is short enough) should be the ultimate identifier.
The Division Between Searching and Confirming
In many existing solutions, the searching and the displaying are decoupled. For example, a user on WeChat can be found by their email address (if enabled), but the email address is not visible for other users when viewing the profile, nor is it used as the primary user-friendly identification method.
This practice is reasonable. Account credentials like email address can be more sensitive than other strings.
As previously discussed in the section for OpenPGP Fingerprint, searching and confirming are different scenarios. Further, the searching can be divided into blurry searching and precise searching.
Blurry Searching
In the example of Twitter, one may search other users by giving a query string and selecting the "People" tab in the results page. This is a blurry match and returns several results. Both the Display Name field and the Username field are included, probably even the Bio field.
Also, some OpenPGP Key Servers offer blurry searching. One may search by Name or Email Address, and the server returns a list of matched public keys.
Precise Searching
In the example of QQ, one may search with a QQ Number to unique locate a user and view their profile page.
Also, some OpenPGP Key Servers offer precise searching. One may search by Full Fingerprint or Short Fingerprint, and the server returns the full public key of the uniquely identified public key.
Confirming
Some OpenPGP Key Servers offer semi-precise searching. One may search by the 8-char Key ID, and the server returns a list of several colliding public key records with their metadata (Name, Email Address, etc) for the visitor to select the actually wanted public key.
In the confirming stage, one may compare the returned information with the remembered information to determine whether a returned result is the desired user profile.
The Dawn of a New Hybrid Solution
The idea of BattleTag and the idea of Fingerprint are excellent and they somehow fit our scenario in Tessercube.
BattleTag is good for searching, and Fingerprint is good for confirming. Further, Key ID is also good for searching.
The KeyTag is the last 8 characters of the Fingerprint (serialized public key). We have a service to make sure that there is no collision. When a keygen is finished, the client asks the server whether another Keypair already occupies the KeyTag. If occupied, the client is encouraged to generate another keypair voluntarily. For searching a user with their KeyTag, the server only returns the earliest result. In future, this can be migrated to a POW-based on-chain solution, like this POC.
Searching
In my proposal, the searching allows the following modes:
The KeyTag serves as a suffix (not necessarily appearing in the same string with the Display Name) as well but can be independently used as a search criteria.
KeyTag
OpenPGP Key ID
The KeyTag has the same length but is unique.
Confirming
The Confirming stage consists of several components.
Fingerprint & KeyTag
The Fingerprint can be viewed directly or indirectly in the user profile page.
The KeyTag is clearly displayed below the Display Name.
SNS Cross Referencing
This practice has been employed by Keybase. Keybase allows the user to associate the Keybase account with SNS profiles, and maintains a list of proofs. Any user can verify if those proofs still exist within their client, and decides individually whether to trust that this Keybase user is the person whom it knows already.
Conclusion
A user may be searched by their Display Name, Display Name Substring, KeyTag, Email Address, and Email Address Username. A user may be uniquely identified by their Fingerprint.
Abstract
Human-Friendly User Identification (HFUID) is a problem commonly encountered in various multi-user communication networks. HFUID consists of several essential requirements, namely: Uniqueness, Memorability, Comparability, Stability, and Embedability.
In this is article, I will discuss existing practices and explore possibilities for our new unique scenario.
Glossary
Classification of Existing Practices
Overview
Existing Practices can be divided into 5 categories, as sorted by Customizability (descending):
As the Customizability decreases, the Stability increases.
Cat1: Bare Username
A user can manually choose a username as long as it is not occupied by another user already. This username is unique to the entire network and has no namespace applied. The collision management requires a central authority to allocate usernames.
Cat2: Namespaced Username
Email addresses are essentially usernames with Namespace. Email is a federated network. Each server is an independent node and manages its own usernames within its namespace where the namespace is its hostname. On a larger scale (Internet), hostnames require a series of hierarchical hostname authorities (TLD) to allocate. Also, in an autonomous network, local TLD consensuses can be reached.
In the Email ecosystem, the TLD NIC does not directly manage each email user. This provides the flexibility and reduces the burden of the central authority of the top-level namespace. However, this practice unnecessarily binds the user to a particular server, and this has been increasingly unfavorable over the recent years, as the right of migrating and synchronizing data across servers has gradually establishes its importance.
Cat3: BattleTag
A BattleTag consists of 2 parts, the Display Name and the Suffix; and they are joined by a "#" character. The Display name is arbitrarily selected by the user, and the Suffix is appointed by the server (4 digits, non-sequential).
This practice allows up to 9999 users to share the same Display Name . When more users use the Display Name , 5-digit Suffixes can be appointed. The space is then upgraded to 99999.
The dynamic length offers reasonable flexibility for distinguishing the users who share the same Display Name. However, this could harm the uniformity of the non-customizable part, which is often expected to be uniform.
It is also important to note that Display Name (or Nickname) should be designed as a volatile property. Changing the Display Name should have no side effects. In this practice, the changing of the Display Name usually leads to the changing of the suffix.
In western societies, the space character should generally be allowed to put in the Display Name field, since writing a full legal name can involve spacing. The dot character shares the same statue, since components like "Jr." can appear and the middle name is often abbreviated as a single uppercase letter and a dot character (for example, from "Joseph" to "J."). This creates a dilemma. If the space character is allowed in the Display Name, the BattleTag is scattered like "Donald J. Trump#1234", and this leads to the difficulty in finding the correct left boundary of the BattleTag; if it is not allowed in the Display Name, we will be imposing unreasonable cultural oppression on users with western backgrounds.
For Battle Net and Discord, this is a minor issue since they are not designed to be formal communicating solutions (comparing with LinkedIn), but we at Tessercube would like to achieve some neutrality on this matter and avoid deciding whether formality is welcomed here.
Cat4: QQ Number
A QQ Number is a sequential Base10 integer appointed by the server. The user has no control over its value or length.
This practice ultimately eliminates the slightest possibility of collision, but introduces a great challenge on Memorability, especially for users of languages which has multi-syllable pronunciations for numerals.
Cat5: OpenPGP Public Key Fingerprint (Including Shorter Versions)
An OpenPGP Public Key Fingerprint (Full Fingerprint) is a 40-char hex string (SHA-1). Its shorter versions include the 16-char version (Short Fingerprint) and the 8-char version (Key ID).
The 8-char version is not much collision-free. Collisions sometimes happen, and the user has to be super cautious when using this.
The 16-char version is often collision-free enough, but the user should also be alarmed of faking.
The 40-char version is confidently collision-free.
In this practice, the user has no control over the HFUL, but the allocation does not require a central authority. In different scenarios, different versions can be used; for example, one can search with the Key ID and choose among colliding users by comparing the Full Fingerprint.
Root of Trust
In Tessercube, one requirement is to implement authorityless end-to-end encryption. This requires the sender to know the public key of the recipient. Several ways can lead to this goal. That means, any information of a keypair, including its canonical HFUL, should be either declared by the keypair owner or derived from the public key itself.
In the example of OpenPGP, the canonical HFUL (Fingerprint and its variants) is derived from the public key itself, and one can safely trust a Fingerprint and consider whatever the corresponding public key signs as canonical information from the keypair owner.
In Tessercube, we should ensure that public key is the ultimate internal identifier, while other metadata come from the keypair owner itself (signed declaration or mathematical derivation) and not any server in the middle. Namely, the public key itself (since it is short enough) should be the ultimate identifier.
The Division Between Searching and Confirming
In many existing solutions, the searching and the displaying are decoupled. For example, a user on WeChat can be found by their email address (if enabled), but the email address is not visible for other users when viewing the profile, nor is it used as the primary user-friendly identification method.
This practice is reasonable. Account credentials like email address can be more sensitive than other strings.
As previously discussed in the section for OpenPGP Fingerprint, searching and confirming are different scenarios. Further, the searching can be divided into blurry searching and precise searching.
Blurry Searching
In the example of Twitter, one may search other users by giving a query string and selecting the "People" tab in the results page. This is a blurry match and returns several results. Both the Display Name field and the Username field are included, probably even the Bio field.
Also, some OpenPGP Key Servers offer blurry searching. One may search by Name or Email Address, and the server returns a list of matched public keys.
Precise Searching
In the example of QQ, one may search with a QQ Number to unique locate a user and view their profile page.
Also, some OpenPGP Key Servers offer precise searching. One may search by Full Fingerprint or Short Fingerprint, and the server returns the full public key of the uniquely identified public key.
Confirming
Some OpenPGP Key Servers offer semi-precise searching. One may search by the 8-char Key ID, and the server returns a list of several colliding public key records with their metadata (Name, Email Address, etc) for the visitor to select the actually wanted public key.
In the confirming stage, one may compare the returned information with the remembered information to determine whether a returned result is the desired user profile.
The Dawn of a New Hybrid Solution
The idea of BattleTag and the idea of Fingerprint are excellent and they somehow fit our scenario in Tessercube.
BattleTag is good for searching, and Fingerprint is good for confirming. Further, Key ID is also good for searching.
The KeyTag is the last 8 characters of the Fingerprint (serialized public key). We have a service to make sure that there is no collision. When a keygen is finished, the client asks the server whether another Keypair already occupies the KeyTag. If occupied, the client is encouraged to generate another keypair voluntarily. For searching a user with their KeyTag, the server only returns the earliest result. In future, this can be migrated to a POW-based on-chain solution, like this POC.
Searching
In my proposal, the searching allows the following modes:
In comparison:
Confirming
The Confirming stage consists of several components.
Fingerprint & KeyTag
The Fingerprint can be viewed directly or indirectly in the user profile page.
The KeyTag is clearly displayed below the Display Name.
SNS Cross Referencing
This practice has been employed by Keybase. Keybase allows the user to associate the Keybase account with SNS profiles, and maintains a list of proofs. Any user can verify if those proofs still exist within their client, and decides individually whether to trust that this Keybase user is the person whom it knows already.
Conclusion
A user may be searched by their Display Name, Display Name Substring, KeyTag, Email Address, and Email Address Username. A user may be uniquely identified by their Fingerprint.