tomerweller

@tomquisel I think SEP12's `PUT /customer` essentially solves that already across the stack. Though we haven't expressed that anywhere. So (a) we should document it and (b) maybe add something...

@tomquisel, got it. Yeah this relates to our conversation from a couple of weeks ago regarding whether or not the kyc responses belong in SEP6 or SEP12. I guess there's...

Also, this might be a really bad idea but what if we'd have another SEP (always a good idea) for unauthorized responses and then both SEP6 and SEP12 could link...

@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....

Awesome. Looking forward to checking out the new version (I'm still on 1.19.2) Interesting idea on the multi-QR SEP. That definitely sounds like a comprehensive solution though on the more...

> The risk of a tx accidentally being submitted to pubnet exists. Just want to emphasize that this is a very real foot gun if we maintain the same passphrase....

The issue is not specific to near intents. It's with every contract interaction that includes moving of user funds. I would close this issue in favor of one to display...

Awesome. One note: richly communicating every smart contract interaction is a worthy endgame but might be a behemoth of a task. For now, I would focus on displaying `transfer` events...

Totally agree with @leighmcculloch. The prior art in the ethereum ecosystem demonstrates that having a uniform API across the stack (but with different implementations and retention policy) makes it easy...