Closed Powersource closed 1 year ago
Relevant discussion in https://github.com/ssbc/private-group-spec/issues/16
should do this simpler case first https://github.com/ssbc/ssb-tribes2/issues/86
discussing this with @mixmix tomorrow
We came up with a pretty good solution (option 4). Here's the full meeting notes:
I add Zach to a group, and there have been multiple epochs. They need to know about them all and be able to decrypt
NOOOO: if we publish a group/add-member in epoch zero to add arj, then anyone who was excluded would be receiving new info about who was being added to the group
Only add the person to the latest epoch. But every epoch init should contain the secrets of its previous
epochs. This way the new user could iterate backwards to unlock all the epochs.
Problem:
this doesn't guarentee they will get them all
what do you do if you discover new epochs for that person later?
A(mix,jacob,staltz,oscar)
| |
mix drops Oscar jacob drops Oscar
| |
B(mix,jacob,staltz) C(mix,jacob,staltz)
A(mix,jacob,staltz,oscar,arj)
| |
mix drops Oscar jacob drops Oscar
| |
B(mix,jacob,staltz) C(mix,jacob,staltz)
{
type: 'group/add-member'
root: MsgId,
creator: FeedId,
secrets: [Secret, ........],
tangles: {
group: { root, previous },
members: { root, previous }
},
recps: [GroupId, FeedId]
}
lookup group/add-member
messages for the groupId
filter the ones that have FeedId === 'jacob' in the the recps
collect all the secrets, map them to epochIds...
compare that with the list of all known epochs
if there are two forks (two tips in the epoch tangle), then there would be two additions.
This means if you look at an epoch, it is enough to look in that epochs' members tangle.
If the history has forked, then merged, then there will only be one tip with one massive causal history of predecessors
This packs lots of data into parcels AND preserve the simplicity of the members tangle!
Question:
BONUS!:
Gonna have to add the old key to add-member or the epoch init for this i think