If you enter “data center” into a translation software for German, you get “Datenzentrum”, “Rechenzentrum”, Datencenter", “Datenzentrale”.
None of these words you would use in German language to describe a Raspberry Pi in a basement at home.
Too bad for the Germans around here…
Germany has, unironically, the second highest number of nodes, ahead of the US.
That I thought also listening to it; better to not get into details and stick to basics just to give a general ideea to a not-so-techincal audience. If you get to technical, you loose almost all their attention. And for the tech guys, they don’t need a speach to a conference to understand what’s what. They go to the source and read white papers and github repos. So getting to technical to a general audience conference dosen’t realy make sense.
Okaaaaay soooo maybe would You like to pull up some i don’t know egress from the Public network? just to support some basics for the nodes this month, coz right now the 10th month is looking very sleepy, disks being emptied, to be ready, but You could pull some traffic maybe to compensate just a little bit, You know, ooooor we could accept any x2, x3 surge in thanks for our great fraternal cooperation that in the end resulted in improving the network and on-boarding a 1B unicorn customer, just too bad that not on our SNOs disks, You know.
If SLC is being used to reserve capacity for 2-3 months worth of projected growth… then if it’s slow now it’s probably because they already have enough extra space available.
No use paying SNOs for space that won’t get sold soon.
Not too surprising. After everyone was rushing to add capacity for test data Storj now has plenty of available space. Probably more than they would have dreamed of.

To me it doesn’t look like that is going to happen. The incentive internally seems to be a positive unit economics. I don’t track the actual numbers but as far as I understand any kind of subvention including filling the nodes with test data would work against that. The only exception for this would be for onboard a bigger customer. There the short term extra cost might be covered by the long term payments of that customer.
This metric includes the storj select nodes we are adding to the network. I hope at some point the metrics will differenciate between public and storj select network. Right now they don’t and to make things worse there are even storj select nodes on all satellites. The best reading you might get from the EU satellite since there the number of storj select nodes is still low.
Why is this still unsolved?
We want to be taken serious by clients, but even the official statistics are wrong?
How hard can it be to make 2 graphs, 1 for public network, 1 for the other?
We would at least don’t have more of this, because they (SNOs) have wrong impressions:
https://forum.storj.io/t/farming-preparation/28209?u=snorkel
Please, make it a priority!
to be honest if you would be developer, you would know, that there is always 100 different tasks and every one speak that there task is more priority than other. you cant make them all and make all happy, first priority will always be features for people who pay money.
Obviously there is only one network.
Select seems to be implemented as a filter to the node selection.
I would love to see the level of decentralization of the storj select nodes side. You cannot sell that Storj is “much better for the environment with a carbon footprint up to 83% less than hyperscalers”, decentralized, “put unused storage space to work on a global network”, etc. and then have big customers using storj select nodes in datacenters in the US, not global atm.
Why? If customers want geo restriction — they get geo restriction. It’s customer choice. You can make other choice and use public network.
Are you saying every customer MUST use every location to satisfy…. what requirement exactly?
What is wrong with US datacenters? They are decentralized, and have tons of spare capacity.
Aside from being only in the US, just nothing I would say. I would consider it a selling point for the remainder of the world: keep the pollution in the US ![]()
@alpharabbit is partially correct, this is one network, it even uses the same satellites. It has a separate edge services though and nodes on Select is configured to join only one satellite and have a special tags in the databases. Repair workers and auditors are different too.
So, it’s the same network, because theoretically you can move data from Storj Select to Storj Global and vice versa with a special repair workers, but it would be costly. However, I think it’s possible. Or use rclone sync between two remotes (now it would be costly for the customer).
For the customer it’s the same network. If the customer need some Select bucket and other on the Storj Global, they can do so. They do not need to change anything if they would use a Storj native protocol. For S3, well, the edge services have different endpoints. I’m not sure that it’s possible to use a Storj Global edge endpoints to upload to the Storj Select bucket. But should be possible to use a Storj Select edge services to access Storj Global.
That’s my original question. Anyways I would love Storj sharing some info about it. Maybe the Storagenode version for Storj select has nothing to do with the one used in the public network.
That’s not correct. At the moment, there are select nodes only in the US. Nothing to do with “geo restrictions”.
The software is the same. The version may differ, they may have more recent version running, but it’s still Open Source and available on our GitHub. Just note that not all nodes can be accepted by a production satellites, because they may have the developers defaults.
That’s incorrect too. We have a Select nodes also in EU and AU. Perhaps in Japan and/or Singapore too (but I’m not sure about last ones). First of all the Select nodes used exactly for geofence when they cannot use a Storj Global with a geofence for some specific reason and/or SOC2 requirements, or very strict geofence (up to city).
And we can extend if there are demands in specific locations.

