Add 'HYBRID GROUPS DRAFT'
parent
f32a678c38
commit
fd513344c9
|
@ -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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
Loading…
Reference in New Issue