Socket Based Subscriptions

[abhishek0405]

The current architecture for communication between the client and server is a traditional request-response based model where the react client requests for any resource or action from the backend. Mechanisms similar to polling have been used implement a heartbeat route to check whether the backend is alive . However for obvious reasons, this is not the most optimal way to go about this.
A mechanism that enables real time communication would be a much better solution. Web Sockets seem to be a good fit for this task. I feel there are four important use cases of this architecture as of now :

1)Realtime wallet updates: This involves notifying the users when new funds are received.

2)Coinjoin updates: This would involve displaying the offers taker receives during a coinjoin. Adding an additional functionality of accepting or rejecting the offer directly from the client software would be another improvement.

3)Maker notifications : Alerting the user whenever a maker transaction succeeds from their wallets. This should display the transaction details and the amount.

4)Heartbeat Route: Upgrading the current heartbeat mechanism from polling to subscription based model.

Hence the idea of having a Publisher Subscriber Architecture seems to be a good idea.

Note: This would require updates in both the frontend and backend. Autobahn seems to be useful for developing such Pub-Sub based designs.

[AdamISZ]

Thanks.

For autobahn, it's just something that can help with the backend because it implements websocket servers in Python using Twisted. See:

https://github.com/crossbario/autobahn-python/tree/master/examples/twisted/websocket

For front end, we need to do whatever is normally done for client side websocket connections. At least I believe so.

[AdamISZ]

As of 79e90ea :

This is just a start but proves the basic concept of the notification-via-backend-callback functionality:

After the user unlocks/opens the wallet, and chooses to do a payment from some account, and receives the "Payment successful!" alert (todo: change that, it is only a notification of having tried to pay), they then receive a notification of the txid which is alerted also.

Of course this stuff like alert boxes is primitive (also the hardcoded wss url string perhaps), but more substantive point:

I discovered after a couple hours reading that you cannot open a websocket in such a javascript app and have it stay open if you navigate to different pages. So initially, putting the opening of the websocket in the successful response to the unlockwallet API call, didn't work; the websocket auto-closed itself as soon as I clicked "Open" which navigated to /display.

This is problematic, I suggest we look at a Single Page Application architecture, but I am not too sure on the details.

Personally I am going to pull back a bit on trying to develop this further. I'd like someone with more expertise to do it, or of course they may use a different framework also. In principle, everything we need to do is possible.

• Transaction notifications (already done)
• Notification of filtered offers for user choice to do a second step /completecoinjoin API request (not yet in the backend, for now it just accepts offers without user input).
• More enriched transaction notifications than 'it is on the network', such as 'it represents a yield generation of 10k sats' (because recognized as the completion of maker-side join).

I'm sure there are others. But that's for later.

[AdamISZ]

See new API docs as per JoinMarket-Org/joinmarket-clientserver@b527bbb ; code here will need to be updated for API changes.