[NameService - Do not merge yet] Adds support to more input formats

[manolisliolios]

Description

Adds support to different input formats when constructing a Domain.

Now, we can resolve names with multiple separators ['@', '.', '*'] (part of upcoming changes), and by skipping the TLD (defaults tosui).

@test -> test.sui test -> test.sui test.sui -> test.sui test@sui -> test.sui test@test -> test.test.sui .. and so on

Test Plan

Added a new test file (We didn't have one for the name service). Not sure if this is the right way to test stuff on our crates, so please advise me here if it's not right.

---

If your changes are not user-facing and not a breaking change, you can skip the following section. Otherwise, please indicate what changed, and then add to the Release Notes section as highlighted during the release process.

Type of Change (Check all that apply)

• [ ] protocol change
• [ ] user-visible impact
• [ ] breaking change for a client SDKs
• [ ] breaking change for FNs (FN binary must upgrade)
• [ ] breaking change for validators or node operators (must upgrade binaries)
• [ ] breaking change for on-chain data layout
• [ ] necessitate either a data wipe or data migration

Release notes

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
explorer	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 15, 2024 2:04pm
multisig-toolkit	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 15, 2024 2:04pm
mysten-ui	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 15, 2024 2:04pm
sui-core	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 15, 2024 2:04pm
sui-kiosk	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 15, 2024 2:04pm
sui-typescript-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 15, 2024 2:04pm

[stefan-mysten]

@manolisliolios I probably lack a lot of context, but curious why test.test.sui would be accepted: isn't that. a subdomain of test.sui? And if yes, how does it work if somebody else owns test.sui? I assume that should fail, and in my mind, you could only get test.test.sui if you already have test.sui. What am I missing here?

[manolisliolios]

@manolisliolios I probably lack a lot of context, but curious why test.test.sui would be accepted: isn't that. a subdomain of test.sui? And if yes, how does it work if somebody else owns test.sui? I assume that should fail, and in my mind, you could only get test.test.sui if you already have test.sui. What am I missing here?

It is indeed a subdomain, and subdomains will also be resolvable on the name service. You will be able to have a stefan.manos.sui (for example) subdomain assigned to you, resolving to your address. Returning results or not here fully relies on the on-chain registry.

[wlmyng]

@manolisliolios I probably lack a lot of context, but curious why test.test.sui would be accepted: isn't that. a subdomain of test.sui? And if yes, how does it work if somebody else owns test.sui? I assume that should fail, and in my mind, you could only get test.test.sui if you already have test.sui. What am I missing here?

It doesn't really matter if someone else owns test.sui. Not sure if this is the best analogy but you can look up the dynamic fields of an object even if you don't own the object.

Today there is some struct that contains a registry and reverse registry: Data { registry: Table<Domain, NameRecord>, reverse_registry: Table<address, Domain> }

Of particular interest is the NameRecord, with shape: NameRecord { target_address: address, metadata: VecMap<String, String>, expiration_timestamp_ms: u64 nft_id: ID of the SuinsRegistrationNFT that gives capability to set target_address }

"Ownership" of a domain is really ownership over the SuinsRegistrationNFT which grants capabilities to the address holding that NFT. The capabilities include setting the target_address of the NameRecord for the domain, which enables address -> domain and domain -> nameRecord lookups

So in the world with subdomains, it's totally possible for addressA to own the NFT to both test.sui and test.test.sui, set the target address of test.sui to addressB, and test.test.sui to addressC. Imagine addressA to be Google domains, addressB to be a subdomain provider, and addressC to be a pleb who bought a subdomain

[bmwill]

I don't have the full context here but this example is sort of confusing to me:

test@sui -> test.sui
test@test -> test.test.sui

[manolisliolios]

I don't have the full context here but this example is sort of confusing to me:

test@sui -> test.sui
test@test -> test.test.sui

Yeah, that was a mini disconnection from what we actually want to do. Initially, we considered omitting TLDs, but that won't work after all so I've removed it completely.

The new approach is described on the PR description.