I’ve read through the multireader tutorial, but I’m having trouble understanding whether or not I can specify which files in app storage I’m sharing.
Let’s say I have private.json and shared.json. Is there currently a way to only share data in shared.json?
You can share any file you want with putFile(). You just need to specify whether or not to encrypt it in the options object.
The app developer is going to largely control this but should make it obvious to the user. In the example of Documents in Graphite, every document you create is yours and yours alone. When you share a file, it’s actually create a copied version of that and sharing that file. At some point, with the help of something like automerge that document might actually live in two different places, but the user will always know they’ve shared the file.
I approach it as everything is not shared by default and only shared by choice (except in the case of Conversations).
I’m not sure if that’s what you’re asking exactly, though.
Yes, like Jude said, you can choose which files to share by encrypting or not encrypting them.
@jude and @yukan – I understand what you’re both getting at now.
I should have reframed my question as “Is there currently a way to only share data in shared.json with known and trusted parties?”
The answer to that question is more nuanced, and as @jehunter5811 was nice enough to show me, involves storing the trusted individual’s public key and encrypting a public file with that.
This sounds like a good thing to add to the storage API docs. Can you open an issue on blockstack.js for it? Thanks!
Absolutely – thanks!
Yes, I’d love to have better support for this in blockstack.js — basically, something like this:
putFile('shared.json', {encrypted: [chase.id, jude.id, yknl.id]})
Which would:
chase.id, jude.id and yknl.id
The way that our encrypt functions are implemented makes Step 2 not too difficult to do, but it would require a bit of work.
Step 1 would need a little more work – basically, the app public key would need to be listed in the apps section of a user’s profile.json (or something along those lines). This could be added at app login, the same way that multi-player storage works now.
Oh that’s really interesting. This might warrant a separate set of API methods to manage permissions. The list of ids could potentially be fairly large (i.e. if I have 1000 facebook friends, I’m passing around a 1000 item array everytime I need to write a file.) Managing permissions on specific storage endpoints should probably also be able to happen as a separate request.
So you may be able to create the file with:
putFile('shared.json', data, {encrypted: [chase.id, jude.id, yknl.id]})
But update who can view it with:
updateFilePermissions('shared.json, [chase.id, jude.id, yknl.id])
Or perhaps more future proof:
updateFilePermissions('shared.json, [
{ 'chase.id': 'some chmod style permissions string or an object of configurable bool vals' }
}
I was trying to figure out this problem today and happened to stumble across this thread. Has there been any further discussion about the topic elsewhere? I have some questions and thoughts either way!
putFile('shared.json', {encrypted: [chase.id, jude.id, yknl.id]})
At first glance it seems like a method like this would end up creating multiple copies of the same file, one for each of the users. Am I missing something here?
Also, to encrypt the data for a specific user, it was mentioned that it would use a user’s ‘app-specific public-key’, I think the best approach would allow for a user to share data with someone who hasn’t yet signed into that specific application.
I have some (really rough) ideas for solving this problem in two parts:
Features:
This solution still however gets back to the question of, “How can we share keys to encrypt/decrypt data?”
I am unsure if the following makes sense, is safe, or is plausible:
A completely unencrypted file
brandonparee.id
{
permissionId: randomId,
publicKey,
privateKey
}
chase.id
{
permissionId: randomId,
publicKey,
privateKey
}
What the public file looks like
JUNK
JUNK
What the file looks like unencrypted to chase.id
STILL JUNK
chase.id
{
permissionId,
publicKey,
privateKey
}
Features:
putFile?getFile?getFile is used it will check through permissions granted by the owner of the file for a matching permissionIdThere is a bunch of little details missing, but hopefully its enough to start a conversation!
@aaron Where can I follow the progress of this code? It’s an awesome feature I really need for my dapp! I noticed a feature in github for sign-validate support? Is this the correct code to look at?
After I wrote a doc in the Graphite ,Where is the directory the doc would be stored?
I made a proof of concept which could be helpful here Anonymous, Secure FileDrop Proof of Concept using BlockStack
hi,I am a new player, I have a problem, Although you can share any file you want with whether or not to encrypt,but how to control who acess to your data,please teach me
@jehunter5811 how is a user with whom you share the file, notified that they have a new shared file? I understand that this could be accomplished using the inbox feature that is in the works. But how is this accomplished for graphite at the moment?
It’s not solved for as of yet. Rather than wait on the inbox feature, the plan is to introduce simple polling of the user’s contacts via a web worker. This would ensure that the polling doesn’t interrupt the user’s experience but when it did return a new message, a notification could be fired.