Discussion: User handles on DSNP

[p5150j]

Spike user handles on DSNP technical implementation options

Per meetings see Suggested Approach idea phase doc

We would like to get options to know the boundaries for user handles prefix and suffix implementation.

Things to think about:

• User chosen prefix
• User chosen suffix
• What3words style ///slurs.this.shark
• Think about non US centric characters

@wilwade @wesbiggs @pfrank13 please add more context as you see fit

The artifact of this spike should be a loose design doc on optionality and pros and cons of each implementation idea to share with the larger group of stakeholders.

Starting guidelines:

• User handles can contain most valid unicode characters. We limit some zero-width and non-rendering characters.
• User handles must be between 2 and 32 characters long.
• The following restrictions are additionally enforced for usernames: User handles cannot contain the following substrings: @, #, :, ```
• Suffixes are 4 digits by default
• Suffix should be auto assigned
• User handle without suffix are available if name is not taken.
• User handles in the following alphabets/Unicode scripts: English basic, Latin, Latin extended, Latin extended-A, Hangul, Katakana, Hiragana, CJK Symbols (Chinese, Japanese, Korean), Bengali, Devanagari, Cyrillic, Greek, and Thai. These alphabets represent over 200 languages worldwide.

[p5150j]

We have an algorithm that works with Wil's requirements above. For the first 500 million users or so, it will generate sixteen options for a 33-bit "suffix". 33 was chosen because it maps directly to 3 words from BIP39, but we could also represent the suffix in other encodings. As an example, here are some options for suffixes if I am dsnp://59918 and want my handle to be "wesbiggs":

  wesbiggs.number-immune-actress
    wesbiggs.charge-outer-badge
    wesbiggs.detect-heart-coach
    wesbiggs.team-sunset-direct
    wesbiggs.honey-smart-drip
    wesbiggs.lamp-auction-fluid
    wesbiggs.sweet-interest-gather
    wesbiggs.essence-advance-infant

Different encodings of one of these are all equivalent, and as long as we knew what we were dealing with, could be used according to circumstance, for example, these all locate the same DSNP User Id:

BIP39     wesbiggs.sweet-interest-gather
Base36    wesbiggs.1hih2vx
Hex       wesbiggs.c0dd6edd
Decimal   wesbiggs.3235737309

Base36 is obviously the most concise but not particularly easy to get a friend to remember. BIP39 seems best for sharing verbally. Decimal is included because that's a lot of the examples we've been talking about, but as you can see from that example it's going to be 10 digits or so on average.

[wesbiggs]

Thanks for posting that Patrick.

For reference, POC code is here: https://github.com/Liberty30/architecture-pocs/tree/main/handles Implementation: https://github.com/Liberty30/architecture-pocs/blob/main/handles/lib/src/main/java/org/dsnp/handles/HandleHelper.java Test/Example: https://github.com/Liberty30/architecture-pocs/blob/main/handles/lib/src/test/java/org/dsnp/handles/HandlesTest.java

[wesbiggs]

Hi all, various apples have hit us on the collective head over the last few days, and we have an option to enable much shorter suffixes (or possibly no suffix at all). Instead of requiring handle + suffix to hash to a specific, sequentially assigned MSA, we can enable non-sequential assignment of MSAs within a predetermined namespace (for now, we are thinking up to 2^32, which is enough for over 4 billion users). Any handle + any suffix will be hashed to one of those 2^32 MSAs. For the most part, this can work exactly like users are used to with a Web2 solution.

Basic rules:

1. Users pick their handle (syntax based on some agreed convention — I suggest lowercase + numerals and maybe hyphen or underscore; international usernames can reduce to these using Punycode).
2. Users pick, or are assigned, a numeric suffix. Technically this could range from 0 to 2^32; we may want to constrain it so it’s always a minimum of 3 or 4 digits, or not.
3. Using the first 32 bits of the Blake2b hash of handle + suffix_bytes, we form an MSA and check if it is already in use. If so, we try a different suffix (perhaps by incrementing the suffix value by one until we find an available one). We can use indexing services to aid in this process, though they won’t be completely authoritative.
4. We request creation of the specific MSA on chain (Frequency doesn’t know what handle/suffix are in use directly).
5. We wait for the block to form to ensure that the transaction processed successfully and the MSA was created. If we get an error, we’ll have to retry with a new suffix (unlikely but possible race condition).
6. We announce our shiny new DSNP identity and tell the world our handle and suffix in a Profile Announcement.

There are a few product/business decisions that we would want to make with this scheme:

• Do we want to allow no suffix at all? This is possible with this design (technically, do we allow “the null/empty suffix”). However, it does open up possibilities for name squatting that would require some governance strategy to address. (For example, I could claim the MSA for cocacola and the eponymous corporation may not be well pleased; if they obtain a court order for Frequency to vacate the ID, how is this handled?)
• If we allow suffix choice, do we blocklist certain numeric suffixes? For example, we could require that suffixes be at least 3 decimal digits, or we could blocklist (again, perhaps by governance) hate symbols like 1488.

[p5150j]

Thanks @wesbiggs, I think we'd like to get to a good place with product and eng teams by Wednesday the 1st EOD. Ill look at stakeholder (braxton, kenne, @wilwade and scott )calendars and see if we can get something on the books and close out the spike at that point.

[aramikm]

Using the first 32 bits of the Blake2b hash of handle + suffix_bytes, we form an MSA and check if it is already in use. If so, we try a different suffix (perhaps by incrementing the suffix value by one until we find an available one). We can use indexing services to aid in this process, though they won’t be completely authoritative.

This would mean that Msa ids won't be incremental. There might be consequences for this change in msa pallet and other places that we need to verify. Other consequence might be in compression assumptions.

[wesbiggs]

We're now treating the suffixing and hashing semantics as Frequency-specific. However, we may need to specify handles from a DSNP point of view.

This could involve the following:

• Definition and syntax of handles
• Uniqueness constraints on handles
• Operation and State Change Record for handle commitment
• Discussion of effect of User Id Retirement on handles
• Referencing handles from ActivityContent
• Discussion of effect of changing handles

[wesbiggs]

Generalization - chain-specific handles are one alternative means of addressing/representing a DSNP User Id, there could be others (URI, ...)

[wilwade]

DSNP Community Call Notes (2023-05-25)

Outcomes

• Not required until a second DSNP System is being considered
• Prefixing DSNP handles would help with scope issues.

Options

1. DSNP has no handle representation and left to DSNP Systems (Current)
2. DSNP has specific rules and requirements around handles
3. DSNP has non-normative recommendations for DSNP systems and handles

What must a DSNP handle do?

If you implement a handle inside of your DSNP System, it must always...

• Resolve the same DSNP Id as other DSNP Systems

Notes

• If DSNP wanted to later bring handles into the spec, a per DSNP System prefix would be required
• It is hard to go from unrestricted to restricted/recommendation (argument for at least a non-normative recommendation)
• If we add prefixes (at the DSNP level) then it helps resolve the issue