chaincase-app
Polling frequency too great during standby - bg join timing
To CoinJoin within a 30s window of background processing the connection confirmation phase has been reduced to ~7s and the synchronizer polling to 3s.
But there is no need to poll every 3s outside of the connection confirmation phase. However, the coordinator will drop Alice's registration if she does not make contect at least every ConnectionConfirmationTimeout period of time. I'm not sure what purpose connection confirmation i.e. "registered" status serves during the InputRegistration phase in Chaincase where most users are only online during the critical final phases of zerolink protocol (Connection confirmation, Output registration, & signing)
One solution may be to both reduce the frequency to confirm connection during standby at the coordinator and reflect the change in the client.
Be mindful of how any decision may effect those who don't allow remote notifications
There are related random delay to create Poisson distribution of an individual clients requests which can mitigate potential for coordinator timing attacks https://github.com/zkSNACKs/WalletWasabi/pull/5827
even if polling is reduced, once queued it's important to give user feedback that they're registered ASAP
There are a few timing issues regarding the background coinjoin
With regards to timing that remains untested I've found the greatest reliability with the backend sending a notification 17s before registration ends. There timing changes that can be paramaterized are WasabiSynchronizer loop, OnResuming requestInterval (which was shortened for a more responsive feel, but could just be shortened temporarily around e.g. registration & ceremony) & ClientState: delayRegistration on Registration (in hopes of re-register, can be done with periodic fetch instead), & of course CoinJoinClient in TryProcessStatusAsync which should be paramaterized as in Wasabi to prevent timing attack vulnerabilities