SEP7 post messge callback

[tomerweller]

SEP7 consumers will often be frontend applications and so will wallets that support SEP7 as delegated signers.

How can SEP7 callers receive callbacks from the SEP7 signers? Currently, the only supported callback protocol is http, which requires setting up additional back-end infrastructure.

Is there a way to generate postMessage URIs that will go directly back to the frontend app?

@orbitlens, @morleyzhi, ideas?

[tomquisel]

Probably not totally applicable, but this is the SEP-6 approach. One thing I regret about that design is that there's no capacity for both an HTTP and a postMessage callback. I can see wanting a notification at both levels to make processing easier.

[nikhilsaraf]

@tomerweller SEP-0007 supports the callback field. The SEP for now has only specified how to use HTTP, but it can be easily expanded to allow for different callbacks. Using HTTP allows to work for both desktop and web wallet clients.

My concern with a postMessage callback is whether it will work for desktop clients. For example: if a website requesting payment was to use a callback of type postMessage and the user's wallet is a desktop wallet, where should it respond?

[orbitlens]

Mobile webviews (both IOS and Android) do support postMessage API, as well as Electron (the most common choice for desktop webviews). So the postMessage will work if the website with SEP-0007 link was opened inside a signer app. However, if a user clicks web+stellar link in browser which launches a separate signer/wallet app (desktop or mobile), the signer app won't have direct access to the origin browser window and won't be able to invoke a postMessage callback.

[nikhilsaraf]

@orbitlens I'm wondering whether the advantages of having a postMessage callback outweighs the universality that is lost (for desktop clients). The creator of the SEP-0007 request does not know (and should not know) what client (desktop/web) the user is going to open the link with and therefore would not know whether the postMessage callback can be successfully completed.

---

On @tomerweller's initial point, I think this is an important question we should all consider:

In which scenarios would a SEP-0007 link creator meet all four of these requirements:

1. The execution of the SEP-0007 request results in an interaction with the Stellar network
2. set a callback on the SEP-0007 request
3. need to take some action on the callback response
4. the creator of the SEP-0007 request does not already have a dependency on some backend infrastructure

I think in most cases requirement #⁠3 would mandate requiring some backend infrastructure (lambda, etc.) and requirement #⁠2 would only be set if #⁠3 was also a requirement. Requirement #⁠1 is one of the main purposes of a SEP-0007 request.

The only case I can think of where the above assumption breaks down, i.e. where requirement #⁠3 does not mandate requiring some backend infrastructure is when requirement #⁠1 is violated. i.e. a web page that is isolated to the frontend and which updates the frontend based on your callback response. The action here (requirement #⁠3 above) is the update to the frontend web page to display more information. There is no interaction with the Stellar network in this scenario, so requirement #⁠1 is violated.

Is there a category of use cases that meets all four of the above requirements?

[orbitlens]

@nikhilsaraf Fully agree with you. The link should work on all clients regardless of the environment, so postMessage is not a universal approach in this case.

[tomerweller]

@nikhilsaraf ,

Is there a category of use cases that meets all four of the above requirements?

Yes, the category of client side webapps communicating with a browser extension. This is not a theoretical use case, it's what a a huge chunk of the ethereum ecosystem is built on (metamask).

In our ecosystem such potential sep7 uri creators: account viewer, stellarterm, mystellar.tools. And probably more once client side apps don't have to worry about key storage and signatures.

I'm not a fan of browser extensions being used in security sensitive places, but we have to acknowledge this category.

[nikhilsaraf]

@orbitlens sounds good, thanks!

---

@tomerweller:

In our ecosystem such potential sep7 uri creators: account viewer, stellarterm, mystellar.tools. And probably more once client side apps don't have to worry about key storage and signatures.

can you give me an example of the action that these apps (account viewer, stellarterm, mystellar.tools) are taking as a result of SEP-0007 submission by the client wallet?

[Pykagamers]

Los consumidores de SEP7 a menudo serán aplicaciones frontend, al igual que las billeteras que admiten SEP7 como firmantes delegados.

¿Cómo pueden las personas que llaman SEP7 recibir devoluciones de llamada de los firmantes SEP7? Actualmente, el único protocolo de devolución de llamada admitido es http, que requiere configurar una infraestructura de back-end adicional.

¿Hay alguna manera de generar postMessageURI que vayan directamente a la aplicación de interfaz?

@orbitlens , @morleyzhi , ¿ideas?

No sabía soy nuevo en esto discúlpeme ahora lo borro