-
-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid adding members twice via securejoin #5356
Comments
I think the |
There is a single member-added message that might get sent extra NUM_DEVICES-1 times -- and membership changes are relatively rare (compared to regular chat messages) so not a big enough deal to tilt the balance to adding extra state and more involved code and tests to core. We could consider btw to remove securejoin request messages from IMAP folder after we handled them so when the second device comes online it will never see them, only the eventual BCCed member-added message. |
Since we have started synchronizing QR codes to other devices, this situation frequently happens:
This results in a second "Member added" message in a group. Even worse scenario is if Alice2 goes online way later when Bob already left the group or was removed from it.
One solution discussed is to store securejoin messages in a separate table similar to how we handle webxdc updates and only "flush" it into outgoing SMTP queue at the end of message fetch, so Alice2 can notice that Alice1 has already added Bob and drop pending securejoin messages.
There is however a simpler solution that does not require separate state for pending securejoin messages. We can generate Message-ID for
vg-member-added
by hashingIn-Reply-To
, i.e. the Message-ID ofvg-request-with-auth
message andAUTH
secret. This way both Alice1 and Alice2 will generate the same Message-ID forvg-member-added
and the secondvg-member-added
will be ignored by recipients.There are drawbacks to the
Message-ID
solution. First problem is additional traffic generated by Alice2. Also second message may still be processed if some device has not received first "Member added" message e.g. because they joined the group later than Bob they will still process second "Member added" message which might come way later. This can however be solved by not sending the message from Alice2 at all if it finds out that it generated the same Message-ID that it already has in theimap
table from the "prefetch" step. Prefetch is guaranteed to be complete by the time Alice2 gets to the step of fetching securejoin messages.The text was updated successfully, but these errors were encountered: