Closed Powersource closed 1 year ago
Powersource
commented
1 year ago Additionally for the "common members" situations, isn't it bad UX to essentially exclude newly added members without informing them, like we do for explicitly excluded members?
staltz
commented
1 year ago Thanks for giving a thoughtful read!
Until we're sure all members are on newer epochs then i think we'll have to keep replicating older epoch feeds and trying old keys?
Yes, and this spec needs to make replication requirements more clear. I made issue #2 for that now
3.1.2. MUST create a new group feed (also known as the "epoch feed") using the epoch key, as described in ssb-meta-feeds-group-spec Section 3.2
Isn't the epoch key the symmetric key we will encrypt the new messages with? We can't make a feed using that.
Can't we? The epoch key is also known as the "group secret", and we make subfeeds by setting the feedpurpose to base64 group secret.
3.1.3. MUST publish a group/init message on the epoch feed, as described in the private-group-spec, with the exception that:
Could we have a new message type for this, since it's quite different from a group init?
Sure, what do you propose?
3.1.3.B. if G is also an epoch of another group, tangles.group.root MUST be the group ID for the first group (which is not an epoch of any other in this chain of epochs), otherwise
I'm confused, how would an epoch end up being a part of 2 groups?
It's not part of two groups, it's this:
flowchart TB
mygroup-->epoch1-->epoch2where
flowchart BT
mygroup
epoch1
epoch2
subgraph epoch2
tangles.group.root
tangles.group.previous
end
tangles.group.root-..->mygroup
tangles.group.previous-.->epoch13.1.5. MUST publish a group/add-member message on their group feed for G, to add remaining group members (this includes A, for recovery purposes) to the epoch, such that the message schema is the same as the one in ssb-meta-feeds-group-spec Section 3.1
I think a new msg type would make sense here since i think the different usages will require different content. Relatedly I've brainstormed about this here previously ssbc/private-group-spec#16
What do you propose?
Concerning replication of group feeds, all remaining group members SHOULD cease to replicate C's group feed for G as soon as the group/exclude message is replicated.
I think this phrasing is problematic since users might have replicated up to different points. I think the goal should be to keep the group tangle whole and fully replicated.
Relates to clarifying #2, but I think this is not about the group tangle, this is just about C's (the excluded member) feed. We are basically saying here that members should ignore new content coming from Oscar, as soon as they know that Oscar was removed.
Remaining group members MAY also cease to replicate every member's group feed for G when group/exclude is replicated, although this can have a negative impact on eventual consistency, because group members may receive the group/exclude message at different times, and in this transition period there may have been useful content published on group feeds for G.
Similarly here, i think users SHOULD replicate all messages in the group tangle (unless they're specifically partially replicating).
Right, yes I think that's correct. Will put it in #2.
fire IS THIS OUR DETERMINISTIC RULE?
SURE
I'd appreciate a bit more bikeshedding on it since lexicographic order can be hacked a bit. Like I could "mine" (i.e. brute force compute) a bunch of different epoch keys until I get one that is super powerful like starting with 0000 that forces all the other forks to lose the game of lexicographic order. Doesn't sound so good.
symmetric difference
What's that?
https://en.wikipedia.org/wiki/Symmetric_difference
I could clarify that these are mathematic set operations.
3.4
This section has to be read slowly haha but I think probably makes sense. Can you clarify though why you went with the "intersection of common members L and R" approach though? Is it to avoid the mess of handling new members? I.e. you assume the fork will be brief and it's ok to failsafe to not including new members?
Yeah I wonder if I can add equations here, it might help reading the text.
Additionally for the "common members" situations, isn't it bad UX to essentially exclude newly added members without informing them, like we do for explicitly excluded members?
Oh, that's a bug in the current spec. Thanks for spotting. I have to add a rule where the newly added member is added to the correct epoch once people move to the correct epoch.
Powersource
commented
1 year ago Can't we? The epoch key is also known as the "group secret", and we make subfeeds by setting the feedpurpose to base64 group secret.
Then everyone would have the same feedId for the new group feed?
3.1.3 Sure, what do you propose?
Maybe group/init-epoch
It's not part of two groups, it's this:
Still a bit confused. I think the usage of the word group is confusing here? You maybe use the words group/epoch interchangeably? But for me we're only talking about epochs here, and they're all part of one big conceptual group.
3.1.5 What do you propose?
Maybe group/epoch-key
I'd appreciate a bit more bikeshedding on it since lexicographic order can be hacked a bit. Like I could "mine" (i.e. brute force compute) a bunch of different epoch keys until I get one that is super powerful like starting with 0000 that forces all the other forks to lose the game of lexicographic order. Doesn't sound so good.
I think we probably can't make it un-gameable, but maybe we could make it harder than simply trivial. Right now as you say, making a key starting with 0000 would make you win basically every time, no matter the keys the others publish. But maybe we could require knowing all the other keys to be able to game it. Pseudocode!
keys = [array of the keys]
keys_hash = hash(keys.join(""))
hash_as_num = Integer(keys_hash)
winning_key = keys[hash_as_num % keys.length]Yeah I wonder if I can add equations here, it might help reading the text.
Maybe, the text is a lot to parse and understand.
I have to add a rule where the newly added member is added to the correct epoch once people move to the correct epoch.
If you want to add them again, why exclude them in the first place?
staltz
commented
1 year ago Then everyone would have the same feedId for the new group feed?
Nope, that's not how feedId derivation works for subfeeds on the tree. Me and you can have the same feedpurpose (just think of it, we all have a subfeed with feedpurpose === 'v1') and yet we all get different feed IDs. You can peek into the code in ssb-meta-feeds to see how that works.
Still a bit confused. I think the usage of the word group is confusing here? You maybe use the words group/epoch interchangeably? But for me we're only talking about epochs here, and they're all part of one big conceptual group.
Yes, and there is some ambiguity about the "epoch zero". Maybe the spec should clarify that. But it's tricky because the ssb-meta-feeds-group-spec doesn't use the word epoch, and we're building on top of the language of that spec.
If you want to add them again, why exclude them in the first place?
Carla is not being excluded at any point. Suppose you create a new epoch to exclude Oscar, and I create a new epoch to exclude Oliver. In the meantime, I added Carla to my epoch. Then I discover your epoch and it's the winning one, so I have to add Carla to your epoch. At no point was she "excluded".
Powersource
commented
1 year ago Nope, that's not how feedId derivation works for subfeeds on the tree. Me and you can have the same feedpurpose (just think of it, we all have a subfeed with feedpurpose === 'v1') and yet we all get different feed IDs. You can peek into the code in ssb-meta-feeds to see how that works.
That's not what I meant, I think we're confusing things. In the spec you wrote
3.1.2. MUST create a new group feed (also known as the "epoch feed") using the epoch key, as described in ssb-meta-feeds-group-spec Section 3.2
I thought you meant that you'd use the epoch key to sign the feed somehow. But I guess you meant to use the epoch key as the feed purpose. So that's probably the confusing part?
Maybe the spec should clarify that.
Would be nice
Carla is not being excluded at any point. Suppose you create a new epoch to exclude Oscar, and I create a new epoch to exclude Oliver. In the meantime, I added Carla to my epoch. Then I discover your epoch and it's the winning one, so I have to add Carla to your epoch. At no point was she "excluded".
Losing track of the conversation and what we're discussing now, maybe I'll wait to check graphs and stuff.
staltz
commented
1 year ago Losing track of the conversation and what we're discussing now, maybe I'll wait to check graphs and stuff.
Yeah, I'll close this issue (but more feedback is totally welcome!) because I created issue #6 for epoch zero, and I just pushed a change for the epoch key as feedpurpose.
Until we're sure all members are on newer epochs then i think we'll have to keep replicating older epoch feeds and trying old keys?
Isn't the epoch key the symmetric key we will encrypt the new messages with? We can't make a feed using that.
Could we have a new message type for this, since it's quite different from a group init?
I'm confused, how would an epoch end up being a part of 2 groups?
I think a new msg type would make sense here since i think the different usages will require different content. Relatedly I've brainstormed about this here previously https://github.com/ssbc/private-group-spec/issues/16
I think this phrasing is problematic since users might have replicated up to different points. I think the goal should be to keep the group tangle whole and fully replicated.
Similarly here, i think users SHOULD replicate all messages in the group tangle (unless they're specifically partially replicating).
SURE
What's that?
This section has to be read slowly haha but I think probably makes sense. Can you clarify though why you went with the "intersection of common members L and R" approach though? Is it to avoid the mess of handling new members? I.e. you assume the fork will be brief and it's ok to failsafe to not including new members?