From 850f3ecbf3437ab48ed008da1c3550535a0f3708 Mon Sep 17 00:00:00 2001 From: mix irving Date: Wed, 8 Mar 2023 17:32:41 +1300 Subject: [PATCH] WIP notes --- README.md | 76 +++++++++++++++++++++++++++++++++++++------------------ 1 file changed, 52 insertions(+), 24 deletions(-) diff --git a/README.md b/README.md index 5742e46..ba1cb89 100644 --- a/README.md +++ b/README.md @@ -20,7 +20,7 @@ In this document, we describe how SSB private groups can create the illusion of group member removal by cycling the symmetric keys in "epochs", thus effectively excluding a peer from participation in the new epochs. We also address how to resolve various cases of diverging epochs, such that group members follow rules -that arrive to consensus on which epoch must new content be published on. +that arrive to consensus on which epoch new content must be published on. ## 1. Introduction @@ -69,11 +69,11 @@ reader. Private group and membership: * A set of SSB peers that possess the same [envelope-spec] symmetric encryption -key (called "group key") is called a "private group". Each peer in a group is -called a "group member" or "member". The "declared members" of a group is -the set of SSB peers who received the group key via `group/add-member` messages. -We also denote the declared members of a group `G` as the mathematical set -`members(G)`. +key (called "group key") is called a "private group" or just "group". Each peer +in a group is called a "group member" or "member". The "declared members" of a +group is the set of SSB peers who received the group key via `group/add-member` +messages. We also denote the declared members of a group `G` as the mathematical +set `members(G)`. Epoch: @@ -107,10 +107,9 @@ other, and both of them are not succeeded by any epoch, we call this situation Common predecessors: * A "common predecessor" of two epochs `G` and `H` is any epoch `X` that -precedes (or is equal to) `G` and `H`. The "nearest common predecessor" `X` of -epochs `G` and `H` is the only common predecessor of `G` and `H` such that no -other common predecessor `Y` (of `G` and `H`) succeeds `X`. We also denote it -as `X = nearest(G, H)`. +precedes `G` and `H`. The "nearest common predecessor" `X` of epochs `G` and `H` +is the only common predecessor of `G` and `H` such that no other common predecessor +`Y` (of `G` and `H`) succeeds `X`. We also denote it as `X = nearest(G, H)`. Common members: @@ -123,18 +122,25 @@ Some mathematical set relations will be useful throughout this specification. We shall denote: * The equivalence of two sets `A` and `B` as `A = B` -* The intersection as `A ∩ B` -* The union as `A ∪ B` -* The set difference as `A \ B` -* The symmetric difference as `A △ B` -* The subset relation as `A ⊆ B` -* The proper subset relation as `A ⊂ B` +* The [subset] relation as `A ⊆ B` ("A is a subset of B") +* The [proper subset] relation as `A ⊂ B` ("A is a subset of B, AND not A is not B") +* The [intersection] as `A ∩ B` +* The [union] as `A ∪ B` +* The [set difference] as `A \ B` +* The [symmetric difference] as `A △ B` -For instance, the common members of `G` with respect to `H` can be denoted as: +An important definition is the common members of `G` with respect to `H` denoted as: ``` common(G,H) = members(G) ∩ members(nearest(G,H)) ``` +> TODO - this definition doesn't take into account additions between `common(G, H)` and `H` +> I think my problem might be that you don't mean "common members" i.e. the intersection... +> you're defining something else like "members from `nearest(G,H)` that made it to `G`" +> Why can't we just use? +> ``` +> common(G,H) = members(G) ∩ members(H) +> ``` ## 4. Functional Specification @@ -184,6 +190,7 @@ Section 3.2.2. * 4.1.3. `a` MUST publish a `group/init` message on `Ha`, as described in the [private-group-spec], with the exception that: * 4.1.3.A. the `tangles.group.previous` field MUST be epoch `G`'s ID, and +> - TODO what's the ID? is it the previous `group/init` message id, or a cloakedId, or ...? * 4.1.3.B. if `G` is not epoch zero, then `tangles.group.root` MUST be the group ID for epoch zero, otherwise * 4.1.3.C. if `G` is epoch zero, `tangles.group.root` MUST be `null` @@ -204,16 +211,24 @@ Section 3.1 with the following exceptions: MUST publish on `Ga` a sequence of `group/add-members` messages according to [ssb-meta-feeds-group-spec] Section 3.1, such that the union of all recipients in that sequence equals all remaining members - -It is RECOMMENDED that epoch `G` is the "most preferred epoch" among all the -epochs that `a` is a member of, which succeed a certain epoch zero. +> - TODO what is the `tangles.group` + `tangles.member` for these `group/add-member` +> messages. I think it should be +> - `tangles.group`: +> - root: the epoch zero group/init message id +> - previous: latest message +> - `tangles.member`: +> - root: the group H group/init message id !? +> - previous: the previous `group/add-member` message for group H (if it exists) + +It is RECOMMENDED that epoch `H` is the "most preferred epoch" among all the +groups epochs that `a` is a member of. ### 4.2. Preferring the next epoch -When a member `a` of an epoch `G` replicates and decrypts a `group/add-member` -message that adds `a` to the new epoch `H` (in other words, `a` "detected the -existence" of `H`), then `a` MUST select epoch `H` as "preferred" over `G`. +When a member `b` of an epoch `G` replicates and decrypts a `group/add-member` +message that adds them to the new epoch `H` (in other words, `b` "detected the +existence" of `H`), then `b` MUST select epoch `H` as "preferred" over `G`. Said differently, if `H` directly succeeds `G`, then `H` MUST be preferred over `G`. @@ -266,8 +281,10 @@ graph TB; R-. a,b,c prefer L .->L ``` -If a member `b` in `R` adds a new member `e` to `R`, then `b` MUST add `e` +If a member `b` in `R` adds a new member `e` to `R`, then when `b` MUST add `e` to `L` as soon as `b` detects the existence of `L` (figure 3). +> WARNING - this is technically 4.5 now - a subset membership T_T +> NEEDS ATTENTION ```mermaid --- @@ -293,6 +310,9 @@ Suppose there are two forked epochs `L` and `R`. If `common(L,R) ⊂ common(R,L then all peers in `common(L,R)` who detect the existence of both `L` and `R` MUST select `L` as the preferred epoch over `R`. See figure 4. +> TODO need to reveiw the definition of `common` to be able to proceed +> <<< WIP HERE >>> + ```mermaid --- title: Figure 4 @@ -489,3 +509,11 @@ e.g. publish-timing analysis to extract timezones, etc. [perfect-forward-secrecy]: https://en.wikipedia.org/wiki/Forward_secrecy [post-compromise-security]: https://ieeexplore.ieee.org/document/7536374 [ssb-uri-spec]: https://github.com/ssbc/ssb-uri-spec + + +[subset]: https://en.wikipedia.org/wiki/Subset +[proper subset]: https://en.wikipedia.org/wiki/Subset +[union]: https://en.wikipedia.org/wiki/Union_(set_theory) +[intersection]: https://en.wikipedia.org/wiki/Intersection_(set_theory) +[set difference]: https://en.wikipedia.org/wiki/Complement_(set_theory)#Relative_complement +[symmetric difference]: https://en.wikipedia.org/wiki/Symmetric_difference