Add sui namespace and CAIP-2 spec

[williamrobertson13]

This PR adds documentation for the Sui smart contract platform and a corresponding CAIP-2 specification which will unlock cross-chain integrations with Sui. The design here is largely inspired by a discussion we had a few years ago in MystenLabs/sui#6624 and will supersede #43.

For easier viewing pleasure:
https://github.com/ChainAgnostic/namespaces/blob/fe4627761af1d6b192994791ea0bba45049f02d5/sui/README.md
https://github.com/ChainAgnostic/namespaces/blob/fe4627761af1d6b192994791ea0bba45049f02d5/sui/caip2.md

[obstropolos]

Approving in this case - curious though how this would apply to a different sui network and how it would be formatted both with the prefix and namespace identifier. Some additional clarity here would be great.

[williamrobertson13]

Approving in this case - curious though how this would apply to a different sui network and how it would be formatted both with the prefix and namespace identifier. Some additional clarity here would be great.

Hey @obstropolos! Thanks for the review - LMK if there was anything unclear from the specification in the PR. There are only four canonical networks on Sui - mainnet, testnet, devnet, and localnet (localnet is excluded from the spec since that identifier encompasses locally ran network instances). The motivating factor for using static identifiers, i.e. sui:devnet and sui:testnet, is that developers expect to interact with the "devnet" network that is live and don't particularly care about which chain ID they're interacting with

[obstropolos]

Hey @obstropolos! Thanks for the review - LMK if there was anything unclear from the specification in the PR. There are only four canonical networks on Sui - mainnet, testnet, devnet, and localnet (localnet is excluded from the spec since that identifier encompasses locally ran network instances). The motivating factor for using static identifiers, i.e. sui:devnet and sui:testnet, is that developers expect to interact with the "devnet" network that is live and don't particularly care about which chain ID they're interacting with

Ah got it! This makes a lot more sense - I didn't know if there would be any additional derivative networks besides the core canonical ones that would require this. Appreciate the color here.

[bumblefudge]

@williamrobertson13 sorry i'm still not understanding what you mean by "canonical". The docs make it sound like any chainId that you can get the domain controller of sui.ui to point to a fullnode at fullnode.{chainId}.sui.io is equally valid, and has its own distinct state (thus the caveats of two of them periodically losing state). so I guess the questions that we traditionally ask of CAIP-2 profile authors to answer with their submissions are:

1. what is the mechanism for a fifth chainId becoming canonical?
2. how can people use non-canonical/private ones?
3. what constraints (ideally expressable as a regular expression) are there on valid chainIds? in this case, is any valid subdomain a valid chainId for a private/non-canonical network?

[williamrobertson13]

@williamrobertson13 sorry i'm still not understanding what you mean by "canonical". The docs make it sound like any chainId that you can get the domain controller of sui.ui to point to a fullnode at fullnode.{chainId}.sui.io is equally valid, and has its own distinct state (thus the caveats of two of them periodically losing state). so I guess the questions that we traditionally ask of CAIP-2 profile authors to answer with their submissions are:

1. what is the mechanism for a fifth chainId becoming canonical?
2. how can people use non-canonical/private ones?
3. what constraints (ideally expressable as a regular expression) are there on valid chainIds? in this case, is any valid subdomain a valid chainId for a private/non-canonical network?

Hello! Ah I realize now that saying "canonical" was incorrect terminology in my previous message 😅. Let me rephrase that and say there are four commonly recognized networks that run today that are supported by dApps.

(https://docs.sui.io/guides/developer/getting-started/connect) make it sound like any chainId that you can get the domain controller of sui.ui to point to a fullnode at fullnode.{chainId}.sui.io is equally valid, and has its own distinct state (thus the caveats of two of them periodically losing state). so I guess the questions that we traditionally ask of CAIP-2 profile authors to answer with their submissions are:

Just to clarify on this point, the documentation states that https://fullnode.<SUI-NETWORK-VERSION>.sui.io:443 is a public-good fullnode URL where <SUI-NETWORK-VERSION> is conveniently mainnet|devnet|testnet and not an underlying chain identifier in the form of a checkpoint digest. For example, https://fullnode.mainnet.sui.io/health exists whereas https://fullnode.35834a8a.sui.io/health does not.

To hit on your questions:

1. Going back to my terminology change from canonical -> commonly recognized network - if a public, long-running network popped up on Sui then we would recognize that network and add it to the CAIP-2 specification here.
2. Private networks should be supported by localnet which should actually be added to the specification now that I think about it. sui:localnet identifies networks that are ran locally on a machine and are inherently private.
3. Subdomains aren't related to the CAIP-2 chain IDs outlined in the spec. The identifiers chosen for the spec are picked for readability and developer simplicity. At this moment, ^sui:(mainnet|testnet|devnet|localnet)$ would be the full set of expressible CAIP-2 chain IDs.

[bumblefudge]

ok neat thanks I will open a PR to add this additional stuff when I have some time but this is fine to publish as a first draft

[bumblefudge]

So the Sui Foundation decides this, and announces this? Is there a canonical mapping anywhere? most CAIP-2 profiles define the underlying machine-readable (and immutable) identifier, since this creates CAIP-10s and CAIP-19s that survive changes at the governance/human level...

[bumblefudge]

Good enough to publish as a draft since clearly the indirections are maintained by the foundation but i'd like to add localnet in a follow-in PR and add some more precise explanation of how these indirections are governed.

I also don't see a good technical reason for only allowing mutable/unsafe indirections; couldn't
sui:4c78adac
and
sui:testnet

coexist? don't some usecases need the former and some usecases need the latter?