Support wallet disambiguation and deeplinking in protocol spec, url encoding, and url parsing #115
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem Overview
This branch addresses requests in #100 to update the Solana Pay protocol specification to support wallet disambiguation in iOS clients and deeplinking to address some security vulnerabilities.
Solution & Decision Log
The open issue proposes several changes; this PR is the first step towards implementing those changes from Solana Pay's end. In addition to this, there will need to be followup PRs to fully close the issue.
Handling the Spec Changes
The issue poster suggested to allow for a url like
https://phantom.app/code?
instead of the current url schemesolana:
. However, the suggested URL has a path, which should be used for therecipient
according to the current protocol spec. There are a few options of how we might want to handle this:recipient
as a query parameter. I'm avoiding this since breaking changes are costly.recipient
in the path, and just parse it out of the end of the wallet URL (in the cases where we use a wallet URL). This is a bit of a rigid solution since it relies on wallet applications registering a wildcard route to handlerecipient
in the path. The parsing also feels a little hacky to me, so I’m not a fan of this one.recipient
query parameter. This will be encoded in the URL when a wallet is provided, otherwise it will default to puttingrecipient
in the path. This solution is backwards compatible and flexible so I decided to implement this.Supporting Wallet Disambiguation
This solution creates a TypeScript enum for tracking supported wallets called
SupportedWallet
. Wallets can create PRs to add their wallet and their registered url to this enum. This branch leaves the enum empty for now, which means we can't build much around this until enum entries are added.Testing
encodeURL.test.ts
will need additional tests once supported wallets have been added to theSupportedWallet
enum.Next Steps
request
query param usage). This could be included in this PR but I don't have access to the files for these diagrams.