70 nodes… 
man, I can’t imagine how huge is your multinode dashboard. 
This is the definition of commitment.
Yes Vadim, but you are everything but a typical Storj node operator! 
1 Like
I dont use Storj multinone dashboard, ihave my own, it enouth for me, no grafiks just numbers.
1 Like
If we would exchange Average Joe/Jürgen/Frank’s small nodes to such 60TB company NAS nodes then the whole concept would be broken.
Yes, I was going to suggest some modifications to Dashboard, to be more compact and display all info on one page. Those graphs occupie to much space and they are somehow useless.
Yeah, same here. A 60TB NAS sitting half-empty at my office. No permission to set up a node though unless I’d promise I could scale it back at moment’s notice in case the business would need the space. Partial graceful exit would be useful ^^
You can decrease storage limits to shrink a node over time. Alternatively run multiple nodes so you can decommission them one by one.
If we would exchange Average Joe/Jürgen/Frank’s small nodes to such 60TB company NAS nodes then the whole concept would be broken.
I don’t understand this comment. What would go wrong if the storagenode operators are a mix of prosumers and small and large businesses?
If we grow to exabyte-scale we can have a few petabyte-size node operators.
Not really. Most storage is long term. After an initial drop of ~25% of the most recent months ingress, data usage barely drops after that.
This is against ToS if done on the same HDD (it’s unclear whether an array is considered as 1 HDD since you’re technically sharing HDDs still).
Then again ToS also still says we can only run a single node per IP.
3 Likes
Not quickly enough.
Banned by T&C.
1 Like
I’m with @BrightSilence and @Toyoo on this one:
True in theory only. This takes for ever in practice and isn’t usable. At all. The “partial graceful exit” feature needs to be implemented if StorjLabs really want to give SNOs a way to shrink nodes without completely turning them off for good.
Since it is basic internet 101 to not expose anything more than you need. I doubt it.
I agree that such a feature would be great to reclaim space in case a SNO needs it. But what do you suggest to prevent abuse, meaning that SNOs could be tempted to clean out data and refill it with new data to have more egress.
When starting the partial exit, most popular pieces get moved out first.
Such a partial exit would need to be tied to the economic model to keep fitting when there are changes in the payout scheme. For example if there might be a bonus for older pieces (as suggested here), maybe old pieces should be removed first, to reduce incentive for SNOs to get rid of them.
Generally, maybe completely randomized deletion of pieces would be most fair?
So that a SNO never knows what pieces he is going to lose?
My points here are:
1, prosumers will not do it for cheap, so we go back to the starting line of this whole discussion
2, as the total daily ingress increases, small node operators will face that their smaller drives fill too quickly → less monthly payments → they leave. For big nodes, there is no such “threat” as there will be allways some free space, so they will allways get fresh data → higher monthly payments
3, Yes, there are such 60TB NAS drives unused, but as @BrightSilence mentioned these can be used with limitations (and not allways for free)
4, If you share data over 10 small nodes and one of them fail, you still have the data. But if the big node fail you lose more data or repair would be more expensive.
I think Storj labs always makes the smartest choises, sticking to the KISS principle. Why overcomplicate things? The SNO can addapt itself according to each situation, no point in complicate the code for specific situations.
If you use a storage/device that is not yours, take small steps, so you can go back and not loose everything all at once.
You have 60TB? Begin with a node of 4 TB. When is 80% filled, start another one with 4TB. And so on untill you use all the 60TB. You need space? Stop a node or 2. You only loose a small fraction of the business. TOS says only one node per HDD, but they can’t enforce that. Yes, this is the best option when all the gear is yours, but if you borrow it, you must addapt. Don’t expect the code to be addaped. But the ideas are wellcomed, never the less.
1 Like
I might decide to violate a T&C rule or two when doing it on my own hardware, especially if violation is explicitly allowed by Storj employees on the forum. However doing so on behalf of someone else is another matter. And this specific rule of not running more than one node per HDD was not stated so far as an acceptable violation by Storj. Erikvv’s message in this thread is, I think, the first time. And this rule was actually considered somewhat important in other communication from Storj.
Right now it doesn’t seem Storj has problems attracting SNOs, which is great! Yes, I do remember of the pending discussion of renumeration for SNOs, which may affect things. And I’m actually leaving the company with the 60TB NAS in few days (after working with them for 6 years!), so that NAS would stop being available anyway. But then, maybe I’ll have similar opportunities in future. Just like Erikvv stated, I know of some small businesses around here which do have hardware already, and would allow hosting a node if there was a party interested in setting it up and maintaining it.
Then again ToS also still says we can only run a single node per IP.
Seems to contradict the recommendation of having a node per hard drive. Once your nose fills, your only option is larger drive.
Are you confusing the one wallet address per operator requirement with one node?
ToS says only 1 node per IP, per drive, and only 1 wallet for all your nodes. But it needs an update, or is let that way for the eyes of customers, to emphase the decentralisation. Because the guide to multinode behind the same IP is also official. 
If we all sticked with the rules, the Storj Network whould be very different, like 1000-2000 nodes owned by hobbists and a few whales who can afford using DCs or ISP locations to get many IP addresses… and Vadim
2 Likes
To me, it looks like the reality check for STORJ is just around the corner.
With STORJ price plummeting, the subsidies shrink.
When I look at the price charts, STORJ behaves almost exactly like the BTC price, just like almost every other coin.
My guess is that the BTC price on the other hand will tank when we find out, that the value is inflated with made-up stablecoins. FTX, Binance, TRON, Tether…
But to be fair, I was wrong before and thought that we would witness a way bigger crash this summer, and BTC stabilized around 16k That is also why I would not bet money on it, markets can stay irrational longer than I can stay solvent 
Again this is just wild speculation, but I hope it happens rather soon, to see if the economics for STORJ work. No matter how it turns out, this is gonna be very interesting.