Hi is It possible to create a new account ( email/password) programmatically ?
@comeno We have Account Management API scheduled in our roadmap: Account Management API · Issue #6 · storj/roadmap · GitHub
I don’t think it covers the account creation itself, but everything else after the account is created.
Could you describe your use case and why you would need to create a new account programmatically? I believe you could do this even now by sending the same request to satellite - just like the sign-up form on our website does it. But have in mind there will be still a manual step - the user must confirm their email address.
Why redirecting to our sign-up page is not enough for you?
3 Likes
Create an unlimited number of free tier accounts and program it to divide your data across accounts but make it seamless on your backend. That would allow you a lot of free storage. I could see that being one reason.
Another is being a reseller of the service. Have your own front end, and mask Storj on the backend. You could do this now, but the accounting would be difficult to track. Would be easier to use Storj accounts to track usage and bill accordingly.
I think for the multi-user frontend would be simpler to have a one account, but different buckets for each user. You can allow the user to use an own encryption phrase for their data. In this case even you would not have an access to users data, but you still can remove a bucket if user would stop to pay you.
1 Like
The reason is the latter but I’m not a reseller. We are just a group of friends/co-workers and we just started with StorJ.
I need to build a little project in order to figure out if it is right for us.
150Gb is fine to start but we need to handle it with our front end and to save trend data.
afterwards introduce the prj to other Co-workers…
I don’t know if this is against tos or what else
@Alexey note that there is a limit for the number of buckets in a project: storj/config.go at 4f196dd39ee4f735d4cdac72fbc477cd3ad4e858 · storj/storj · GitHub
It’s not recommended to have a bucket per user. We usually recommend all user data to be in a single bucket, but namespacing it with a prefix for each user.
It is still possible to use a separate encryption key per user by overriding it for the prefix: Multitenancy in a Single Application Bucket
4 Likes
@comeno Perhaps, you may want to consider our OAuth2 solution that is coming very soon: Login with Storj (OAUTH) · Issue #13 · storj/roadmap · GitHub
It would allow users to log in with their Storj account to your app. Users will still pay Storj for their raw usage of storage space and bandwidth. Your app can charge them separately for the added value it provides.
The benefit of this approach is that users has their own Storj account, own their data and encryption keys, and take advantage of their free tier with Storj.
4 Likes
Alternatively you could use one bucket, a prefix per user, generate an access key per user and use a password based key derivation function to generate the encryption passphrase client side. This would still allow only the specific user access to their data without giving you as the Storj account owner any access.
You’d somehow have to deal with password changes though.
Alternatively you could randomly generate a passphrase locally and encrypt it using the users password client side. In that case you would just locally decrypt using the old password and then encrypt using the new one.
3 Likes
I am interested in your use case, can you tell us more about what you are trying to build? As you have noticed there are lots of options, if you share more details we can probably help guide you to what will fit best!