Allow multiple BobStates #2777
Comments
|
This... is no longer true? Is this still the right way to notify the user? |
the comment is wrong, yes. the end-user is now informed by info-messages added to the corresponding chat, so, from view of the ui, there is nothing more to do anymore. |
Ok, I think the |
|
Do we want to allow alice to invite bob with multiple QR codes in parallel, e.g. "here join this and this groups". Or do we only want to allow bob to join multiple alices? From a user point of view the latter is probably a weird case that's different to understand. This matters because if we allow multiple joining processes at the same time we have to know which bit of state to load from the db. The securejoin protocol took care of this on the alice side with an invite code but the bob side doesn't really do this. We can probably amend the protocol a little, e.g. bob sends an additional header which alice needs to send back, but we'd need to think through the security implications. |
i think, in the long run, it would be nice if Bob can just scan multiple qr-codes, no matter if they come from the same or from different Alices. usecase could be eg. a gathering prepared by Alice - "scan here and here and here to join the groups 'kitchen', 'chore' and 'fun'" :) but if the "same Alice" turns out to be complicated and needs adaptions in the protocol, maybe just start with the simpler parts - persistence and allow Bob to scan different Alices. scanning the same Alice again, will abort pervious handshakes with that Alice (as now with all handshakes). maybe that's already "good enough". in any case it would already be a huge improvement over the current state. EDIT: and we can iterate from there - maybe we could also serialize different handshakes with the same Alice. that would save some messages as subsequent joins will take the shortcut in the protocol. |
|
now that the group chat is created up front, does it make sense to re-direct (some) info messages about the progress and/or failure of joining a group to this chat instead of the 1:1 chat of the inviter? In any case I'll do this separately, but makes sense to think about already. |
for Bob, this already happens. for group-joins all info messages go to the group-chat (info messages are added to to reduce noise and to focus on the gist of the scan - joining a group -, the one-to-one chat is not even shown to the user (however, the contact is added and verified, of course) (technically, the one-to-one chat is there, as it is needed for the messages currently, however, unless it was present before, it is not added to the chatlist the user sees) |
The state bob needs to maintain during a secure-join process when exchanging messages used to be stored on the context. This means if the process was killed this state was lost and the securejoin process would fail. Moving this state into the database should help this. This still only allows a single securejoin process at a time, this may be relaxed in the future. For now any previous securejoin process that was running is killed if a new one is started (this was already the case). This can remove some of the complexity around BobState handling: since the state is in the database we can already make state interactions transactional and correct. We no longer need the mutex around the state handling. This means the BobStateHandle construct that was handling the interactions between always having a valid state and handling the mutex is no longer needed, resulting in some nice simplifications. Part of #2777.
The state bob needs to maintain during a secure-join process when exchanging messages used to be stored on the context. This means if the process was killed this state was lost and the securejoin process would fail. Moving this state into the database should help this. This still only allows a single securejoin process at a time, this may be relaxed in the future. For now any previous securejoin process that was running is killed if a new one is started (this was already the case). This can remove some of the complexity around BobState handling: since the state is in the database we can already make state interactions transactional and correct. We no longer need the mutex around the state handling. This means the BobStateHandle construct that was handling the interactions between always having a valid state and handling the mutex is no longer needed, resulting in some nice simplifications. Part of #2777.
The state bob needs to maintain during a secure-join process when exchanging messages used to be stored on the context. This means if the process was killed this state was lost and the securejoin process would fail. Moving this state into the database should help this. This still only allows a single securejoin process at a time, this may be relaxed in the future. For now any previous securejoin process that was running is killed if a new one is started (this was already the case). This can remove some of the complexity around BobState handling: since the state is in the database we can already make state interactions transactional and correct. We no longer need the mutex around the state handling. This means the BobStateHandle construct that was handling the interactions between always having a valid state and handling the mutex is no longer needed, resulting in some nice simplifications. Part of #2777.
The state bob needs to maintain during a secure-join process when exchanging messages used to be stored on the context. This means if the process was killed this state was lost and the securejoin process would fail. Moving this state into the database should help this. This still only allows a single securejoin process at a time, this may be relaxed in the future. For now any previous securejoin process that was running is killed if a new one is started (this was already the case). This can remove some of the complexity around BobState handling: since the state is in the database we can already make state interactions transactional and correct. We no longer need the mutex around the state handling. This means the BobStateHandle construct that was handling the interactions between always having a valid state and handling the mutex is no longer needed, resulting in some nice simplifications. Part of #2777.
The state bob needs to maintain during a secure-join process when exchanging messages used to be stored on the context. This means if the process was killed this state was lost and the securejoin process would fail. Moving this state into the database should help this. This still only allows a single securejoin process at a time, this may be relaxed in the future. For now any previous securejoin process that was running is killed if a new one is started (this was already the case). This can remove some of the complexity around BobState handling: since the state is in the database we can already make state interactions transactional and correct. We no longer need the mutex around the state handling. This means the BobStateHandle construct that was handling the interactions between always having a valid state and handling the mutex is no longer needed, resulting in some nice simplifications. Part of #2777.
The state bob needs to maintain during a secure-join process when exchanging messages used to be stored on the context. This means if the process was killed this state was lost and the securejoin process would fail. Moving this state into the database should help this. This still only allows a single securejoin process at a time, this may be relaxed in the future. For now any previous securejoin process that was running is killed if a new one is started (this was already the case). This can remove some of the complexity around BobState handling: since the state is in the database we can already make state interactions transactional and correct. We no longer need the mutex around the state handling. This means the BobStateHandle construct that was handling the interactions between always having a valid state and handling the mutex is no longer needed, resulting in some nice simplifications. Part of #2777.
The state bob needs to maintain during a secure-join process when exchanging messages used to be stored on the context. This means if the process was killed this state was lost and the securejoin process would fail. Moving this state into the database should help this. This still only allows a single securejoin process at a time, this may be relaxed in the future. For now any previous securejoin process that was running is killed if a new one is started (this was already the case). This can remove some of the complexity around BobState handling: since the state is in the database we can already make state interactions transactional and correct. We no longer need the mutex around the state handling. This means the BobStateHandle construct that was handling the interactions between always having a valid state and handling the mutex is no longer needed, resulting in some nice simplifications. Part of #2777.
|
Proposal to allow bob to scan multiple QR codes from Alice concurrently: In each response from Alice, For cases where Bob supports multiple concurrent joins but Alice doesn't yet Alice would not include this header. If Bob has multiple joins with Alice at this point he aborts all of them with a suitable error message in the chats. |
link2xt
changed the title
|
Currrently BobState is persisted: #2920 |
|
Looking at the protocol, it seems there are no protocol changes required. In the worst case Bob scans two QR codes from Alice trying to join two different groups with the same inviter. Bob sends two Bob states should also be cleaned up eventually to remove stale processes, but this can be done in housekeeping, like e.g. after 30 days, if not done already (did not check). |
|
Code-wise it looks like Alice is also prepared to receiving |
|
Replaced with a less cluttered #6531 |
BobStateis currently kept in memory only and there is only oneBobState. this has the following disadvantages:if the app is terminated before Alice answers, the secure join will get stale. eg. iOS suspends app in the background already after 30 seconds, usually the memory is restored on coming to foreground again, but that depends: apps may also be terminated already after 30 seconds.EDIT this is fixed by #2920android may have similar situations, but also a simple user-exit may terminate a handshake unexpectedly, esp. it that runs for several minutes.
since instant success on simple qr-setup-contact #1215 and non-blocking group QR joins #2508 all handshakes run in background and
dc_join_securejoin()always returns immediately with the chat-id.however, if
dc_join_securejoin()is called again before the old one has finished, the old one is aborted (which is already better than showing an error :)the idea is to target both issues by handling
BobStatecompletely in the database, eg. in a separate table, one row per state.The text was updated successfully, but these errors were encountered: