Hey all, new to Storj. I spent some time going through the docs, but I could use some help in figuring out some high-level concepts.
My goal is to build a web application that lets users upload, manage, and share assets (images, videos, text, etc).
Are these the correct steps to take:
Generate an API Key
Create a bucket for each user
Generate an Access Grant for each user, letting each user specify their own passphrase and associating only their bucket with the grant
Users use their Access Grant to manage objects in their bucket
Now presumably, each user has full access to their own bucket (read, write, delete, etc). As an admin, I do not have access to their buckets (except I can delete the entire bucket if I wanted to). Is this correct?
Some questions I have:
If my Storj account were to be deleted, all user data would be lost, right? Is there a way for users to still have access to their data, regardless of whether or not it’s through my application?
What’s the best way to manage and use user Access Grants? Should they be stored like oAuth credentials in my backend?
Yes, you are correct. You can even use a single bucket, but different prefixes for each user, this will allow you to have an unlimited number of users: your paid account will have a limit of 100 buckets by default (see Understanding Storj Usage Limits - Storj Docs). Of course, you may increase it with a support request, however, if you would use the single bucket, then you would not be forced to request more.
There are several ways:
Pay your bills in time
Do not delete user’s data
Allow users to use their own access grants or S3 creds from their Storj DCS/Storj OSP accounts
There are several ways
Do not store the access grants and generate them client-side with provided user’s encryption phrase (like we do in the satellite UI).
Encrypt user’s access grants by provided password/oAuth/biometric code/etc. and store it locally on the user’s device (in the encrypted browser’s local storage for example), and use it only when the user want to access their data.
Store it on backend in encrypted form using user’s key (like we do if you use a Storj-hosted S3-compatible Gateway), and decrypt and use it when the user wants to access their data; the user should provide a key to decrypt encrypted access grant, but it’s better to decrypt it client-side if possible, or store decrypted access grant only in RAM during usage and remove after expiration, see Understanding Server-Side Encryption - Storj Docs.
I believe there are also many other ways to implement this.
Allow users to use their own access grants or S3 creds from their Storj DCS/Storj OSP accounts
So users would have to create their own Storj accounts, first? This feels like a lot of friction. Also, if user data falls under my account and (let’s say) one of my users is a malicious actor, could all my users be impacted if my account (or Storj in general) were subject to a content takedown notice?
I’d like to avoid centralized points of failure as much as possible. Thank you for your help so far!
But it’s a most secure and independent way to separate your account and user’s account.
Usually it happens only if the user published either their keys (access grants) or a link to the object with a malicious content. So you (or Storj Labs) would be responsible to take down either such keys and/or URL.
You can do it either by revoking published access grants and/or requesting to take down the published URL via support request. Maybe there is a more graceful way to do so.
then you need to allow users to use their own access grants and do not store them in unencrypted form on your backend, in this case you would not have even a partial control above their data.
When you implement a share function you may also enforce users to use their own domains, in this case at least your domain would not be impacted.
You could try setting up a perpetuity that would pay for storage expenses even if your project goes down. No idea whether this is possible in the current crypto world.