mirror of
https://github.com/chatmail/core.git
synced 2026-04-06 07:32:12 +03:00
127 lines
5.3 KiB
ReStructuredText
127 lines
5.3 KiB
ReStructuredText
|
|
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)
|
|
|
|
|