S3 disclosures and limitations, a living technical document


Greetings - this is Jocelyn (community manager). I was having a conversation internally with our engineer @kaloyan about S3 and implementation for a project Im working on . He mentioned this document which I hadn’t been aware of at https://www.storj.io/disclosures . I love that its a living document, and that it’s so well organized for reference.

I thought it would be helpful info to people looking to use the product, so am placing it here.

You can also check out these relevant discussion topics


excerpt from intro | Disclosures

At Storj, we are relentlessly pursuing the best system we can. Of course, we’ve still got work to do. This document is intended to address the known limitations of the product (with regard to security, performance, availability, ease of use, economics, and more) that we are busy trying to address.

There are also some instances where we’ve made what we think are thoughtful compromises between competing goals (e.g., completeness vs. time to release, security vs. ease of use, decentralization vs. economics). Still, some users might disagree with those choices.

There are also some circumstances where, to support certain use cases or to work with outside systems (e.g., to support certain common S3 usage patterns), we’ve had to give users options, and some of those options represent compromises.

While we think we’ve made the right trade-offs, we don’t want to substitute our judgments for yours. So:

  1. We publish this document so that you understand our choices
  2. We’ll always try to make sure users can make well-informed decisions in product
  3. We publish information on the state of our network, so users can make informed decisions (more info in section 7 below),
  4. We are open source, publish detailed whitepapers, and publish frequent technical updates, so you can see what it is we are doing. (We do not currently grant public access to Jira tickets, inclusive bugs, and the internal roadmap, although this is a matter of internal discussion.)
1 Like

Thanks Jocelyn, really interesting read - useful to have clarification on the future for small SNO’s as well.

As our list of node operators includes both individuals and data centers, once we reach a critical mass of node operators who are operating compliant data centers, we also intend to add an option for customers to only store data on nodes in compliant data centers should they need to meet storage compliance requirements.

Also would be very happy with;

the community to run Satellites

And you know you only have to ask if you need testers :slight_smile:

We have a project underway to make significantly more data available on a near real-time and programmatic basis

1 Like