In add-member, make groupKey an array?

[Powersource]

https://github.com/ssbc/private-group-spec/blob/master/group/add-member/README.md

A group will end up having multiple keys (i guess?) once we add member-removal since that will require key rotation, while we still want new members to be able to read old messages.

[Powersource]

Hmm it doesn't have to be a big array or anything. A new user actually only needs to be sent:

1. The latest key so that they can encrypt new messages to the group
2. The oldest key, so that they can go through the history to
   1. Decrypt old messages
   2. Find old keys to further decrypt old messages

So maybe it doesn't have to be an array, but maybe instead something like rootKey which is the key the root msg was encrypted with, and latestKey which is the key the latest message is decrypted with.

[Powersource]

So maybe simplest, if we want to deploy to prod before we have moderation, is to keep it as it is now and once we have moderation just also add a rootKey where needed.

[Powersource]

Ok getting ahead of things but brainstorming while it's in my head, when removing a member you'd publish 2 kinds of messages

(encrypted with newKey)
{
  type: 'group/remove-member',
  newKey: 'asdfasdf',
  removedMembers: ['@potato', '@squash'],
  recps: [groupId]
}

(encrypted with newKey and the keys of the up to 15 people in the recps)
{
  type: 'group/rotate-key',
  removeMember: (id of remove-member msg),
  newKey: 'asdfasdf',
  recps: [groupId, stillMember1, stillMember2, etc]
}

[Powersource]

Wait hmm giving them the root key only gives them access to the first 'epoch' right. Maybe giving them the current and the previous key though, since that'd let you go back one 'epoch' at a time, until you get to the root message.

[mixmix]

You can't go "backwards" through epochs... I think it's best to either:

• include all the group_keys
• only include the first

We're gonna have an interesting thing with removal where we will need to be able to answer the question "who has which keys?" and get them the ones they are missing.

I'm in favour of starting out simple

[Powersource]

only include the first

doesn't work if you want to show the user the whole history. better to give them the previous key, then they can iterate backwards and finally get to the root key

[mixmix]

What do you mean? They can take the first, then replicate in order re-living the group history including invites and removals. I think doing something fancier is going to generate more edge cases and I'm scared we've got enough of those. Replicating records backwards means you will end up with some records that miss their root and you'll have a weird group?

TL;DR :heavy_check_mark: I'm fine with you making it an array :x: I am not fine with putting more than the first groupKey in there (for the moment)

Open to looping back

[Powersource]

They can take the first, then replicate in order re-living the group history including invites and removals.

No they can't though? At least if they're a new member. It'll be equal to being added as a member to the initial epoch but being excluded from the second. Where would they get the keys to the epochs that aren't the first and the current?