mentions for secret blobs

[mmckegg]

@dominictarr's secret blobs proposal adds a query string onto the end of a blob ID containing the unbox key. These are not able to be detected by the mentions checker and so never get added to the msg.value.content.mentions array.

This PR fixes it by instead checking to see if the ID starts with a & and then assumes it is a blob. I did it this way because it was the same way @dominictarr did it ssbc/patchcore#50

I'm a little worried that we are veering of the "spec" established by ssb-ref here. Should we just update ssb-ref instead to be able to handle blob unbox in the id?

Thoughts?

cc @mixmix @clehner @ahdinosaur et el

[mmckegg]

@clehner has already started work on this on git-ssb:

https://git.scuttlebot.io/%258%2BwcXeBD0H3Xv%2FoHJfhJ1mU4iryhhrztgdQBP77IRqA%3D.sha256/commits

It's a much better implementation that splits out the unbox= into key.

[mmckegg]

I just updated this PR to bring it in line with what @clehner's PR does, except that it uses an updated version of ssb-ref that knows how to parse secret blob refs.

[dominictarr]

what if we interpret this not as a special case, but rather that ssb objects (msgs, feeds, blobs) can come with parameters that represent "hints" about how that link should be interpreted?

so, maybe it should parse to {name: name, link: link, query: { unbox: ... }} because that will preserve the structure rather than handling the key as a special case. I intend to implement a similar way to pass a id with a key, except for messages (this will be part of the private-groups system) I can also think of other things I could represent as "part of a message" like maybe you could refer to a file within a git blob? or a quote inside a message? i think if we preserve the structure of the query parameters it will stay flexible.

[dominictarr]

btw, I have been working on the ability to share a key to a encrypted message. This makes private messages into a capability system - you can create a private message, then reveal it later, or show it to another person. This is how I plan to implement private groups - create a new private message with the group key, then add more people to it.

auditdrivencrypto/private-box@9849289

(a particular message is the root, because I want it to always be explicit that you are adding someone to a group. it should not be possible to create a group that just happens to have the same key as another group_)

This is related because it points towards needing a generic way to handle the passing a link with a decryption key.

[mmckegg]

@dominictarr

Just saw this now. Yes I like this proposal {name: name, link: link, query: { unbox: ... }}.

Would you like me to update this PR (and ssbc/ssb-ref#15), or are you keen to implement yourself?

[ahdinosaur]

👍 on {name: name, link: link, query: { unbox: ... }}

[mmckegg]

Latest push adds query parsing to all ID mentions. You can now have a %msgId?unbox=somecode&more=things and it will get added as:

mentions: [{ 
  link: '%msgId', 
  query: {
    unbox: 'somecode', 
    more: 'things'
  }
}]

Shall I merge? Depends on ssbc/ssb-ref#16

cc @dominictarr

[mmckegg]

Okay, I'm gonna merge!!