Description
The issue is a replacement for #2777.
Since #2920
bob state is stored in the database.
Current bobstate table is created in migration 86:
CREATE TABLE bobstate (
id INTEGER PRIMARY KEY AUTOINCREMENT,
invite TEXT NOT NULL,
next_step INTEGER NOT NULL,
chat_id INTEGER NOT NULL
)
Here next_step is the next expected message from Alice,
one of
- 0: vc-auth-required or vg-auth-required
- 1: vc-contact-confirm or vg-member-added
- 2: terminated
- 3: completed
"Terminated" and "Completed" states are never actually stored in the database and should be removed.
next_step = 1 is also unnecessary. Once we have sent AUTH code out, we can forget about the invite code. If vc-contact-confirm or vg-member-added (actually any message with Chat-Verified header) arrives from Alice then cool, we can mark Alice as backward-verified, but if not, we are not going to do anything anyway. There is no special processing for vc-contact-confirm or vg-member-added needed other than emitting progress event. Also vg-member-added in non-protected group (without Chat-Verfied header) should set backwards verification.
Overall the only purpose of having a Bob state is to remember AUTH code and Alice's expected fingerprint when sending vc-request or vg-request if Bob does not have the key for Alice yet. When vc-auth-required or vg-auth-required is received, Bob should lookup the database, check that Alice has the key with fingerprint corresponding to the invite code, mark the key as verified and send the AUTH code in a vc-request-with-auth or vg-request-with-auth code.
Currently there can be only one bob state at the time.
If Bob scans a QR code, all existing bob states are removed
and warnings are issued about aborted QR code scanning processes:
https://github.com/deltachat/deltachat-core-rust/blob/81e9628ab79941adaa12de1e30cefb8d8d69b3f9/src/securejoin/bob.rs#L48-L52
Instead of removing bob states,
we should keep existing states
in case a message from Alice arrives.
When a message from Alice is received,
Bob should advance all matching bob states.
For example, if Bob scans two QR codes at the same time
from the same Alice, he will first send
two vc-request messages.
Then he will receive two vc-auth-required messages.
When Bob receives first vc-auth-required message,
he should advance both states to the next stage
and send two vc-request-with-auth messages.
When processing the second vc-auth-required message,
Bob should ignore it because there are no bobstates
with next_step=0.
Alice is already completely stateless,
so can handle multiple messages sent by the same Bob
or multiple Bobs in parallel.
We need at least a test where Bob joins two groups in parallel by scanning two QR codes from the same Alice.
There is also a corner case of Bob who has two devices scanning two different QR codes from the same Alice at the same time. When one of the Bob's devices receives vg-auth-required, it should not delete the message from IMAP if it has not sent any AUTH codes, because otherwise it is possible that first Bob's device will consume both vg-auth-required messages and second device will not be able to send the AUTH code.
PR is at #6534