From d1a26e66a7138b67fb74058f70a703438597dd7d Mon Sep 17 00:00:00 2001 From: holger krekel Date: Wed, 19 Feb 2020 13:48:05 +0100 Subject: [PATCH] update --- draft/group-sync.rst | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/draft/group-sync.rst b/draft/group-sync.rst index c43de2ae0..968272667 100644 --- a/draft/group-sync.rst +++ b/draft/group-sync.rst @@ -16,9 +16,13 @@ the new members will miss each other's additions, example: 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 @@ -29,8 +33,8 @@ solution: memorize+attach (possible encrypted) chat-meta mime messages 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. + check_consistency+correction message dance. + This avoids recursion problems and hard-to-reason-about chatter. Notes: