oh btw, we have all the code for encrypted files, which can be shared in private messages, we just need to add support to the front ends. checkout %ssb-secret-blob and everyone is now on the %ssb-blobs that supports pushing a blob to a pub. we basically just need to agree on a format for including a decryption key in a blob link. (i suggest &{hash}#{key} because it's analogous to how browsers do not send the hash fragment of the url to the server) and then implementing support for decrypting a blob in the clients.

@dominic
using "#" as the blob hash/key delimiter conflicts with linking to an html blob with a link anchor, or to a web app blob that uses location.hash for routing. although i don't know if such links work in all clients currently, they could be useful in the future. how about "~" instead?

@cel deciding what format to use for secret blob keys is the step that secret blobs have stalled on.

My reasoning for # is that it already has the right behaviour - the data after # in a url is not sent to the server, and it's also a comment in the shell. It would be important not to send the key to the server.

We are using ~ as a separator in multiserver already.

What about if the key is just attaches as a query string? (blob#key=<decryption_key>) then it will leave room for applications to do all that other stuff too!

Also, in the liteclient, # can be stacked, for example: domain.com#secure_url#invitecode#welcome_message first it loads bootstrapping code from domain then javascript from secure_url the applies the invite code, then opens the welcome_message. Each thing to the left is responsible for interpreting the rest of the string. so you could have patchbay#markdown#blob_id#key which would tell patchbay to open markdown sub-app which then would request that blob and decrypt it.

or both of these ideas?

how can this work in a plain html web client (e.g. patchfoo, go-ssb webui currently), where blobs are served by a local web server? <img src="/&{hash}#key={key}"> won't work, because the browser will try to render the ciphertext. in a browser app you could do the decryption in the client, build an HTML5 blob and use a blob: URL in the img tag, but without client-side JS, the web server has to send the plaintext in response to the request for the img src. this means the key has to be included in the request url, or retrieved by the server via some indirection mechanism.

@cel that is right. They'd need to at least run some javascript to do the decryption. It's not a big deal if a local server sees the keys, but I don't want a pub seeing that.

normally, the encryption means that a pub does never see it! but if the encoding of the secret in a url causes a browser to send it to another pub, then you have just unintentionally leaked a private secret.

so if i find a link like this in markdown in a post:
[cool thing](&6lF87HG0l6vGnto3M7/mTNFShOFmp/zAH05Ett1+eqk=.sha256#47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=)

how can i know if it is a link to an encrypted blob, or to a page in a hash-routed html5 web app?

@ezdiy how about this?

{
  "link":"&b10bb10bb10bb10bb10bb10bb10bb10bb10bb10bb10bb10bb10bb10bb10bb10b.sha256",
  "key":"dec0dedec0de",
  "size": size of ciphertext in bytes
}

i would include the key in the markdown. the link in the markdown source should identify the blob hash and key and other parameters if needed, so that a user can copy-paste it into a new message and it will still work. i would be okay with considering a key property with base64-encoded 32 byte value to indicate the encryption algorithm to be pull-box-stream, as used in ssb-secret-blob and ssb-git-repo and scuttlebot's rpc. additional encryption algorithms or filters could be added later

hmm, so we stuck extentions on hashes and keys and signatures, but we didn't really have a rationale for how they would be used, just thinking - this will be important one day, when we need to add more algorithms.

maybe it should be <blob_id>#<key>.boxkey? or if we take a acme plummer like approach, we can easily fallback to a more well defined system in the future.

@vendan one day I'd like to understand what javascript did to hurt you so much