diff --git a/draft/group-sync.rst b/draft/group-sync.rst new file mode 100644 index 000000000..286d19cb6 --- /dev/null +++ b/draft/group-sync.rst @@ -0,0 +1,126 @@ + +Problem: missing eventual group consistency +-------------------------------------------- + +If group members are concurrently adding new members, +the new members will miss each other's additions, example: + +- Alice and Bob are in a two-member group + +- Alice adds Carol, concurrently Bob adds Doris + +- Carol will see a three-member group (Alice, Bob, Carol), + Doris will see a different three-member group (Alice, Bob, Doris), + and only Alice and Bob will have all four members. + +Note that for verified groups any mitigation mechanism likely +needs to make all clients to know who originally added a member. + + +solution: memorize+attach (possible encrypted) chat-meta mime messages +---------------------------------------------------------------------- + +For reference, please see https://github.com/deltachat/deltachat-core-rust/blob/master/spec.md#add-and-remove-members how MemberAdded/Removed messages are shaped. + + +- All Chat-Group-Member-Added/Removed messages are recorded in their + full raw (signed and encrypted) mime-format in the DB + +- If an incoming member-add/member-delete messages has a member list + which is, apart from the added/removed member, not consistent + with our own view, broadcast a "Chat-Group-Member-Correction" message to + all members, attaching the original added/removed mime-message for all mismatching + contacts. If we have no relevant add/del information, don't send a + correction message out. + +- Upong receiving added/removed attachments we don't do the + check_consistency+correction message dance. + This avoids recursion problems and hard-to-reason-about chatter. + +Notes: + +- mechanism works for both encrypted and unencrypted add/del messages + +- we already have a "mime_headers" column in the DB for each incoming message. + We could extend it to also include the payload and store mime unconditionally + for member-added/removed messages. + +- multiple member-added/removed messages can be attached in a single + correction message + +- it is minimal on the number of overall messages to reach group consistency + (best-case: no extra messages, the ABCD case above: max two extra messages) + +- somewhat backward compatible: older clients will probably ignore + messages which are signed by someone who is not the outer From-address. + +- the correction-protocol also helps with dropped messages. If a member + did not see a member-added/removed message, the next member add/removed + message in the group will likely heal group consistency for this member. + +- we can quite easily extend the mechanism to also provide the group-avatar or + other meta-information. + +Discussions of variants +++++++++++++++++++++++++ + +- instead of acting on MemberAdded/Removed message we could send + corrections for any received message that addresses inconsistent group members but + a) this would delay group-membership healing + b) could lead to a lot of members sending corrections + +- instead of broadcasting correction messages we could only send it to + the sender of the inconsistent member-added/removed message. + A receiver of such a correction message would then need to forward + the message to the members it thinks also have an inconsistent view. + This sounds complicated and error-prone. Concretely, if Alice + receives Bob's "Member-added: Doris" message, then Alice + broadcasting the correction message with "Member-added: Carol" + would reach all four members, healing group consistency in one step. + If Bob meanwhile receives Alice's "Member-Added: Carol" message, + Bob would broadcast a correction message to all four members as well. + (Imagine a situation where Alice/Bob added Carol/Doris + while both being in an offline or bad-connection situation). + + +solution2: repeat member-added/removed messages +--------------------------------------------------- + +Introduce a new Chat-Group-Member-Changed header and deprecate Chat-Group-Member-Added/Removed +but keep sending out the old headers until the new protocol is sufficiently deployed. + +The new Chat-Group-Member-Changed header contains a Time-to-Live number (TTL) +which controls repetition of the signed "add/del e-mail address" payload. + +Example:: + + Chat-Group-Member-Changed: TTL add "somedisplayname" someone@example.org + owEBYQGe/pANAwACAY47A6J5t3LWAcsxYgBeTQypYWRkICJzb21lZGlzcGxheW5h + bWUiIHNvbWVvbmVAZXhhbXBsZS5vcmcgCokBHAQAAQIABgUCXk0MqQAKCRCOOwOi + ebdy1hfRB/wJ74tgFQulicthcv9n+ZsqzwOtBKMEVIHqJCzzDB/Hg/2z8ogYoZNR + iUKKrv3Y1XuFvdKyOC+wC/unXAWKFHYzY6Tv6qDp6r+amt+ad+8Z02q53h9E55IP + FUBdq2rbS8hLGjQB+mVRowYrUACrOqGgNbXMZjQfuV7fSc7y813OsCQgi3tjstup + b+uduVzxCp3PChGhcZPs3iOGCnQvSB8VAaLGMWE2d7nTo/yMQ0Jx69x5qwfXogTk + mTt5rOJyrosbtf09TMKFzGgtqBcEqHLp3+mQpZQ+WHUKAbsRa8Jc9DOUOSKJ8SNM + clKdskprY+4LY0EBwLD3SQ7dPkTITCRD + =P6GG + +TTL is set to "2" on an initial Chat-Group-Member-Changed add/del message. +Receivers will apply the add/del change to the group-membership, +decrease the TTL by 1, and if TTL>0 re-sent the header. + +The "add|del e-mail address" payload is pgp-signed and repeated verbatim. +This allows to propagate, in a cryptographically secured way, +who added a member. This is particularly important for allowing +to show in verified groups who added a member (planned). + +Disadvantage to solution 1: + +- requires to specify encoding and precise rules for what/how is signed. + +- causes O(N^2) extra messages + +- Not easily extendable for other things (without introducing a new + header / encoding) + +