Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CIP-30: Add getNetworkName() Function to API #489

Open
Crypto2099 opened this issue Mar 24, 2023 · 4 comments
Open

CIP-30: Add getNetworkName() Function to API #489

Crypto2099 opened this issue Mar 24, 2023 · 4 comments

Comments

@Crypto2099
Copy link
Collaborator

Crypto2099 commented Mar 24, 2023

CIP-30 was originally written and implemented during the time of a singular testnet and mainnet.

With the new era of multiple testnets and a cross-chain future on the horizon, I propose that we introduce a new function in order to maintain backwards compatibility with existing implementations while providing for a more robust and feature-rich future.

Enter the getNetworkName() function.

api.getNetworkName(): Promise<string>
Errors: APIError

Returns a string identifier of the network of the wallet. "preprod" is Pre-Production Testnet, "preview" is Preview Testnet, "cardano" is Cardano Mainnet.

In this way, future test networks and/or side chain networks (i.e. Midnight, Shareslake, etc) can be determined by application developers without breaking backwards compatibility with existing solutions relying on the binary true/false returned by getNetworkId().

@rphair
Copy link
Collaborator

rphair commented Mar 24, 2023

cc @Ryun1 - also looks related to pending CIP-0030 update #323

@Crypto2099
Copy link
Collaborator Author

Just noticed that and left a comment there as well, thanks!

@latheesan-k
Copy link

Yes, there's no optimisation to be had by returning a numeric identifier, why not just be literal and say the currently connected network's name

@Ryun1
Copy link
Collaborator

Ryun1 commented Mar 24, 2023

This seems to be a long standing issue, with both #323 and #209 seeking to amend it.

Instead of altering CIP-30 more, I would suggest we use the extendibility mechanism present. Perhaps this end point could be bundled with other CIP-30 additions, such as #443 and/or maybe #206? - to form a CIP-30 extension.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants