I wanted to have your opinion about this structure:
A random key is generated for every file and encrypt them with AES256
Every file will be sent to a new random hub as signed
The private key of the hub is stored in the user hub encrypted with user hub public key for later use
The private key to the random hub will be sent to the server
So the server can move the file from a hub to another one and give it to another user. This is for the reason that not every user needed to download and then upload it again.
Now each user has control over their copy so they can delete it independently, update to a new version with another encryption key and so on.
In this system, the only thing server can do move or delete the files, just like the storage provider. It cants read the file content or index them.
Do you think it is a good practice? Do you think is there any other way to not force the user to reupload every file on the share?
It’s hard for me to understand what you’re asking. Users tell the app which hub to use – the point of having hubs at all is that users will instruct apps to store their data to their preferred hub. If the user wants the hub to replicate their files beyond writing them to a particular back-end, then the hub itself is responsible for implementing the replication strategy. The user opts into whatever the hub’s replication strategy is by virtue of selecting the hub to host their data.
That said, it’s hard to understand why or how someone would go about selecting different hubs at random. Why is this desirable? How do you enumerate the set of hubs? Why should other peoples’ hubs store your data? Why should other peoples’ hubs even listen to your delete commands? Hubs are not a fungible commodity service.
It seems I didn’t clarify enough; please let me try again.
I want to give users the ability to share files. Eighter, the app can provide a share link of the file, and the user can download and reupload it again to his hub or ask the server to do this for him.
The reason is I want to give each user a separate copy so they can have full control on that, for example in case one wants to delete the file or update it without sharing back.
So for this, I thought about such structure that:
User A, encrypt a file with AES and upload it to a new hub (and not the personal hub). She will save the AES key as encrypted with ECIES in her personal hub.
User A sends a share link (containing the address and the AES key) to User B. B can get the file, and re-encrypt and upload it again. But it is not very practical and optimized, especially if the file is big or he is using a mobile phone.
So I propose the server S that, User B make a new hub for the file and send the private key to that hub to the S along with the address of the file he got from A.
So S can copy the file from A’s hub and copy it to B new hub as fast as possible.
B now has a new copy of the file and with the AES key.
S has only access to delete the file, and we can impose that S will not do that as it does not know the content of the file.
It even opens the way to implement auto-expire time and such.
Please keep in mind that I don’t want to make a custom Gaia to do such jobs as it will divide versions of Gaia and future providers that who support what.
I share some of the confusion that @jude had. Are you trying to implement similar functionality to dropbox’s “Add to my dropbox” where a user A views a file that user B shares and then decides she wants to have her own copy of this file in her own hub? You don’t want to implement this on the client side for network performance reasons, so you’d like a way to to transfer a copy of the file from user A’s hub to user B’s.
Am I understanding that properly?
I think the part that really confuses me is the “make a new hub” part. I’m not sure what that means.
@jude isn’t there a type of gaia access token that gives a user the ability to generate a scoped write token that one could give to a 3rd party to allow it to write a portions of a user’s gaia hub?
If that’s the case, what you could do is something like this:
User A encrypts file using a symmetric key and upload the file to his gaia hub. He also uploads a copy of the symmetric key to his gaia hub encrypted with his app key.
User A sends a link to the file to User B and also sends a copy of the symmetric key to User B encrypted for user B using a secure channel
User B views the file and decide she wants a copy of it in her personal hub.
User B encrypts the symmetric key with her app private key and stores a copy in her personal hub.
User B generates a scoped gaia access token for a known area of her storage hub.
User B sends a request to a server S that includes a link to the original file on User A’s hub and the scoped gaia access token previously generated.
Server S copies the file to the destination on User B’s gaia hub.
You trusting server S with the ability to write to that area of your hub. The server would never have read access to the file though.
It would be nice to build this functionality into gaia hub though. Not sure if it’s on the roadmap.
Yes.
I don’t know about such feature and if there is any there is no need for a middle hub.
What I mean from a middle hub is a hub made with a new random private key and not the user app key, so he can share it with the receiver or server to the transfer.
So in either way, the user control on data and his privacy is safe?
But like you, I like to see such a feature to remove the extra complication too.