Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP notes #20

Closed
wants to merge 2 commits into from
Closed

WIP notes #20

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
9280754
WIP notes
mixmix Mar 8, 2023
a44015f
Merge branch 'master' into mixmix
mixmix Mar 15, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
75 changes: 51 additions & 24 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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:

Expand Down Expand Up @@ -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:

Expand All @@ -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 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`
mixmix marked this conversation as resolved.
Show resolved Hide resolved

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`
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what I'm confused by

Copy link
Member

@staltz staltz Mar 8, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, "common" is not "intersection". What this definition captures is the set of "remaining" members. If there is a bifurcation in the epochs, we need to go back to the common predecessor, look at its members, and see what those members have to do regarding the bifurcation. They are the ones who witnessed the bifurcation happening, and they have data that helps them decide which fork to select as the most preferred.

The reason this doesn't work as

common(G,H) = members(G) ∩ members(H)

is because common(G,H) = common(H,G) is always true, which means rule 4.4. is always applied. Also common(L,R) ⊂ common(R,L) is never true, which means rule 4.5. is never applied. And common(L,R) △ common(R,L) is always empty, which means rule 4.6. is never applied.

So this means we only have rule 4.4., which says to only use tie-breaking rule to select the preferred epoch. This doesn't work in some cases, see e.g.

graph TB;
  zero[X: a,b,c,d]
  zero--"b excludes d"-->L[L: a,b,c]
  zero--"a excludes c,d"-->R[R: a,b]
Loading

Suppose L is the tie-breaking winner. Then a and b decide to go to L, where c is, but a doesn't want c in the group! Do they have to re-remove c? And who performs that action? a or b? If it's both, then you may end up with forks again.

The case above may seem simple to fix: we just have to make 4.5. be the rule members(L) ⊂ members(R) instead of common(L,R) ⊂ common(R,L), but then we are incorrectly taking into consideration members that were freshly added to either side. Those fresh members kind of don't matter when it comes to choosing forks. We want to know what is the forked epoch that has most excluded members, and jump to that one, but we can only talk about exclusions if we refer to the original (thus the common predecessor) context.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done in another PR

> 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
Expand Down Expand Up @@ -200,16 +206,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`
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if we pin down the tangles right, we can do really tidy quick lookups for the memberships of each epoch

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see this #17

> 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
mixmix marked this conversation as resolved.
Show resolved Hide resolved
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`.
mixmix marked this conversation as resolved.
Show resolved Hide resolved

Said differently, if `H` directly succeeds `G`, then `H` MUST be preferred over
`G`.
Expand Down Expand Up @@ -262,8 +276,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`
mixmix marked this conversation as resolved.
Show resolved Hide resolved
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
mixmix marked this conversation as resolved.
Show resolved Hide resolved
> NEEDS ATTENTION

```mermaid
---
Expand All @@ -289,6 +305,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
Expand Down Expand Up @@ -485,3 +504,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