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

CIP30: experimental api section #183

Merged
merged 3 commits into from
Feb 7, 2022
Merged

Conversation

SebastienGllmt
Copy link
Contributor

@SebastienGllmt SebastienGllmt commented Dec 28, 2021

Problem

  1. Many wallets have started defining their own functions that aren't part of CIP30. It makes it hard for dApp devs to know which functions are standardized (supported by all wallets) and which are wallet-specific
  2. We currently have no clear process for updating the CIP30 api version

Adding an "Experimental API" section to CIP30 aims to solve these issues.

Experimental API

Functions in this section must be under the experimental namespace (ex: api.experimental.myFunctionality).

The benefits of this are:

  1. Wallets can add non-standardized features while still following the CIP30 structure
  2. dApp developers can use these functions explicitly knowing they are experimental (not stable or standardized)
  3. New features can be added to CIP30 as experimental features and only moved to non-experimental once multiple wallets implement it
  4. It provides a clear path to updating the CIP version number (when functions move from experimental -> stable)

@SebastienGllmt SebastienGllmt self-assigned this Dec 28, 2021
@alessandrokonrad
Copy link
Contributor

That is a great idea. Then I can finally move Nami to CIP-0030, while still supporting some of the custom endpoints and event functions.

@crptmppt crptmppt added Minor change Update Adds content or significantly reworks an existing proposal labels Jan 5, 2022
@MarcelKlammer
Copy link

Just to clarify, that would be?:

const fullApi = await window.cardano.walletName.enable() // walletName: eg. nami or ccvault

await fullApi.experimental.functionName()

@SebastienGllmt
Copy link
Contributor Author

@MarcelKlammer yes, that's correct

@MarcelKlammer
Copy link

Today I had a feature request of a nft marketplace for an appVersion property, which can be read ahead of calling enable().

So I put it here:

window.cardano.ccvault.experimental.appVersion = { major: 1, minor 3, patch: 9 }

So we could also add such an object in the wallet namespace.

@SebastienGllmt
Copy link
Contributor Author

Just an FYI, Nami, ccvault and Flint now all use this experimental field so I think probably this should be merged

In general probably we need a modification to CIP30 to define when we can merge these though

Copy link
Contributor

@rooooooooob rooooooooob left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Collaborator

@rphair rphair left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although I don't understand every detail of this spec, the additions look understandable, useful & well precedented to me.

@vsubhuman
Copy link
Contributor

Note, Yoroi is updating to utilise this as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Update Adds content or significantly reworks an existing proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants