Add 'HYBRID GROUPS DRAFT'

HYBRID-GROUPS-DRAFT.md

@@ -0,0 +1,148 @@
+# Hybrid Groups
+
+
+# It all starts with the Root
+
+All groups start with a single message. We refer to this message as the "root" of the group.
+
+The root contains:
+
+* The Membership List of profiles who are considered members of the group.
+* The Access Control List (ACL) that determines who can post to the group (among other actions).
+* The Topology of the group.
+
+The root is signed by the group creator. A group can only have a single creator, but the creator can designate
+additional administrators within the ACL.
+
+## Message Structure and Distribution
+
+All additional messages to the group have the following structure:
+
+    struct GroupMessage {
+        Parents: Vec<Signature>
+        Contents: Vec<u8>
+        Author: PublicKey
+    }
+
+    struct SignedGroupMessage {
+            Message: GroupMessage
+            Signature: []byte // Sig(GroupMessage, senders public key) 
+    }
+
+
+* Every message to the group *must* be signed by the author of the message.
+* Every message to the group **must** reference one-or-more previous messages **received from the group**.
+* Each author **must** only reference a parent message once.
+
+
+### Rules for Constructing the Tree
+
+When a group member receives a message that references a parent message that they have not seen before, that member
+can request that message from other group members.
+
+If a group member is in possession of more than one message from another group member that references an intersecting
+set of parents, then the other group member **must** be considered to be acting maliciously. All previous messages received
+from the malicious group member **must** marked as malicious, and **must not** be considered for future reference - except the set of messages that uncovered the fraud, which are distributed as Fraud Proofs to presumed-honest group members.
+
+
+## Topology
+
+Messages distribution is governed by the Topology of the group. Depending on their needs and preferences, groups can be designated to be peer-to-peer only, rely on trusted forwarding bots, or rely on untrusted cwtch server infrastructure.
+
+## Encryption
+
+All group messages are encrypted prior to transport. The structure of an encrypted group message is the same as
+the v1 group structure, with the exception of the signed value
+
+    // EncryptedGroupMessage provides an encapsulation of the encrypted group message stored on the server
+    type EncryptedGroupMessage struct {
+        Ciphertext []byte // Encryption of GroupMessage
+        Signature  []byte // Signature from Signed Group Message
+    }
+
+Verification remains similar to the current scheme:
+
+* Attempt decryption of `Ciphertext` with `GroupKey`
+* If successful:
+    * Verify signature over `GroupMessage` against `GroupMessage.Author`
+    * If successful:
+        * Return `SignedGroupMessage` consisting of the `Signature` from `EncryptedGroupMessage` with the decrypted `GroupMessage`
+    * Otherwise, return an error
+* Otherwise, return an error    
+
+## Conflicts
+
+If a member violates the protocol by sending multiple messages confirming the same parent more than once then that 
+member is assumed malicious, and their confirmation chain is marked as invalid.
+
+If a member references a parent signature but is unwilling to provide the GroupMessage that resulted in it,
+that member should be assumed to be malicious. Note: that a member that references a fake message will not have their
+messages included in the timeline until they present proof of such a message - as such referencing a fake message has
+minimal impact assuming that such messages are pruned from the tree-crdt occasionally.
+
+
+
+## Key Rotation
+
+Rotation are accomplished when an authorized sender sends a `KeyRotationMessage` to the group, and a quorum of members
+confirm the receipt of the message indirectly via inclusion of the parent within the tree-crdt.
+
+Once a member receives enough confirmations, they will rotate their key and begin encrypting new messages with the new
+key - while testing existing messages against the older key. As soon as all members have sent a message using the 
+new key, the old key is purged.
+
+Note: The above allows each member to identify the exact state of any other members timeline and keyring. This is a useful
+meta-protocol when managing the security of groups.
+
+
+## Tree-CRDT
+
+Messages contain a reference to their parent node to aid in tree reconstruction.
+
+When a profile receives a message containing a reference to an unknown parent, they attempt to download the
+parent message from online contacts.
+
+As such the conversation tree can be reassembled from parts.
+
+There are no conflicts, parents can have multiple children, and these will be accessible via the UI
+
+## Access Control List (ACL)
+
+The rules for which messages are accepted into the Tree-CRDT are governed by the ACL which is defined on group
+creation and be refined through messages published to the Tree-CRDT.
+
+### Maintaining Consistency
+
+Requires acknowledgements to be published to the CRDT before a change goes into effect?
+
+## Topology
+
+How messages are fetched for the CRDT is governed by the overlay protocol for the group. The overlay protocol
+can be:
+
+* Equal - all nodes are considered equally valid to fetch new messages from.
+* Unequal - certain nodes are given priority e.g. an untrusted cwtch server or an always online-bot are given priority
+when sharing new messages, or when downloading previous messages.
+  
+# Consistency 
+
+## of the ACL
+
+Changes need to be acknowledged by a quorum before going to effect.
+
+## of the Message Database
+
+Conflicts are not possible, parents can have multiple children. Children can reference multiple
+parents to include an acknowledgement of both parts.
+
+For the vast majority of applications relevant to Cwtch, exact consensus is not necessary, and most can be resolved
+via higher level protocols operating on a message tree itself.
+
+
+
+
+
+  
+
+
+