Sdk updates for proposed 1.1 spec

[mcintyre94]

Marking as draft because we'll want to coordinate this release so we don't confuse application developers. Maybe a 1.1 or alpha branch?

This PR adds the spec changes to support the proposed/alpha 1.1 spec

• Redirect is added as an optional parameter on transfer request URLs. Note that for transaction requests redirects are part of the POST response which is out of scope for the SDK.
• A new MessageSignRequestURLFields is added with just a link field. Internally encodeURL encodes it in the same way as a transaction request

Notes:

• No SDK changes are made for transaction request error handling, because again they're just part of the POST response
• Should we deprecate the label and message fields of TransactionRequestURLFields? They're not in the spec and I haven't included them in the fields for message signing requests. I think they're superseded by label in the GET response, and message in the POST response. If we eventually remove them we could simplify the encoding since transaction request and message signing request would be the same structure.
• I think using encodeTransactionOrMessageSignRequestURL is kinda hacky, but we can't differentiate TransactionRequestURLFields from MessageSignRequestURLFields at a typescript level

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated
solana-pay	✅ Ready (Inspect)	Visit Preview	💬 Add your feedback	Feb 28, 2023 at 4:32PM (UTC)
solana-pay-docs	✅ Ready (Inspect)	Visit Preview	💬 Add your feedback	Feb 28, 2023 at 4:32PM (UTC)

[jordaaash]

Looks good! I'm going to do another round of review on the spec itself.

[jordaaash]

I think this type can be (structurally) the same as TransactionRequestURLFields, right? Label and message can still be used.

[jordaaash]

I think maybe we should rename the type of request to a Sign Message Request in the spec and here.

[mcintyre94]

They can still be used, but it seems a bit confusing because wallets would presumably ignore them. Both fields are not inputs in the spec, and are also fields in server responses which I think makes it more confusing. We do already have this problem with transaction requests - I just wasn't sure whether it was a good idea to do the same here, and thought it might be better to move toward removing the fields from transaction request in the SDK instead.

Renaming to Sign Message Request sounds good to me, seems a bit more natural!

[jordaaash]

This can also be simplified if we allow those fields.