add namesapce for Armonia Meta Chain(AMAX)

[Narsiss]

No description provided.

[oed]

Is this blockchain related to EOS in some way? See a bunch of EOS links.

[bumblefudge]

I agree with OED that this PR doesn't really explain its relationship to EOS.io well enough to be helpful to outsiders assessing AMAX support without context, which is a core design goal of a successful namespace.

It would appear that Amax shares with EOS.io an RPC interface and Rust crate for accessing them, and this comment also implies that AMAX should be considered as one network within the broader eos.io namespace despite its custom functionality. The precedent here is Polkadot, where each custom network composes its own runtime from shared or custom Rust crates, but interoperability is guaranteed by namespace-wide interfaces (i.e. XCM).

Perhaps it would make more sense to combine the two PRs ( #64 and #5 ) into an EOS.io namespace that uses AMAX examples in the ### Test Cases sections and has AMAX-specific sections added if CAIP-2 or CAIP-10 operate differently on the AMAX network than they do in EOSIO more generally?

[bumblefudge]

That way, if other custom networks in EOS.io want to add sections, they'll have a much smaller PR to open, and a template/comparison point in yours!

[Narsiss]

AMAX is an EOS homomorphic chain, meaning most of its RPC interfaces are consistent with EOS. To add support for the AMAX network, what do we need to do? Do we need to first assist in adding the EOS namespace?
Some key points:

1. As AMAX is homomorphic to EOS, their RPC interfaces and parameters are mostly the same. This means DApps and tools developed for EOS can also work on AMAX with little modification.
2. However, AMAX is an independent blockchain network separate from EOS. To enable support for AMAX, its own network configuration and parameters need to be added. This includes adding the AMAX network to platforms and specifying nodes, chainID, symbols, etc.
3. Adding the AMAX network can start from the backend, i.e. integrating AMAX nodes and chain data. The frontend modifications come after to display the AMAX network and tokens.
4. Integrating AMAX may not require first launching support for EOS, as they are separate blockchain networks. However, considering they share similar RPC interfaces, adding EOS compatibility can provide references and experiences for supporting AMAX.
5. Full support for AMAX needs to encompass displaying its network status, reading/transferring its native tokens, accessing its dApps and resources, etc. This requires connecting to AMAX nodes for interaction with its chain data and business logic.

Please tell us next steps to add AMAX namespaces

[bumblefudge]

hey sorry for the delay. from what you're telling me, this sounds like amax is one network within the eos namespace using different configurations of the same tooling and frameworks. As such, I think it makes more sense to make an EOS.io namespace with AMAX examples (and, if it's not too much extra work, maybe also examples from main-net EOS.io, or other custom networks on the same RPC/engine). My only request would be that you add an explanation of the EOS.io concept of a "network" to the CAIP-2 entry for this namespace-- i.e., sections describing each of the following (with AMAX examples!):

• displaying the network status of a given network (usually referred to in other CAIP-2s as "resolution mechanics", i.e. getting network status info from a node to confirm you're calling the network you think you are)
• setting/getting native token info (particularly if not included in the status method above)

[bumblefudge]

Hey @Narsiss -- checking back in because since we last chatted an Antelope namespace was added, which might make it easier to provide some context or explanation-by-contradistinction:
https://namespaces.chainagnostic.org/antelope/caip2

Let me know if I can help move this along!