Add SEP-24/SEP-6 communication between client_domain and anchor

[jopmiddelkamp]

What problem does your feature solve?

As a non-custodial wallet, tracking the status of client deposits and withdrawals can be challenging. We implemented a polling mechanism to fetch status updates, but this approach has proven inefficient, as it generates numerous unnecessary calls to our partner’s services. Additionally, receiving these updates on our back-end gives us the ability to send notifications to our users device without having to keep it awake most of the time.

What would you like to see?

We would like to add some interaction between the anchor and the client domain. The way we see this possible is via the following steps:

1. [Client Front-end] is requesting SEP-10 challenge with client_domain (belonging to [Client Back-end]) from the [Anchor Back-end]
2. [Client Front-end] signs the challenge
3. [Client Front-end] sends the challenge to the [Client Back-end] to sign the transaction
4. [Client Front-end] sends the challenge to the [Anchor Back-end] to verify the transaction
5. [Anchor Back-end] reads out the client_domain and reads out the TRANSFER_SERVER_CALLBACK_URL from the SEP-1 data
6. [Client Front-end] receives a JWT
7. [Client Front-end] requests a deposit from the [Anchor Back-end] via the JWT
8. [Anchor Back-end] sends updates directly to the TRANSFER_SERVER_CALLBACK_URL
9. [Client Back-end] can now send (silent) notifications to the [Client Front-end]

Legend:

• [Client Front-end]: The non-custodial wallet application
• [Client Back-end]: The back-end server belonging to the Client Front-end
• [Anchor Back-end]: The back-end server belonging the the Anchor

What alternatives are there?

The background worker we’ve built feels cumbersome and unnecessarily complicates the process, even though it shouldn’t be this way.