login: open new WS and refresh QR code after 45s

[smweber]

No description provided.

[tulir]

I'm pretty sure it requires more changes than just auto-reconnecting, signal seems to have a x-signal-websocket-timeout: true header at least

[tulir]

https://github.com/signalapp/Signal-Desktop/blob/main/ts/textsecure/Provisioner.ts#L104-L110 also looks funny

[smweber]

So as far as I can tell, based on observing Signal Desktop in mitmproxy and peeking at the changes (server and desktop), it looks like the new behaviour is just holding two provisioning websockets open at a time, and letting the older one timeout. So it goes something like this:

• t:0s: open WS 1 and display it's QR
• t:45s: open WS 2 and display it's QR (but WS1 stays open and it's QR code still valid)
• t:60s: WS 1 times out
• t:90s: open WS 3 and display it's QR (but WS2 stays open and it's QR code still valid)
• t:105s WS2 times out
• ...etc. (stop after 6 iterations)

Signal Desktop's previous behaviour (which I just confirmed) is just keep one provisioning WS open with keepalive messages indefinitely. I assume they made this change because making new websockets is more robust when changing networks? Or holding websockets open indefinitely doesn't play well on their server?

However the previous signalgo behaviour (before the bridgev2 rewrite) was similar to the new Signal Desktop behaviour - don't keepalive, and instead just open new websockets when the old ones timeout. Without keepalives the websockets timeout anyway, so I don't actually think they needed to add the optional "timeout" header, but I guess they wanted a way to timeout websockets while still sending keepalives?

This PR doesn't implement the new Signal provisioning behaviour, it goes back to the original behaviour I made with signalgo. (Why didn't I originally implement keepalives? Probably because provisioning was the first thing I did and I had no idea what I was doing ;). This PR will at least allow the bridge to send more than one QR code (which is connected to a WS that closes after ~60s) and solve the immediate issue of users needing to rush to scan the QR code on their Signal bridge.

To fully implement the new Signal provisioning behaviour, we'll need to:

• (Optionally) add the x-signal-websocket-timeout: true when opening the websocket, and send /v1/keepalive/provisioning messages
• modify signalmeow to have two provisioning websockets open at the same time (this will likely be a big pain, I don't love the provisioning WS handling code I wrote)
• have signalmeow drive pushing new websockets to the connector, instead of the connector driving the websocket loop

Clients using the connector's provisioning API shouldn't notice a difference between the behaviour in this PR and the proposed new Signal provisioning behaviour above, but the benefit would be QR codes scanned just before the new QR code is displayed would still work, where as with this PR there is an edge case where a QR code is scanned just as they are switching and the provisioning fails (though at that point a new QR code is displayed and a subsequent scan works fine). I figured this tradeoff is okay for now, since it's still strictly better than failing QR scan forever after 60s.