Solana Client "Wallet"
Problem
At the moment the solana-specific client code supports a signer of type KeyPairSigner from @solana/kit.
Unfortunately this doesn't work well for browser wallets, or perhaps other wallets that we haven't considered yet.
So for most browser implementations so far we've had to roll out our own client-side flow.
Solution
It seems like createPayment and perhaps even verify and settle should take a TransactionSigner instead of (or now in addition to) a KeyPairSigner.
The KeyPairSigner is implemented as a PartialSigner, a specific type of TransactionSigner.
By adding TransactionSigner, I believe we'd be able to support browser wallets more easily.
For example, the @solana/react package has a useWalletAccountTransactionSigner that would take a UiWallet and return a ModifyingTransactionSigner which is a specific type of TransactionSigner.
From my understanding so far, most solana wallets will be compatible with the wallet-standard and wallet-adapter, which UiWallet is a part of.
Another Problem Worth Discussing
It also seems like a lot of existing wallet providers are stuck on web3js.
Do we want to add support for that here, or try to break the cycle and keep going forward with solana/kit only?
Looking for feedback / thoughts.
@amilz would love to get your thoughts here.
Will take a look. Also tagging @stevesarmiento who has been a lot closer to Solana Kit support for browser wallets.
I still owe a comment here, but wanted to flag looks like Solana Kit v4 was just released w/ some impacts on wallet signing.
Hey, @amilz tagged me in, I want to take a crack at this. Is there any more context you think I should consider?
I still owe a comment here, but wanted to flag looks like Solana Kit v4 was just released w/ some impacts on wallet signing.
From the changelog:
If you are using a TransactionModifyingSigner such as useWalletAccountTransactionSigner, then you will now receive a transaction with TransactionWithLifetime when you would previously have received a type with a lifetime matching the input transaction message.
This was never guaranteed to match at runtime, but we incorrectly returned a stronger type than can be guaranteed.
You may need to use the new isTransactionWithBlockhashLifetime or isTransactionWithDurableNonceLifetime functions to check the lifetime type of the returned transaction.
For example, if you want to pass it to a function returned by sendAndConfirmTransactionFactory then you must use isTransactionWithBlockhashLifetime or assertIsTransactionWithBlockhashLifetime to check its lifetime first.