Update Proposal for Storage Node Operators

First thing, thank you for posting the proposal. I was starting to worry about it, as it was already announced 3 months ago.

The proposed ranges for egress traffic are pretty wide. I wonder whether this is an attempt to differentiate payments between nodes (maybe by reliability, maybe just by maturity), or just the uncertainty of estimates. As I stated in @BrightSilence’s thread, I’d be fine with the upper bounds, or slightly less than that. Lower bounds, not really.

I’d like to compare this proposal to Hetzner’s (obviously…) offer. Their best offer is around 1.2 EUR/TBm of storage including mostly unlimited egress, with hardware and networking probably more reliable (i.e. less repairs needed) than most of SNOs. If there’s not enough SNOs at that level, Storj can always get some hardware from them.

Was going to ask the same. SNOs are (supposedly) mostly private individuals. And there is that thing called inflation that hits them more than companies. Cause companies can have cost write-offs and when operating costs are becoming a problem to the point where there is no room to maneuver, they can always increase the price of their product, shifting the increase on the customers.

I am not saying that even a small cut shouldn’t happen, but really, how it was calculated before to be any profitable long-term? Was the plan all along to lure many nodes first, then start the cuts and hope folks stay “at minimum wage”? You clearly must’ve calculated that. Or was it a blind “we hope that somewhere on the planet the running costs will be low enough to host sufficient amount of nodes for the network to work”.
Transparency? Share those calculations and plans.

--------------
About the thing that old nodes tend to keep cold data and do not get much egress. How about the network balances out the share of the old data, moving some of it from old nodes to new ones? Old nodes get room for fresher data with higher probability of egress and new just get the same amount of ingress as now, but some of it comes as a cold data from existing nodes. And yes, that egress for old nodes would be free, as I assume fresher data will be more profitable anyway. If you (totally not looking at certain individuals) have issues with that, maybe we could have an opt-in/out config “i-dont-want-to-be-paid-more: true”. How would that work? I don’t know. Free up some as new data comes? Free upfront and then data just flows? Whatever the algo, that’s just an idea to address the issue of old nodes becoming Snorlaxes.

1 Like

and where did you get those numbers.?

Cheapest I could find is ~1.27€/TBm excl. VAT (64TB server), but in regards to hardware it’s nothing more than consumer grade. Network yes, it’s a bit more than just a single ISP connection. And there are already a couple of Hetzner Servers active, as nodes and linkshares.

Right now they have a 10×10TB auction server at 107 EUR/month before VAT, and a 15×10TB server at 143 EUR/month. I’m observing their auctions fairly regularly, this is the usual price for these devices. Sorry, their UI doesn’t allow linking to a specific server on the auction, but there’s a list here: https://www.hetzner.com/sb?country=ot&drives_count_from=10&drives_size_from=10000&drives_size_to=16000&search=ECC.

They’ve got ECC, so at least this factor makes them better than regular consumer hardware.

2 Likes

Right, forgot about the auctions. Last time I checked most of these servers were more expensive then the new ones, so stopped looking :smiley:

A necessary question: Has a similar plan of salary/revenue reduction by 30-90% been proposed to all Storj employees/investors (including yourself John)? If so, how many of them have agreed to such cuts of their salaries?

-atom

5 Likes

It doesn’t matter whether the roll out is gradual or sudden. As soon as it is confirmed that the SNO payout decreases have been agreed upon to happen and have started to happen, I will start the process of graceful exit on all my Storj nodes that qualify for a graceful exit.

-atom

2 Likes

You’re comparing apples an oranges here.

as I said above, they choose the easiest way for them by pushing the difficulties to their providers(SNOs). But what we can do? Nothing.

However if you run your old node in the Storj advocated setup without redundancy and your disk fails then you’re doomed.

Did some math. Roughly:
2x 4TB: pays for disks in 3+ years, then just gives scraps each month = not worth a hassle at all
2x 8TB: pays for disks in 3+ years, then pays for internet = it’s not nothing, but it’s not something either
2x 16TB: pays for disks in almost 3 years, then pays for internet and maybe a gym card = better, but…

All the above based on:

  • max proposed amounts
  • no fees and taxes (don’t want to waste time figuring it out now)
  • no energy cost increase (lol)
  • disks get data without interference (no /24 limitation)
  • everything “just works”
  • 4TB bought used, 8 & 16 new

Add in some maintenance time or disk failure and it just collapses. Can do more in-depth calculations, but at this moment I think I’ve spent enough time on something that may just be like a ball and chain.

2 Likes

I hope Storj is aware that this can turn into a kill switch for Storj. I am still figuring out if this is viable for me as SNO but it looks really really bad.

A lot of time has passed since you have initially announced changes to the economic model but you have also asked what signals would SNOs require so that Exabyte scaling is possible. Well with these payout amounts I don’t think it is.

I really wished Storj would have started the changes to the economic model on their own responsibility rather than simply pushing the problem to the SNOs. I don’t see your suggestions for price increases or technical optimizations and I fear with that new payout you will see higher node churn, higher repair cost and at the end more centralization than ever with less nodes. A minimum node with 500GB will never be interesting with these payouts.

So what I would like to see from Storj:

Changes in cost structure

  • Tune RS settings as proposed by @BrightSilence to limit repair
  • Work on the incentive structures to keep old nodes on the network
  • Work on the incentive structures to limit repair due to exit without graceful exit
  • Decentralization of repair service
  • Decentralization of Edge services if possible
  • Remove test data or at least start paying less for it
  • Incentivize customers use of native integrations
  • Limit free tier (Timed Trial only, delete unused accounts, none or limited gateway services) unless user is high prospect. Maybe there should be a harder distinction between “personal” and a “business” account where the business account comes with higher price but gateway services included.
  • Limit use of token where required. Gateway costs are always $. So if a customer can pay by token for that even with a discount this sounds like a disadvantage for Storj.

Generating more revenue

  • Increase price to $5 / $10 (Storage/Egress) per month. Rather apply discounts for fitting customers or customers with huge data demand if necessary. There have never been better times for a price increase as prices go up everywhere. If you are too scared to scare existing customers away with that, make price change for new customers only.
  • Charge for gateway services. It is very understandable that Storj DCS low prices can only be achieved if the customers use the low cost decentralization structure. If customers want centralization then they have to pay the price for it. Not the SNOs!!! The SNOs are not at fault for those incurring costs. They deliver their job as they should.
  • Develop use cases that could justify higher prices. Let me link to one Wasabi example: Pay-go Pricing FAQs - Wasabi, they charge $10,99 for their “Surveillance Cloud”. I made the suggestion to Storj to look into this market years ago. There would have been plenty of time to develop similar cases.
  • Technical certification or certification for legal or other specific compliance can also justify higher prices and bring more customers. Why is there no ISO, DIN, TÜV, GDPR, HIPAA, CJIS, FERPA, MPA certification until today?
  • Specific data storage requirements like geo-fencing (but also other use cases like specific distribution of pieces) could also justify higher price models.
  • Maybe even to create new sources for revenue stream like value added services or different support packages.
12 Likes

I think the payout cost for TB stored should be higher than $1.50/month and then fudge the egress cost structure from there. It is difficult to predict exactly how much bandwidth you will have each month so providing more value from the TB stored makes it more predictable for the SNOs. Bandwidth does cost so it shouldn’t be free by any means but I’d rather take a hit on lost profits from bandwidth vs the actual storage requirements.

Lowering both the traffic payout and the storage amount I will probably stop hosting but I would stick around if the TB/month amount was slightly increased while lowering the egress payouts so it makes sense for STORJ as a company. They need to do what makes sense for them to be profitable but they also need to make decisions that keep their SNOs happy because without the SNOs they don’t really have a viable product. It is a difficult balancing act for them but I hope they actually listen to all of our feedback and make a smart decision otherwise it could very likely backfire.

1 Like

As you can see even the upper range of those proposals give people few years of ROI just for the hardware, not to mention if it breaks or maintenance time.

It’s not possible to think about the future of this, if new payouts will give you basically 0 return. You’re gonna basically be losing money for running nodes. Let’s say you have a disk that needs 3+years for ROI. You run it for 2 years and you’re very unlucky and it breaks. and now what? you don’t have the data to keep earning pennies and you don’t get it back. Which means you just lost time and money. After this I would feel pretty bad… Wasted money and time and I don’t even have money to get another disk in that place… these proposals are joke.

I have a question, how did you came up with those lower proposals and have you even tried to do the math to see what are the expenses of running a node with that kind of payout? Or just tossed them in here to make the upper proposals not look so bad?

2 Likes

Without the SNOs they don’t have any product.

6 Likes

Can we use Storj clients and satellites software on-premises to create our own network?
Maybe it’s time.

1 Like

@john
Also where is this in this model:

1 Like

That would be just insane! This is exactly the backblaze pricing model (including S3). If a customer can choose between Backblaze and STORJ for the same price, they will never choose STORJ (and have not in the past).

I totally agree. But if we charge for gateway, the default prices have to go down.
STORJ base price + S3 fee has to compete with $5 / $10 (Storage/Egress) backblaze.
STORJ base without S3 needs a big discount to compete with $5 / $10 (Storage/Egress) backblaze.

Totally agree with both. But I think these things need a lot of time and they better get the basics done right first. That is the problem I see with a lot of the posts here. You guys keep dreaming about a fantasyland future.

and how scaling will make the economics worthwhile, while in reality STORJ can’t even find enough customers to fill up 100PB. The disconnect between what you guys think STORJ is, and what the customers thinks STORJ is, is huge! Maybe the customer is just dumb and does not realize how good STORJ is. Guess what, that does not help us in any way! In the end customers are the ones paying!

I don’t know if STORJ management is just greedy and soft rug pulled this project or if they pay way to much for edge services. I think someone from STORJ should explain, why they think the 5% portion of the company needs cutting down and how they plan to save on other parts.

2 Likes

A wiser decision would have been to stop accepting new nodes when Storj had reached the number of SNOs deemed appropriate for their business model.