It is quite ridicoulus when SNOs start to fight over 20PB of storage when alone AWS has reported 500 trillion objects stored on S3 taking hundreds of exabytes of capacity.
The amount of data stored in the cloud was expected to reach 100 Zettabytes in 2025.
Today even smaller enterprises have petabytes of data to manage and to store.
Unfortunately I could not find some kind of a ranking of cloud storage providers by amount of data stored. But I fear that even smaller or regional providers are storing more data than Storj.
So the ultimate goal must be to get a larger share of the total of 200 Zettabytes of data globally stored by 2025 and not fighting over 20PBs of data.
SOC2, ISO 27001 and others would still help with that. Unfortunately we nevery heard back what happened after
And now they even sold Storj and the new owner remains silent.
Well, that’s what creating the market and 20 years of history does for you. Don’t expect challengers to immediately rise to this level.
Yeah, but that doesn’t mean they want to use a distributed network for this.
I know one of these companies. Their use case is just not a match for a public Storj cloud despite having “petabytes of data”. Not all data needs to be shared across continents, for some a better fit is just a single location with compute close enough to not have to pay for bandwidth. Apples and orange pies.
I know people that store more data at home than what STORJ is storing in Europe.
But I don’t blame customers. STORJ proposition just isn’t attractive.
S3 is a commodity. Something you can change pretty easily. So the only thing you need to sell a commodity is a good price.
If someone would start tomorrow with gas stations that sell at a 50% discount compared to others, you would not need 20y for car drivers to finally make the switch, just because the love their local chevron station so much.
It’s not just that. Give AWS a head start for inventing the whole thing.
But look at Wasabi: More than 3 Exabytes stored today. Founded when? Like 2017 or something. Storj was founded 2014 and sitting at 20 or 30 PBs. The total amount of data created, captured, copied, and consumed globally is forecast to increase rapidly if not exponentially. Yes, not every single byte will be stored in the cloud and many enterprises have good reasons to store their data with specific providers or on premises. But we have seen that a single customer like Vivint created a huge load and made everybody already exicited. Nodes could not keep up left and right to a point where Storj wanted to use surge nodes. So as little as 1 single customer out of 200 Zettabytes of data could have a significant positive impact on node fill rates.
S3 is a commodity until it isn’t—when performance, latency, locality, or features like access logs suddenly start to matter. S3 stopped being simple a long time ago. Just see how many features Storj still does not implement.
Heck, even I had to write a few thousands of lines of code simply to work around bad AWS S3 performance in some ugly corner cases.
You need a product and you need a market.
Obviously there is a huge market for cloud storage and obviously there is a product that caters for that (S3).
Then you need a good product fit for the market. Here is where Storj is struggling. We see many indicators for that. From rebranding to focusing on specific use cases and tailoring the product for it.
And then you need to find the customers for your product. Here is where Storj really sucks.
We have seen with Vivint that there are huge potential customers which needs to be identified and attracted. Unfortunately for Vivint and the global network, the product fit was not there. The decision to obtain SOC2 was not made when it should have been made like years ago (Because I guess it would take a minimum of 1 year of work on the product and the company to get everything ready to pass SOC2).
We also know and see from competitors how important the certificates are for specific industries (Health, government, etc.).
So I believe the To-Do list for the new parent is clear: Bring S3 on par with the original, obtain all certifications, broaden the use cases of the product, increase marketing efforts at a global scale to identify and target the right enterprises.
Maybe the new big customer that fits is sitting in South Korea not even knowing about Storj because Storj is not present there.
IMHO that is not going to work. STORJ will never be competitive offering S3.
Not with the current architecture. They can get rid of nodes and just become another S3 vendor, but with the current setup, it will never be possible to be competitive in the S3 market.
STORJ could be competitive in another market. Remember the USP of Storj?
The one and more importantly only advantage of the Storj architecture?
Having free storage and bandwidth, because we use only use unused resources? On that model I would try to build a business on.
For example. Offer 1TB for 2$ a month. Ditch S3 (or add a self sustaining premium on top of it, which basically would also kill S3, I don’t care).
Create a Synology and TrueNAS integration.
A year ago his report only included the larger filesystem-level numbers: which look around 744TB now. Since summer he also added the smaller node-reported-used-space: 619TB now (and the differences). So you’re right if we compare 744TB vs. 600’ish a year ago… the average is closer to 1/3-to-1/2TB/day.
Still can you imagine averaging 1/2TB/day? Maybe syncamide gets even more with his 100 IPs!
th3van is not doing it the same way many people assume. He uses real IP subnets (e.g. /30) combined with policy-based routing, so every node has a properly routed, independent source IP. From the satellite’s perspective this is just correct networking, not a trick or workaround. The correlation risk is therefore mainly host/location-level, not IP-level.
What is often misunderstood is how Storj’s redundancy actually works today.
Storj uses erasure coding, and the numbers have changed significantly over time. We are not talking about 110 or even 80 pieces anymore. Currently, a segment is encoded into ~49 pieces, while the network only needs around 29 pieces to reconstruct the data. Repair already starts very early, at roughly 46 available pieces, which is intentionally conservative.
Nodes going offline is not an exceptional event — it is expected behavior, and the system is designed for it. That is exactly why there are more pieces than strictly required. Even if someone operates a very large number of nodes and many of them go offline at the same time, the network does not instantly lose data. After a few hours of sustained unavailability, repair kicks in and regenerates missing pieces.
That said, the basic rule still applies:
the more nodes a single operator has that go offline simultaneously, the more pieces are temporarily lost, and therefore the more repair work is triggered. This increases risk for that operator’s data contribution, not for the network as a whole. The redundancy and repair mechanisms exist precisely to absorb such events.
In short: large-scale correlated outages are not “free”, but they are explicitly accounted for by the design, and current repair thresholds leave a lot of safety margin long before actual data loss becomes a concern.
IP subnetting is a shortcut, a proxy, to correlated risk. Nothing else. That’s the whole point. There is no separate “IP-level” risk you are referring to.
It does not matter how you get 30 different IP addresses – via your provider or via other providers over VPN. Net result is the same: for the purposes on /24 rule, your correlated nodes appear uncorrelated, and receive more traffic than they otherwise would, if the system knew those node are under the same roof and share majority (all) of infrastructure. Why does not th3van put all nodes under the same IP? Correct, to get more traffic and payouts. Exactly what /24 rules is designed to prevent. (note, no judgement here, just facts).
Whether this is a problem from storj perspective is an entirely different story. But from general considerations – If it wasn’t, and if the network was able to absorb such behavior – there would not be a /24 rule in place to begin with.
If tomorrow everyone starts routing shit from the rats nest of links to workaround /24 limit - storj will have to either increase erasure coding, and develop different heuristics to proxy collocation assessment.
So this is a prisoners dilemma. We can not be assholes and abide by ToS, or we may not – and suffer consequences together as a group. Right now we are in a transitional stage – where some limited abuse is tolerated.
But seriously, who really bothers with all those concoctions for Storj payout? I guess if someone does not value their time enough to bother concocting all that VPN infrastructure to steal $5/month more from storj.. I guess let them have it, for effort.
Note, storj wants to keep node operators payout around $130k, so there is no reason to deceive only to get a marginally bigger cut of this tiny cupcake. When storj starts paying at least 1M/month – then we can optimize. Now it’s pennies.
Thankfully, heuristics just need to make cost-ineffective to work around rules, they don’t have to be 100% correct. The combined facts that regular IP addresses go for around 1 USD/mo now and worse latency leads to losing more races is already a non-trivial deterrent. Even Th3Van admits that in this thread.
Besides, better heuristics are already known. They are more difficult to implement, sure, which is likely why they haven’t been done already, but it’s as so much research work as just engineering.
All I want this year is a monster server and a few JBODs to hold… around… maybe 200 30TB HDDs? And 200 separate /24’s. And a 10G Internet connection. In North America. Maybe a California or New York datacenter? And then maybe with luck … in 5 years or so …
…people will create threads about me in the Storj forum!
… in 5 years or so 
…