Require the first recp to always be a groupId

[Powersource]

For most messages this'd mean that we'd disallow a feedId being the first entry in the recps array, i.e. every ID in recps being a feed id. In the init message which doesn't have an explicit recps array, this still applies in spirit since the recipient code currently looks like

      const recipientKeys = [
        { key: groupKey.toBuffer(), scheme: keySchemes.private_group },
      ]

      ssb.db.create(
        {
          content,
          recps: recipientKeys,
          encryptionFormat: 'box2',
        },

I'm suggesting this as a modification to the Direct Messages spec https://github.com/ssbc/private-group-spec/tree/master/direct-messages to make this standard simpler. My hunch so far is that the DM spec introduces a lot of edge cases. We could make the spec more open in the future, but I don't see the harm in being more strict at least initially.

[Powersource]

@arj03 @mixmix @staltz

[staltz]

Require the first recp to always be a groupId

I thought this was already enforced somewhere? In ssb-box2 maybe.

In any case, I'm favorable of this. But Mix is the person for all things private-group-spec.

[Powersource]

I thought this was already enforced somewhere? In ssb-box2 maybe.

Idk but this spec doesn't disallow it to be a feedId

[Powersource]

@mixmix

[mixmix]

The rule i have set up and follow is

• there may be a maximum of one groupId in the recps and
• if there is any group id it must be in the first slot

I don't understand what your problem/ issue is from what you've written here?

[Powersource]

One example of a problem:

If the first slot always is a groupid then I can always get recps[0] to get the group's ID. Currently you might have to add checks for that. A lazy convenient programmer might then opt to use the root msg id as the group identifier instead, since you can always find that at tangles.group.root. But then we lose the benefits of having the ssb:identity/group/key uris in the first place.

[Powersource]

@mixmix

[Powersource]

@mixmix boop

[mixmix]

what do you do with the first slot if you have no groupId then? e.g. in case of DM or PO Box?

[mixmix]

cc @Powersource

[Powersource]

@mixmix All the cases we've talked about so far I think that are DMs are either adding a new member or sending a member a new key. In both of those cases we have a group id. PO boxes are also not a thing yet in v2.

[mixmix]

PO Box is the mechanism by which we will do "request to join group"

I don't personally think this is a worthwhile optimisation. You will just create problems elsewhere if / when we use DMs standalone ever, or use PO Box (which we know we want for Ahau at least, and probably generally), then what do you do with the first slot? Leave it empty? You can't the slot will have to have 32bytes of junk in it, which you will then be forced to try and decrypt maybe?

It's very easy to go check the type of recps with new ssb-uri formats isn't it?

recp.startsWith('ssb:identity/group'') // or something

I'm a :x: "No, I don't think this is the right way to go" for the moment. It creates more problems than it solves IMO

[Powersource]

when we use DMs standalone ever

I just don't see this happening I guess, and feels weird to leave implied support for it in the spec when tribes2 doesn't really support it. But I'm fine with not discussing this more.