SIP for Wallet client API draft

HeroGamer · February 14, 2023, 3:22pm

Please see original GH issue opened by @Kryan & Jannik based on some work Friedger has done in the past.
Draft in the comment just expand

github.com/stacksgov/sips

Wallet client API

opened 07:10AM - 04 Feb 23 UTC

kyranjamie

There should be a standard describing the style of API used by wallet clients. … @friedger pushed a [draft SIP](https://github.com/stacksgov/sips/pull/59) a while back describing the existing wallet API. Though, more recently, there's been some discussion about moving away from the existing JWT-style API towards something more consistent with other ecosystems, like an RPC style API. I suggest a SIP that describes a feature-agnostic RPC API that works cross-platform: Web Extensions, mobile apps, CLIs etc, similar to that of [`EIP-1102`](https://eips.ethereum.org/EIPS/eip-1102). <details> <summary>SIP Draft</summary> # Wallet Client API This SIP describes a simpler standard for apps to interface with wallet clients. ## Abstract This proposal outlines a uniform manner with which apps can interface with wallet clients. It recommends to minimise the surface area of available APIs, and makes design decisions similar to those in other crypto ecosystems. ## Introduction No standard exists describing how apps interact with Stacks-compatible wallets. Presently, ecosystem wallets adhere to an undocumented set of commands that wallets should implement. A well-documented API, that’s familiar to developers from other ecosystems, benefits both app and wallet developers. The purpose of this SIP is to describe the outline of an API that can support multiple environments including, but not limited to, Web Extensions, mobile wallets, CLIs etc. It does not describe the individual methods that clients may commonly support. ## Specification Two methods are described. The methods can be typed such that the return value corresponds to the method name passed. ### `request` `request(method: string, params?: object[]): Promise<T>` A `request` method is accepted by clients, following the [JSON RPC standard](https://www.jsonrpc.org/specification) _Example_ ```ts const accounts = await Provider.request('stx_requestAccounts'); ``` ### `listen` `listen(event: string): Observable<T>` A `listen` method accepts an event parameter. It returns an `Observable`, following the [TC39 specification](https://github.com/tc39/proposal-observable), that consumers can subscribe and unsubscribe to. _Example_ ```ts Provider.listen('networkChange').subscribe(network => toast('Switched network')) ``` ## Related Work [https://eips.ethereum.org/EIPS/eip-1102](https://eips.ethereum.org/EIPS/eip-1102) [https://eips.ethereum.org/EIPS/eip-1474](https://eips.ethereum.org/EIPS/eip-1474) [https://eips.ethereum.org/EIPS/eip-2255](https://eips.ethereum.org/EIPS/eip-2255) ## Backwards Compatibility Wallet clients should continue to support the existing methods until a time where a sufficient majority of apps adhere to the new standard. They may warn developers of the newer format, encouraging developer to migrate. ## Activation This SIP is considered activated when at least two wallet clients support this API. </details> Happy to work on this with anyone that wants to collaborate. cc/ @janniks @yknl @markmhx @fbwoolf @edu-stx Edit: March 2023 update With the suggestions/ideas from this SIP @janniks and I have started http://btckit.org, which aims to push this effort and form a community-driven, wallet-agnostic standard.

This is a big utility unlock, please chime in particular:
1. wallet providers
2. builders

some TLDR and use cases: HeroGamer⚡ on X: "Builders like @AlexLabBTC @ZestProtocol @NeoSwap_ai @LiquidiumFi @trygamma @tradeportxyz all can benefit from this. e.g.👇" / X

Will need some testers to try out the UIUX in testnet soon.
Raise your hand if you are interested too.