CIP-0090? | Extendable dApp-Wallet Web Bridge #462
Conversation
CIP-XXXX/CIP-XXXX.md
Outdated
|
|
||
| Extensions provide an extensibility mechanism and a way to negotiate (possibly conflicting) functionality between a dApp and a wallet provider. There's rules enforced as for what extensions a wallet decide to support or enable. The current mechanism only gives a way for wallets to communicate their choice back to a dApp. | ||
|
|
||
| We use object as extensions for now to leave room for adding fields in the future without breaking all existing interfaces. At this point in time however, objects are expected to be singleton. |
There was a problem hiding this comment.
Don't quite understand what 'singleton' means in this context (or what is the 'object'). Would be nice to elaborate.
There was a problem hiding this comment.
This means that extension objects cannot pass additional fields at enable time, currently.
There was a problem hiding this comment.
Do we need to limit this in this text? Isn't it enough to say that this CIP only defines a single key in the object passed, and that it's up to Extensions to define additional fields in their respective CIP, if any?
There was a problem hiding this comment.
This means that extension objects cannot pass additional fields at enable time, currently
Thanks. Could be just me not understanding it from text, but consider rewording it @Ryun1
Do we need to limit this in this text? Isn't it enough to say that this CIP only defines a single key in the object passed, and that it's up to Extensions to define additional fields in their respective CIP, if any?
The simpler the base dApp connector cip the better imho. The scope of the extension CIPs can then be contained to just the API object that enable() returns. The extensions can have API methods (or arguments for those methods) instead. If we allow configuration at enable() time then we can expect to see extension designs that would require the dApp calling enable multiple times with different arguments. Do we want that? 😅
There was a problem hiding this comment.
Do we want that?
You raise a good point, I think this could become messy quickly.
And I have removed this sentence to avoid the confusing wording.
Ryun1
changed the title
There was a problem hiding this comment.
Love it. Thanks for the pushing this @Ryun1.
Any thoughts @Quantumplation ?
CIP-XXXX/README.md
Outdated
|
|
||
| In order to initiate communication from webpages to a user's Cardano wallet, the wallet must provide the following javascript API to the webpage. A shared, namespaced `cardano` object must be injected into the page if it did not exist already. Each wallet implementing this standard must then create a field in this object with a name unique to each wallet containing a `wallet` object with the following methods. The API is split into two stages to maintain the user's privacy, as the user will have to consent to `cardano.{walletName}.enable()` in order for the dApp to read any information pertaining to the user's wallet with `{walletName}` corresponding to the wallet's namespaced name of its choice. | ||
|
|
||
| #### cardano.{walletName}.enable(extensions: Extension[] = [{ cip: 30 }]): Promise\<API> |
There was a problem hiding this comment.
Same comment about structural vs positionsl as I left on the other CIP30 PR
There was a problem hiding this comment.
Given this is defined in CIP-30 and is already implemented by wallets, this is asking for trouble on a backwards compatibility front.
It would be simpler if the wallets just enable ALL extensions they are aware of.
Alternatively, there could be:
cardano.{wallet}.reqExtensions(extensions: Extension[])
This could pre-informs the wallet what extensions the dapp wants to use. The enable then just enables those. The default if its not called should be enable all extensions the wallet supports. However, in this case, I think its informative only (maybe the wallet can use it to display something meaningful to the user?). The wallet should enable all the extensions that it supports, which were requested. If an extension was requested but the wallet does not support it, that should not be an error.
To be clear, even though this reqExtension function could be added, I don't think it's necessary.
CIP-XXXX/README.md
Outdated
|
|
||
| A list of extensions supported by the wallet. Extensions may be requested by dApps on initialization. Dapps can repeatably call `wallet.enable()` to add further extensions. Some extensions may be mutually conflicting, and this list does not thereby reflect what extensions will be enabled by the wallet. Yet it informs on what extensions are known and can be requested by dApps if needed. | ||
|
|
||
| `undefined` is equivalent to `{cip: 30}`. |
There was a problem hiding this comment.
I think this is redundant.
I do not see much utility in fine grain switching of extensions.
If the process was just:
cardano.{walletName}.enable();
extensions = cardano.{walletName}.isEnabled();
That tells you everything you need as a dApp.
- Does this wallet support this cip, or is it just obeying cip-30.
- What extensions does the wallet support.
- All supported extensions are enabled.
There was a problem hiding this comment.
I do agree with this, I think I will do a revision of this proposal.
CIP-XXXX/README.md
Outdated
|
|
||
| Errors: `ConnectorError` | ||
|
|
||
| Returns a list of extensions which have been enabled by the wallet. If no wallet access has been granted then a `ConnectorError` with `Refused` error code should be thrown. |
There was a problem hiding this comment.
Again from a backward compatibility viewpoint, this should be allowed to return either a bool or a list of enabled extensions. a bool set to true is equivalent to CIP-30, and should mean "This wallet does not support this CIP".
Even though a wallet that implements this CIP should not return a bool, its a valid response from a CIP-30 wallet and it should be clear how a dapp reacts to it.
There was a problem hiding this comment.
I agree with this also, I think I had not considered backward compatibility enough... I plan to do a more significant rewrite when/if #486 is merged.
KtorZ
changed the title
|
I plan to do a significant rewrite once there is more community consensus around #486. |
Ryun1
added
the
State: Waiting for Author
Co-authored-by: Martynas <martynas@firmfirm.co>
Co-authored-by: Martynas <martynas@firmfirm.co>
Co-authored-by: Martynas <martynas@firmfirm.co>
Co-authored-by: Martynas <martynas@firmfirm.co>
Co-authored-by: Martynas <martynas@firmfirm.co>
Co-authored-by: Martynas <martynas@firmfirm.co>
Co-authored-by: Matthias Benkort <5680256+KtorZ@users.noreply.github.com>
Co-authored-by: Matthias Benkort <5680256+KtorZ@users.noreply.github.com>
Ryun1
force-pushed
the
extendable-dapp-connector
branch
from
2940783
to
6ff143d
Compare
Ryun1
removed
the
State: Waiting for Author
|
@Ryun1 since this still has not moved forward (and I am not rushing you) I'm reapplying the |
rphair
added
the
State: Waiting for Author
|
Leave me to it I think I will fix up this proposal explaining drawbacks, get it merged |
|
@Ryun1 how would the new proposal differ? |
This document describes a base web-wallet communication bridge accompanied by a scheme from which functionality can be added through API extensions.
This specification defines a wallet-dApp connection standard using injected Javascript object, with an extendable API interface.
This aims to allow the creation of dApp connectors without the need to include the CIP-30 API as proposed in #446.
Instead the CIP-30 API can act as an optional extension to this specification.
This draws direct inspiration from @mkazlauskas' comment, utilizing @KtorZ's design from #446. Thus the author accreditations.
Todo
(rendered proposal in branch)