GreenField: Wallet API #2143
Replies: 2 comments 1 reply
-
@NicolasDorier do you have any guidance on what you'd like to have for the wallet API? |
Beta Was this translation helpful? Give feedback.
-
So I would say:
Seems good, and we should focus only on this for the first release.
This is because those would have different APIs, so it can't be generic. About If you start working on this, please keep it small. Like only starting by the OnChain wallets, instead of making a huge PR with everything in the kitchen sink. EDIT: About |
Beta Was this translation helpful? Give feedback.
-
Currently, a
WalletId
consists of astore id
and acrypto code
combined together with the format ofS-{storeId}-{cryptoCode}
. A wallet is 1-1 with a store (that is what theS-
prefix signals) and one of its on-chain payment methods. In the future, we would like to allow the creation of wallets which are not bound to a store and I would also like to extend the wallet concept to other payment methods that are not only on-chain, such as Lightning.I believe that
cryptoCode
should be removed from the id (wallet ids are not saved in the DB, only computed based on store and crypto in the url) and instead have the wallet crypto type under a nested url route (instead of ``S-gdhasdhsdgh-BTCit would be
S-gdhasdhsdgh/BTC`).Further to that, I also propose that we move from
crypto code
toPayment Method Id
, which consists ofCrypto code
andPayment type
. This allows us to have a collection of different payment method wallets under one Id, in an exact construction to a store (a store has many payment methods of many currencies) .API endpoint considerations:
As you can see, we can hit 2 birds with one stone, as the wallet API becomes also a Store Payment Methods API!
For each payment type, we will need separate endpoints as they configuration is different. We will implement only the APIs for
BitcoinLike
and forLightningLike
, and the altcoin communities are free to implement their own endpoints to manage those payment methods.The PR #1767 is almost perfect for the above proposal.
Using the actual wallet
Constructing transactions is a whole other beast. For BitcoinLike, it is as follows:
We should focus on a MVP for transaction management. For LightningLike, we could most likely mirror parts of the Store LightningNode API.
Beta Was this translation helpful? Give feedback.
All reactions