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

SIP-27: Accounts Metadata Request #148

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

SIP-27: Accounts Metadata Request #148

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
3a8ac41
SIP-27: Accounts Metadata Request
ritave Sep 18, 2024
8a2bd5e
Update SIP-27 with unsaved changes
ritave Sep 18, 2024
38d345f
Changed after code review
ritave Sep 20, 2024
0c4bf40
extension -> client
ritave Sep 20, 2024
18dff37
Use CAIP-2 chains and namespaces
ritave Sep 30, 2024
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
95 changes: 95 additions & 0 deletions SIPS/sip-27.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,95 @@
---
sip: 27
title: Accounts Metadata Request
status: Draft
author: Olaf Tomalka (@ritave)
created: 2024-09-17
---

## Abstract

This SIP allows Snaps to retrieve metadata related to accounts that exist in the extension.

## Motivation

The intention of this SIP is to allow Snaps providing new accounts for new chains to be able to list all accounts when selecting one during transfers. Currently the Snap can only access their own accounts, and can't do more complex UI flows.

The specific need for this SIP is to allow a Snap to create a send flow with an account picker, with an example design as follows.

<img src="../assets/sip-27/snap-account-list.png" alt="Account picker flow" width="600"/>

## Specification

> Indented sections like this are considered non-normative.

> Usage of `CAIP-N` specifications, where `N` is a number, are references to [Chain Agnostic Improvement Proposals](https://github.com/ChainAgnostic/CAIPs).

### Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" written in uppercase in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt)

### Snap Manifest

This SIP specifies a permission named `keyring_listAccountsAll`. This permission grants a Snap the ability to retrieve account metadata through an RPC call.

The permission is specified in `snap.manifest.json` as follows:

```json
{
"initialPermissions": {
"keyring_listAccountsAll": {}
}
}
```

### RPC Method

This SIP exposes a new RPC method called `keyring_listAccountsAll` with no additional parameters.

The RPC call returns with the following data:

````typescript
type KeyringAccount = {
/**
* An extension-specific unique ID providing stable identity.
*/
id: string;
/**
* Account addresses mapped by CAIP-2 namespace or chain ID.
*
* If the address is the same for all CAIP-2 chains, it's mapped only by namespace.
* @example
* ```typescript
* address: {
* 'eip155': ['0x1234...']
* }
* ```
*
* Otherwise, if the address differs between chains, it's mapped by chain IDs.
* @example
* ```typescript
* address: {
* 'eip155:1': ['0x1234...'],
* 'eip155:137': ['0x6789...']
* }
* ```
*/
address: Record<string, string[]>;
/**
* User-given nickname for the account in the extension.
*/
name: string;
};
Copy link
Contributor

Choose a reason for hiding this comment

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

If we wish to have a similar UI than the native one to list the accounts, we might needs some more information coming from the metadata field from InternalAccount (maybe not everything, but I was thinking about hardware-wallet accounts).

In case of HW, the account.type will be eip155:eoa, but we don't encode any other information regarding which HW if comes from. We do have this information in the account.metadata.keyring.type field like:

{
  "id": "651e5769-86b1-4717-ae7b-63a00d7b3872",
  "address": "0x9f753769a4b45e8e2ed61108f1174b5a0939e08e",
  "options": {},
  "methods": [
    ...
  ],
  "type": "eip155:eoa",
  "metadata": {
    "name": "Ledger 1",
    "importTime": 1727081928281,
    "keyring": {
      "type": "Ledger Hardware"
    },
    "lastSelected": 1727081928285,
    "nameLastUpdatedAt": 1727081928286
  }
}

And I believe, if we implement a similar AccountList component to display the list of accounts, we will need this keyring.type information to be able to display the small pill Ledger alongside the account entry.

Screenshot 2024-09-23 at 11 16 55

But I think @danroc had a different ideas regarding rendering a AccountList component, so maybe we won't even need to expose any of those metadata :).

I just wanted to be explicit here that type lacks some context/information.


type Keyring_ListAccountsAllResult = KeyringAccount[];
````

> Notice that multiple `Account`s can have the same `address`, for example when there are two hardware wallets using the same seed.

The call returns data concerning all accounts available in the client, both built-in Ethereum accounts as well as accounts managed by this, and other Snaps.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE).
Binary file added assets/sip-27/snap-account-list.png
View file
Open in desktop
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading