Replying to Avatar Egge

I am pretty sure 50% of the coco-cashu codebase is now subscription and state check logic.

- Whenever the wallet requires updates from the mint it will subscribe for them.

- Coco will batch and debounce subscriptions as much as possible.

- It will re-connect sockets automatically and re-subscribe now stale subscriptions

- If a socket breaks and can not be reconnected it will automatically fallback to polling. The same happens if the environment or the Mint does not support WS.

- In polling automated backoffs are added, proof checks are batched.

- All HTTP communication with the mint is throttled by a token-based system that allows bursts, but will make sure we don't call the mint more than 25 times per minute.

- The throttling logic filters by requested URL, so that non-rate-limited endpoints like /keys or /info don't could towards our threshold.

I really find this to be the most difficult part about building a wallet. I hope this gives us a solid foundation to build up on.
Avatar
meduzot 3mo ago

You've modeled this as a finite state machine?

Reply to this note

Please Login to reply.

Discussion

Avatar
Egge 3mo ago

What exactly? The fallback logic is actually quite naive right now, as it will never retry websockets after falling back to polling. However processes are usually short lived enough that it doesn’t matter

Avatar
meduzot 3mo ago

This article is quite good at explaining: https://wickstrom.tech/2017-11-10-finite-state-machines-part-1-modeling-with-haskell.html

Don't get hung up on the language though. Anyway, using something like this may help how you structure your code.

Avatar
calle 3mo ago

followed