-
Notifications
You must be signed in to change notification settings - Fork 318
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
Conversation
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. |
Just to clarify, that would be?:
|
@MarcelKlammer yes, that's correct |
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:
So we could also add such an object in the wallet namespace. |
Just an FYI, Nami, ccvault and Flint now all use this In general probably we need a modification to CIP30 to define when we can merge these though |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this 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.
Note, Yoroi is updating to utilise this as well |
Problem
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: