Mina: Add namespace / CAIP-2

[halsaphi]

This is the initial namespace specification / CAIP-2 for the Mina Protocol. The Mina Protocol is a L1 built from the ground up to use zero-knowledge proofs.

[halsaphi]

hi @bumblefudge is there anything else I need to do / add etc for this to be reviewed?

[bumblefudge]

hi @bumblefudge is there anything else I need to do / add etc for this to be reviewed?

Apologies, the queue has been a little backed up with travel and conferences! This looks fine except the nits mentioned above, can I get an independent review from a tooling company or experience Mina dev just in case I'm missing something out of ignorance?

Also, I noticed the Rosetta link in the references-- this is a cool open-source standards-support feature to highlight for cross-chain dapps and exchanges. One way of doing this would be to add that line to the references from the readme.md as well. Another would be to go ahead and write an CAIP-27 profile that gives dapps/exchanges all they need to send graphQL or rosetta queries to nodes, how to address/find archival nodes, etc. through walletConnect or other transport networks. Not blocking this PR or anything, just a suggestion if you want to get more crosschain interest organically through developer documentation :D

[halsaphi]

@bumblefudge - thanks for the review! - will make some updates and come back to you ;D

[halsaphi]

hi @bumblefudge - can this be merged? Or do I need to add more?

[bumblefudge]

hey sorry to do this to you but i dug into the docs again and noticed that the RPCs actually use a machine-readable hash to identify networks-- which is what i was asking about before, why invent a human-readable mapping that isn't canonically published anywhere? https://docs.minaprotocol.com/exchange-operators/faq#why-am-i-getting-this-error-message-not-able-to-connect-to-the-network

[bumblefudge]

in other words, if "mainnet" is actually 5f704cc0c82e0ed70e873f0893d7e06f148524e3f0bdae2afb02e7819a0c24d1 why not just cut that down to the first 4 or 8 characters like most other CAIP-2 profiles? I keep thinking this human-readable indirection is a weak link/maintenance obligation and won't age well if people spin up their own private networks or testnets, i'm really leaning towards just doing a one-way transform (e.g. substr) of the canonical hash rather than adding the human-readable alias at the protocol level...

[halsaphi]

hi @bumblefudge, sorry missed this ;) This was discussed internally and the product team were keen to have a human readable name so the graphQL was extended to support this. Do you think we need to reappraise this or can we push forward with the proposal?

[bumblefudge]

interesting-- if human-readable is how the chainId system is actually working in the community's code "in the wild", then sure, the CASA scheme should reflect that. But my main concern is keeping CASA's docs maximally "downstream" of more canonical ones with lots of mina-community eyes on them and thus maximally low-maintenance. do you have a link to somewhere in the maintained docs about this mapping? When I google around, all I see are references to codename in the dockerized node setups, but what i'm looking for is the authoritative mapping in official docs or offical repos-- the CASA docs are NOT the place to define this archivally!

[ukstv]

@halsaphi The next CASA call is on 14th of December. I guess, it makes sense for you to join there, so that we could have a chance to go through that change in a synchronous fashion, if @bumblefudge does not mind. Disclaimer: I like what Mina is doing.

[bumblefudge]

hey im not blocking the design I just want the upstream docs updated so I can link to them and know theyll be updated there when future mappings get added! attending an editorial meeting isn't a requirement but always welcome

[ukstv]

"I just want the upstream docs updated so I can link to them" - yeah, I understand, and fully support the concern. Mina should have some sort of "Improvement Proposals" or RFC standardisation process on their own to specify available network names.

[bumblefudge]

if there isn't a page in the Mina docs and getting one added is out of your hands, just put in a comment like, "at time of writing the current recognized values are the ones listed above and no canonical human-readable or machine-readable mapping has yet been published. In future, the Mina official docs will link to such a mapping once one is published."

[halsaphi]

hi @bumblefudge - sorry been busy at some events in Taipei - I'll add your comment to the spec and work on getting the mina docs updated ... once the docs contain the canonical mappings I'll update with a link to the docs.

[halsaphi]

There is a update to the docs coming in Jan/Feb - will have the canonical mappings in that update and will then update the files here with links.

[halsaphi]

@bumblefudge @ukstv - I have added a link to some updated documentation showing the network identifiers and how to resolve the network identifier.

Can this be merged now? Is there anything I need to do for this?

Thanks

[halsaphi]

@bumblefudge and @ukstv - please note there is a planned upgrade to the Mina Networks (adding zkApps) - and that post this upgrade the documentation linked to above will move to https://docs.minaprotocol.com/ - I will update the link to reflect this post upgrade.

[ukstv]

@bumblefudge This looks okay by me. What do you think?

[halsaphi]

hi @bumblefudge and @ukstv - how do I get the second approving review?

[ukstv]

@halsaphi I guess, the next step is to wait till the next CASA call. Usually, we merge PRs like this during our meeting. AFAIK, it is on April the 4th.

[bumblefudge]

@halsaphi I guess, the next step is to wait till the next CASA call. Usually, we merge PRs like this during our meeting. AFAIK, it is on April the 4th.

actually, you could be reviewer #2 today, @ukstv , and thus take one PR off the queue for the ~4Apr~21Mar meeting! :D

[halsaphi]

hi @bumblefudge and @ukstv thanks for all your help and patience with this ! :)