An open letter to the Storj token community: the restructuring, the network, and a proposed path to shared ownership

Announcements
82

The funniest thing is that one official employee talks about free hardware and “don’t buy anything,” while another immediately calculates their own profitability. Could you at least agree within your team whether your company will be based solely on altruists, or on people running their own small businesses?
And yes, those people above have 400 TB, 445 TB, I have 1050 TB, and there are many more of us. I know a person with 3PB used space. And we know the real value of our hardware and time. But you have one or two nodes and you’re not accounting for a bunch of other expenses besides the disk. Which SNOs do you think actually host your data?

P.S. And no, you’re not “using up free space,” data on nodes can’t be partially deleted, and GE takes a month.

83

Good words. I feel like storj themselves don’t know what the public infrastructure actually look like.

84

I agree with you. Unreliable nodes are a big problem in my eyes. They create costs that are not really covered with any money. I took a look on another project that does the same and I like their approach more with locked and risked money.

Just take a look at my repair traffic, this is daily and not “sometimes”. Who is covering those costs? And i don’t think that’s only my node.

1000107198
10001071981076×940 78.3 KB

85

The repair rate is somewhere around 10% per month. Meaning each segment gets repaired once every 10 months. We can lower that buy adjusting the RS numbers but it would increase the total payout for used space more than it would reduce the total payout for repair traffic. Well technically we have offset the ideal spot a bit to create a repair buffer. Even in a month with more repair traffic the total cost will stay in a predictable window.

Once the month is closed I can run that calculation again and check if the current repair traffic is still within prediction.

86

Interesting! Does that mean even if a high-speed node doesn’t win some initial upload races… data will still slowly move towards it over time as it gets repeated chances to win repair traffic?

(Like even if the network stays at relatively the same used capacity… constant repairs will keep nudging data towards faster nodes?)

87

Then I have pretty special nodes. Cause all have more repair download as normal download traffic. And this consistently month over month.

I’ll calculate the number together for each month when I got home.

88

I am glad to hear that Storj has some PB customers and that they have even agreed to the new pricing. But you are right. My question focused on a potential situation after the Chapter 11 procedure resp. now after the information that Storj is on the verge of bankruptcy is all over the internet.

When I think of my fellow Germans in the corporate world, I can’t imagine that reputable companies would even consider storing their data on a platform that emerged from bankruptcy. I named already the DFB in my previous comment. But others too, Wortmann, WMF, Miele, Penny, Edeka, BMW, Dräger, Bilfinger, you name it… I can’t imagine a single one. And I can’t imagine why it would be any easier to convince companies to become customers after they’ve completed Chapter 11 proceedings if Storj hasn’t been able to do so before.

But ok, Storj has PB customers. So why in you opinion is Storj not in the Exabyte league today like their competitors?

Wasabi now has over three exabytes of data under management, underscoring the scale and reliability of its services. Industry analysts see Wasabi’s trajectory as part of a broader shift in AI infrastructure.
“Wasabi’s momentum reflects a clear demand for simple, predictable cloud storage,” said Dave McCarthy, research vice president at IDC.

So in your opinion where did Storj go wrong that they were not able to keep up with the competition?

Some? Not yet. The only whitelabel satellite UI that I saw so far is:

If there are more that is even greater.

I second that. You would basically need regional sales and marketing teams that speak the customers’ language and understand their perspectives.
Also when I see all the team members Inveniam [showcases on their website] (Inveniam - Meet the Team) with all their great careers and CVs, they should be able to recommend Storj to their personal network of high ranks.

I also second that so many suggestions have been made and that Trying to restructure without addressing and without a critical reckoning of the past mistakes will be pointless.

89

Don’t these 2 question contradict each other? Anyway repair has a long tail. I am not sure by how much. It might be that a slow node has a higher chance to not get cut off.

There is one downside. The node selection aka load balancer will target fast nodes in the first place. So any miss will reduce the number of repair uploads the slow node gets. And that impact should be much higher than any long tail cancelation. I would still expect fast nodes to benefit more than other nodes.

90

Your observation might be correct. Something I didn’t check is if the offline notifications still work. Between all these cost reductions we might have broken the notification emails. I would expect that to increase repair traffic.

Can anyone in the group confirm that by chance? A node recently offline for more than 4h maybe?

91

In my opinion, we can speak about cost reduction only if there will be no /24 rule, but one node cant get several pieces. It will lower our costs also.

92

I think the /24 rule is the main reason we have 30k+ nodes and not 300k+. There are ways around it: but the diversity it encourages is crucial. Removing it would be a mistake.

Select doesn’t need it because there’s some minimum guarantees the hardware isn’t crap and will be gone tomorrow. :slight_smile:

But there hasn’t been any official talk about payout changes anyways (it’s just littleskunk going off and doing his own research?).

93

It is additional money every month to spend, makes network slower but it is not a problem
I dont think it will bring more nodes, especially in case on payout reduction.

94

SNOs that don’t have more IPs today… don’t start more nodes because those nodes will just share traffic: so they wouldn’t earn more.

But if the /24 restriction was gone: every new node would be considered for it’s own uploads. SNOs would want to run as many nodes as possible - to have a chance of growing faster. Node count would explode. And the network wouldn’t be any faster (as nobody added any more real IPs with real bandwidth) but the variety of nodes would decrease (just more running on the same hardware). The network would be weaker.

TLDR; I like the /24 rule :heart:

95

There is 3,577 payouts was last month and 30k nodes. So how much nodes today belongs to one person? on same place just with other IP on VPS? Major of the network are in HOME datacenters. Why it /24 makes network slower? Because traffik go thou VPS in USA and then to node in EU. Or vice versa. this makes network slow.
If you see pictures majority on big operators have 12-24HDD ped Server. Do you thin they all behind same external IP? So we have already reality when 10-20% on node operators own 50-60% of the network capacity(this is my estimation).

without /24 role all will be in equal positions. to prevent several nodes on 1 HDD it easy, node need to check HDD serial and send to storj, newer nodes will be DQ on same HDD after some time.

96

I don’t think so. There is reasons to have multiple nodes per /24…

  • Small nodes get more ingress because ingress interferes with egress.
  • Vetted and unvetted nodes are selected independently.
  • There is other SNOs in same /24.
97

One node per HDD doesn’t make any sense unless you’re running a bunch of small-capacity HDDs. For large drives, we need to run at least 3-4 nodes per HDD. So maybe not only SN should be checked but also capacity.

98

I am sure this can be tricked with virtual disks…

99

ALL end wen you HDD cant keep load, running and compaction. then it go slow and you get little data, that’s all. 2 node on one HDD running very poor, because they do lot of small reads and writes.

100

Modern HDDs seem fine with at least 6 nodes (as far as being able to keep up with iops). And layering special-metadata/small-files/l2arc on top can help.

But yeah with many nodes doing small-random-reads… there is a limit.

My guess eventually the many-node people run out of RAM? (how much memory does each node use - maybe 300MB?)

101

Not anymore with hashstore. I have tested 8 nodes per HDD with no problems. Also I remember another thread where someone running 200 nodes in one ZFS array.