Backward compatibility rules

Greetings, @dominick here with Storj. When using the storj (Native) back end the encryption and erasure coding occurs client side which is more intense on local compute and results in a 2.68x upload multiplier due to erasure coding.

Use our native integration pattern to take advantage of client-side encryption as well as to achieve the best possible download performance. Uploads will be erasure-coded locally, thus a 1gb upload will result in 2.68gb of data being uploaded to storage nodes across the network.

Use this pattern for

  • The strongest security
  • The best download speed

Using the S3 backend for uploading is faster as the encryption and erasure coding occurs on our edge services. The disadvantage is you have to share the encryption key with us as we encrypt for you.

Use our S3 compatible Hosted Gateway integration pattern to increase upload performance and reduce the load on your systems and network. Uploads will be encrypted and erasure-coded server-side, thus a 1GB upload will result in only in 1GB of data being uploaded to storage nodes across the network.

Use this pattern for

  • Reduced upload time
  • Reduction in network load

Ideal users could choose between the "Native" and "Hosted S3 Options". I can't post links here but we have a recent write-up on performance. Search for "hotrodding decentralized storage" which should bring up my post on the Storj Community.

Thank you all!