Document Decentralized Namespace Standards and Proposals

[RagnarLifthrasir]

From #1719

[tyjvazum]

I previously made a comment on issue https://github.com/casey/ord/issues/794 that documents some of the behavior of the current naming system for sats.

[RagnarLifthrasir]

I agree with your comment.

[tyjvazum]

I've been working on a decentralized username system on top of ordinals. It'd be nice to get some feedback from anyone interested. These are the high-level features of what I'm implementing.

• Characters can be alphanumeric with underscores, lowercase a through z, 0 through 9, and _ in any combination.

• Length can be 1 through 16 characters, with 6 characters and shorter reserved for a future update, so 7 to 16 characters to start with.

• Usernames must be renewed periodically, likely every 52,500 blocks, which is about 1 year, but perhaps a shorter period initially to discourage speculation and encourage engagement.

• A "sunrise period" where a list of the top ten thousand domains are reserved, with the matching username claimable by publishing some specific data at a well-known location on the domain prior to the end of the sunrise period, which would be some specified block height.

[RagnarLifthrasir]

I like the features. Can you share more about how you'd accomplish these?

[tyjvazum]

Sure, I'm implementing it through a generalized system to handle arbitrary protocols on top of Bitcoin, validating inscriptions with checks specific to the use case, which in this discussion is a decentralized username system, but could be anything.

Inscriptions are used for username registrations, updates (when some associated data should be changed), and renewals. Each requirement from the points in my previous message, as well as others like the username being available or the update being done by the owner, gets checked against each inscription that matches for the username protocol. If an inscription passes the checks then nodes consider it valid and the operation takes effect.

I'm doing the sunrise period using data from Open PageRank that's been filtered down to the essential top ten thousand domains, with subdomains and other unsuitable domains removed from the list.

[stet]

will this be on testnet first?

[RagnarLifthrasir]

I have a good use case for this. @tyjvazum Can you please send me a message on Twitter (@ ragnarlif) or my contact form at ragnarly. com?

[tyjvazum]

will this be on testnet first?

I'm not planning on doing a public testing phase since it's built on top of the inscription functionality, which has already been tested quite a bit, but I'm open to suggestions on that.

[0attack]

i think ideally there should be some data that gets displayed on default block explorers even if it doesn't support the new features.

[tyjvazum]

i think ideally there should be some data that gets displayed on default block explorers even if it doesn't support the new features.

I agree with that and I've been working on it. It won't be able to support any of the new features without modified code, but it'll hopefully be a compelling connection with the existing system. It'd essentially be a generative NFT that gets created along with the username, serving as a collectable, a notification of the registration (although not validated in software unaware of the username protocol), and potentially as a point for further integration with possible future ord features like parent inscriptions.

[RagnarLifthrasir]

Could you create a graphic or visual representation fo the process or schema? I have a small brain.

[tyjvazum]

Hopefully this is visual enough, but it works something like this:

KeyPair > SignedMessage > HashOutput > GenerativeProcess > NFT

KeyPair is the public key and private key associated with the username, SignedMessage is a commitment message signed with the private key (to allow validation by protocol-aware software using the public key), HashOutput could be the SHA-256 or SHA-512 of the SignedMessage, and GenerativeProcess is an algorithm to take the bytes from the hash and produce a deterministic, unique, interesting image, which, along with metadata like the commitment message and public key, is the NFT.

Here are some example generative outputs, sampled randomly, from the work-in-progress algorithm. There are small input size (128 bit/16 byte) and large input size (512 bit/64 byte) versions. I plan on exploring and refining it more moving forward, so feedback from anyone interested would be appreciated.

What's sort of special about it is they're effectively generated from the private key, serving as a visual extension or representation of the public key.

Also, I should note that I omitted lots of implementation details from this explanation, for instance managing key revocations, so additional questions are quite welcome if there are any gaps.

Small Input:

Large Input:

[0attack]

i like it 🚀

it's like a better version of the github icons. what would the difference be for small and large in terms of use cases?

are they all supposed to be vertically symmetrical? i noticed that some of the large ones like the 2nd in the bottom row aren't.

[tyjvazum]

it's like a better version of the github icons. what would the difference be for small and large in terms of use cases?

I'm planning on using the small ones for single usernames and the large ones for group profiles (similar to multisig).

are they all supposed to be vertically symmetrical? i noticed that some of the large ones like the 2nd in the bottom row aren't.

Yes, they all should be vertically symmetrical, nice catch. That's a bug that I'll fix before showing the next iteration of it.

[nammaki]

This sounds awesome and the examples look super pretty 🤩

[tyjvazum]

Here are some examples from the latest iteration, with the symmetry-breaking bug fixed and modified generator logic, which I think results in better looking output.

Sprites (Small Input):

Sigils (Large Input):

[tyjvazum]

@nammaki, thank you for surfacing issue https://github.com/casey/ord/issues/1280. There are two additional sizes, 8 bytes and 32 bytes, that haven't had an appropriate use case. I think 8 bytes works well as an identicon for sats and 32 bytes is a nice fit for identities not associated with a username (while still being derived from a Bitcoin wallet). This non-username option would allow user identities without requiring the cost of making inscriptions, which might help with initial onboarding and could be attached to a username registration later, if the user wants to do that. So 8 bytes for sats, 16 bytes for usernames, 32 bytes for non-username identities, and 64 bytes for group profiles (similar to multisig).

Sprites (Top Half of Image / 16 Bytes) - Sigils (Bottom Half of Image / 64 Bytes)

Stamps (Top Half of Image / 8 Bytes) - Symbols (Bottom Half of Image / 32 Bytes)

[casey]

See https://github.com/casey/ord/issues/794 for the design for a inscription namespace.