add sep24 callback params #97
Conversation
* add sep10 helper method * name change * correct resp * create server module
src/walletSdk/Anchor/Sep24.ts
Outdated
| @@ -61,6 +61,10 @@ export class Sep24 { | |||
| * @param {ExtraFields} [params.extraFields] - Additional fields for the request. | |||
| * @param {Memo} [params.destinationMemo] - Memo information for the destination account. | |||
| * @param {string} [params.destinationAccount] - The destination account for the deposit. | |||
| * @param {string} [params.callback] - The callback URL or postMessage the anchor should POST to | |||
There was a problem hiding this comment.
@Ifropc is postMessage something that's used / we should support?
and if so what's an example of one? just a JSON string?
There was a problem hiding this comment.
We should not support postMessage. This is an error-prone way of signaling to the wallet to close the webview, and there are more straightforward approaches to this that have better user experiences as well.
There was a problem hiding this comment.
- We are deprecating postMessage
- We are also deprecating approach of passing callbacks "as is" to the request parameter. I'm working on drafting new approach, where callbacks are passed outside of the request.
So let's hold on this PR for now
There was a problem hiding this comment.
We may want to hold this PR until we come to a conclusion on what changes we want to make to the SEPs regarding callbacks.
There have been various discussions internally and with partners about whether the proposals should encourage callbacks to endpoints provided by the client on a per-transaction basis. It appears as if most businesses providing callback prefer to have client's register static endpoints outside of the transaction processing flow defined in SEPs. MoneyGram and Circle for example both take this approach to their respective callback services.
The two viable paths I see on this topic is to
- Keep the
callbackandon_change_callbackparameters in the proposal, leaving it up to each anchor and wallet pair to determine whether and how they will implement support. - Deprecate and eventually remove the parameters and recommend that anchors require clients to register callback endpoints with them prior to initiating transactions.
|
makes sense, I'll keep this PR in drafts then until we know how we want to handle the callbacks |
|
hey @JakeUrban how long do you think it will be until the new way to handle callbacks is determined? and do you think it'd make sense to merge this code in now, and then we can change it later once the SEP changes |
|
Hey @acharb I think for now we can close this PR. We still need to discuss it more internally. Currently, in the Anchor Platform, which we use as a standard implementation of all SEPs, callbacks are configured on the Anchor side. So we may want to align protocol to the implementation, as we think this approach is better for various reasons |
|
@Ifropc are you saying the Anchor Platform implementation currently deviates from the SEP standard and we think we might want to update the SEP standard to reflect this deviation? any risk to merging what we have here for now while we figure out the changes we'd like to make? also do you have any kind of ETA for when we'll land on a longterm solution? |
|
@mtwtfss |
|
@Ifropc do we have any news regarding the usage of sep24 callback parameters? I'm leaning towards closing this PR given it's around for a long time now |
|
I agree we can close this PR. It might be easier to re-do it in the future if necessary |
ticket