add blobId as an attachment to shard

[m4gpi]

Adds capacity to attach a file / blob reference to a shard message. Needed by Patchwork Integration - Phase 1: ssbc/patchwork#952

[m4gpi]

Am yet to figure out if we can specify different possibly references here. e.g. at this point, content.attachment.reference can only be a blobId. While this is fine for the moment, would be more extensible / open ended to make it so that it could be one of multiple options. Not sure how to do this with JSON schema.

[m4gpi]

@ameba23 thought more about this, if we pass an attachment and give it a name, this reveals something about the shard to the custodian. So this raises a security question: if the name gossip.json labels the attachment, the custodian can pretty easily work out that this is an SSB identity shard.

For the sake of the Patchwork integration, it would be useful, as it would allow the interface to only render shards that are relevant to their SSB identity. We've got a trade-off here between security and usability.

[dan-mi-sun]

@KGibb8 thinking outside the box here is it possible to slice up the gossip.json, encrypt the slices, and reconfigure on the other end with a recomposition script?

[ameba23]

@KGibb8 this is indeed gonna be a problem, but i think it's a problem we will have to live with if we want patchwork to only display shards relating to ssb keys. and its not that big a problem!?

i would like to propose that we make a generalised solution for handling bigger secrets, and add anything specific to gossip.json files or patchwork intergration on top. but this is just my opinion.

@dan-mi-sun do you wanna explain how this idea helps us? is the idea to obfuscate the size of the gossip.json file?

[m4gpi]

If we choose to do this, it kind of undoes a lot of the work we did obfuscating the name, label, etc. Personally, if this is to be a genuinely usable feature, not just in Patchwork but for others circumstances where we're dealing with multiple backups, I feel like this kind of compromise is going to be necessary, but I'm not sure I like this trade-off... that said, the exposure is only to the shard holder, and within the context of encrypted blobs and the distribution of shares amongst unknown peers, it feels acceptable?

@ameba23 agreed on the generalised solution for bigger secrets. That was why I made it so you can just attach a blobId, the blob could be anything, it could be your GPG key, a revocation certificate, etc. What did you have in mind?

[ameba23]

@KGibb8

the exposure is only to the shard holder, and within the context of encrypted blobs and the distribution of shares amongst unknown peers, it feels acceptable?

agreed, i think its acceptable

What did you have in mind?

nothing different to what you're suggesting, i think we are on the same page. as i think i mentioned elsewhere, ideally id like if the share method handled everything, as in it notices the secret you gave it is to big and creates a blob for you. but it might start getting a bit bloated.

[ameba23]

@KGibb8 so this commit makes the attachment property be an object with properties 'name' and 'blobId'. is this what you were imagining?

i'm gonna wait for the thumbs up from you before making changes to the schema in this PR.

[m4gpi]

Unified into single branch, see #22