Startup project : host personnal user informations

Developer Discussions
1

Hi,

I need some advice about a project I’d like to start in my country.

The service would allow anyone to host files and folder on storj.
Basically, the user goes on the website, register, then manage his own files.
What’s the best way to do it?

1/ Do I have to create one “access grant” for each clients of the website on my own storj account?
2/ I don’t know yet what’s a bucket. But do I have to create one big bucket or multiple small buckets?

Thanks

2

What about backups? In a previous post you said we must always have backups. But since the network is decentralized, why do I need the backups? Am I fine without backups on my side? which would cost me more money from s3.

3

We do not build the consumer-facing applications, so that part would be on you. We give you a backend for such applications.

The bucket is a high level storage unit, it could contain a lot of objects. The name of the object (key) can contain prefixes (like “subfolders”, but they are part of the object’s name).

See more details there: https://docs.storj.io/dcs/concepts/key-architecture-constructs

There are many approaches to achieving your goal.

  • You can create a bucket for each of your client and allow them to specify an encryption key, you will not have an access to their data, but they can. You would be able to forcible remove the entire bucket though. Your clients can use different encryption keys for their objects.
  • You can use the same bucket for all your clients (less convenience), since each client uses an own encryption key, they would be unable to see content of others. However, if they specify the exactly the same encryption key as any other client in that bucket, they would be able to see and manage the foreign content. Your clients could have a different encryption keys for their objects. You would be unable to forcible remove their data, because you can’t distinguish them from object of other clients.
  • You can use the same bucket but different prefixes (“subfolders”), then your clients would be unable to see and manage a foreign content even if they specify exactly the same encryption key. Your clients could have a different encryption keys for their objects. You would be able to forcible remove their data (going through the list of encrypted objects for the known bucket and prefix and delete them one by one).
  • You can use different projects in your account and have a separate billing for each of them, but increasing number of projects is not automated yet, you need to file a support ticket to increase their number. So it’s less desirable way.

Each of approaches gives the possibility to share content. You also able to hide the Storj’s linksharing URLs and specify your own domain instead. Your clients even can host a static website.

The difficult part could be a billing of your clients - in case of separate buckets you can see in the report how much space and egress bandwidth it uses. But in case of “one bucket for all clients” you would be unable to separate usage the one client from another. This is not a problem too - you can charge a fixed price, not all clients would use their quota at whole, so you would have a profit even if you specify a lower price (like DropBox is doing).

You can conclude a partnership with Storj to have more support.

2 Likes