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.

Sign up for GitHub

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-0030 | Encourage namespaced extension endpoints #577

Merged
merged 8 commits into from
Sep 19, 2023
Merged

CIP-0030 | Encourage namespaced extension endpoints #577

Changes from 2 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
717b05a
stipulate namespaced extensions
Aug 4, 2023
3a913c9
chose better number example
Aug 7, 2023
bc52762
Added removing leading zeros
Aug 7, 2023
a4af1f3
made namspacing partially optional
Aug 17, 2023
ba02ab5
added that authors have to justify
Aug 18, 2023
2d7d6b6
address draft extensions
Sep 4, 2023
81e1ba3
remove over perscriptive draft extension protocol
Sep 10, 2023
f17bfab
small stipulation added
Sep 10, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions CIP-0030/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -200,6 +200,13 @@ Upon start, dApp can explicitly request a list of additional functionalities the

DApps are expected to use this endpoint to perform an initial handshake and ensure that the wallet supports all their required functionalities. Note that it's possible for two extensions to be mutually incompatible (because they provide two conflicting features). While we may try to avoid this as much as possible while designing CIPs, it is also the responsability of wallet providers to assess whether they can support a given combination of extensions, or not. Hence wallets aren't expected to fail should they not recognize or not support a particular combination of extensions. Instead, they should decide what they enable and reflect their choice in the `cardano.{walletName}.extensions` field of the Full API. As a result, dApps may fail and inform their users or may use a different, less-efficient, strategy to cope with a lack of functionality.

Extension's endpoints should be namespaced by `.cipXXXX.` with the returned `API` object. For example; CIP-1234's endpoints should be accessed by:

```ts
api.cip1234.endpoint1()
api.cip1234.endpoint2()
```

Ryun1 marked this conversation as resolved.
Show resolved Hide resolved
##### Can extensions depend on other extensions?

Yes. Extensions may have other extensions as pre-requisite. Some newer extensions may also invalidate functionality introduced by earlier extensions. There's no particular rule or constraints in that regards. Extensions are specified as CIP, and will define what it entails to enable them.
Expand Down Expand Up @@ -368,6 +375,10 @@ Extensions can be seen as a smart versioning scheme. Except that, instead of bei
2. Not everyone agrees and has desired to support every existing standard;
3. There's a need from an API consumer standpoint to clearly identify what features are supported by providers.

#### Namespacing Extension
Copy link

@mirceahasegan mirceahasegan Aug 7, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

For me, it is unclear how a DApp will use these namespaced methods.
Let's take signTx usage as an example:

  1. DApp enables cip-95 and cip-1234.
  2. Builds a transaction with Conway fields (e.g. registers a DRep certificate) + cip-1234-specific-stuff

Which signTx will the DApp use?

  1. cip95.signTx(tx, partialSign=true) + cip1234.signTx(tx, partialSign=true)
  2. Split it into 2 transactions and sign them separately?
  3. Will all namespaced signTx extend the cip30 base sign?

Copy link
Collaborator Author

@Ryun1 Ryun1 Aug 7, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

This is a good question! and I think the answer would depend on how CIP-1234 defines it's signTx.

For me, I think it is best that extensions completely replace other extensions capabilities rather than dApps needing two extensions to do the same thing; such as signing transactions. So my preferred approach would be for CIP-1234 to be supporting all of the CIP-95 capabilities and it's own at once. This would prevent the need for dApps to support two extensions for the same purpose.

I also don't see this as a massive issue, as I don't see there being a massive emergence of conflicting extensions.

With that said, CIP-30 as it stands today would does allow for such awkward overlaps of capabilities between extensions and it is up to wallets to reconcile their capabilities, at enable time.


By explicitly namespacing each enabled extension we aim to improve the usability of extensions for dApps. This prevents possible polymorphism of extension endpoints, which should also improve complexity of wallet implementations.

## Path to Active

### Acceptance Criteria
Expand Down