Test getting added to the group after the first epoch, but still getting access to all the epochs

[Powersource]

Gonna have to add the old key to add-member or the epoch init for this i think

[Powersource]

Relevant discussion in ssbc/private-group-spec#16

[Powersource]

should do this simpler case first #86

[Powersource]

discussing this with @mixmix tomorrow

[Powersource]

We came up with a pretty good solution (option 4). Here's the full meeting notes:

---

Adding people later than the first epoch but still giving them access to the older epochs

Problem

I add Zach to a group, and there have been multiple epochs.
They need to know about them all and be able to decrypt

Requirements

1. minimise messages
2. minimise complexity
3. still be able to audit "who has which keys"

Solutions

1. Add the person with 1 add-member message per epoch

1. NO LOTS of messages
2. YES
3. YES

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

2. One add-member but the user can recursively discover everything

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.

1. Yes, only 1 new. Only extra data in epoch inits
2. Maybe more complicated to look up memberships for old epochs
3. The new user will in theory have access to all the secrets, they're gonna have to look around for them a bit more though

Problem:

• this doesn't guarentee they will get them all

  • solution: to all previous + all other known tips
  • solution: in add-member, include secrets to all known tips

• 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)

• initial replication of the group becomes slower

3. Invite has EVERYTHING

{
  type: 'group/add-member'
  root: MsgId,
  creator: FeedId,
  secrets: [Secret, ........],
  tangles: {
    group: { root, previous },
    members: { root, previous }
  },
  recps: [GroupId, FeedId]
}

How do I find out if e.g. jacob has all the keys needed?

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

4. Invite has EVERYTHING (for it's causal predecesors)

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:

• do we want to be able to distiguish between the sort of addition
  • type 1: an addition which is migrating people to new epoch
    • one new secret, many feedId recps
  • type 2: an addition of a brand new person to the group
    • many new secrets, ... one or two feedId recps
  • type 3: patching missing keys
    • e.g. jacob is missing some keys... I send him them.

BONUS!:

• we don't leak info about new members to previously excluded members