My guess is that short term, we’re not going to get a hit in payouts. This month is looking like a 1TB ingress month. That’s gonna fill up smaller nodes quickly, directing even more ingress to larger ones. They can’t really afford to lose capacity right now as @Vadim mentioned.
Actually, it’s quite fair for customers to pay if customers want any reliability. Test data are what Storj engineers can use to develop features and evaluate whether they function correctly at scale. The only question is what should be the ratio of test to customer data. Maybe some rather insignificant value like 5 to 10%, maybe more.
What I’d assume though is that in the long term it should be somewhat routine to run tests involving, let say, 1PB of data.
Sure at a reasonable eventual rate. But you can’t expect customers to pay double if half the data is test data. And it’s not the customer who can choose to optimize and minimize the use of test data. So I think the responsibility to pay for that should for now be with Storj. Basically it should eat into their margins so they have an incentive to not go overboard with it.
1 Like
Did Vetting process has been modified somehow? When I started 2 years ago, it was said that only 5% of the normal traffic is directed to new nodes in vetting. This summer I think it was still 5-10%. Now I just started a new node and is like it fills with 1TB/month, and is only 2 days old. And the number of new nodes/day is huge. I didn’t check my other nodes, but I’m pretty sure the 1TB/month is not 5% of ingress traffic.
I am not suggesting paying collateral to start the node like SIA. I am suggesting holding back payout as a collateral. So no need to pay anything. I would not be hear, if that were true 
Love ixSystems! And you did a great job implementing STORJ into TrueNAS. But ixSystems is a partner, not a customer that will pay us for storing data. Don’t know the other guys.
5% of all ingress goes to unvetted nodes. If 5% of nodes are unvetted, you get the same amount of ingress as on any other node. Technically you can even get more data than on a vetted node.
I guess we found another element that should probably be fine tuned as the network grows. At some point unvetted nodes will account for less than 1% of the total number of nodes and there really isn’t a good way to assign a fixed percentage of all traffic to go there. Instead it should probably calculate how much of each upload should go to unvetted nodes based on vetted vs unvetted node counts so that there actually is a static rate of say 10% of ingress on unvetted nodes vs vetted ones.
It’s a partner that will potentially bring in a lot of customers though.
1 Like
yeah, but the reason I’m saying this is this exponential growth curve in data storage.
vs this linear growth in active nodes.
That’s not gonna work if those trends continue. Though the first graph does show that free space doesn’t really drop on nodes, possibly suggesting that many nodes expand when they start to fill up. (I know I do this)
Niceee… keep me in vetting more 
.
Good job Storj Labs for attracting new customers. In the long run, nodes will multiply and storage will increase, so I think it will keep up with demand, stabilising the profits too, but for now is awsome. I don’t have where to put more nodes though…
yeah. An ingress is pretty crazy currently.
For vetting, keep this in mind.
Interesting change there. The number of unvetted nodes dropped significantly again. So yeah, ingress is pretty good. Since about 13% of nodes are unvetted, you can expect about 40% of normal ingress on an unvetted node currently. But these numbers include inactive nodes and full nodes. So it might be quite a bit higher than that.
What do you think about “different payout plans for SNOs”, that can be opted in by SNOs from month to month, that offers different plans for engress and stored space. Something like:
Plan A. 3$ for stored space, 1$ for engress.
Plan B. 1$ for stored space, 10$ for engress.
Plan A can benefit full nodes, with little engress, and will encourage them to stay on and don’t delete and restart a new node.
Plan B will benefit semi full nodes with a lot of engress.
In theory I think it would be cool. In practice I’m afraid this just allows node operators to make it not profitable for Storj. They are also making less money on the data on your node once it’s full, so what are they gonna pay that $3 with if the storage income doesn’t cover it?
I’d say differentiating like that only makes sense if you also differentiate customer payments based on specific service models and then node operators can pick what service models to provide data for. But then you wouldn’t just be able to twitch based on existing data you already store.
1 Like
Not so sure about that. I will bring us nodes, but data?
If I wanna backup my TrueNAS, why not use Backblaze instead of STORJ? It is only a little bit more expensive but they have a higher chance to still exist in 5y. Which brings us back to, why STORJ is to expensive right now for cold storage backups 
This was proposed many times, with—if I remember correctly—no clear answer from Storj yet.
This is a natural proposition, cloud companies tend to offer many such trade-off levels (compare AWS with their storage classes, from S3 Standard to S3 Glacier Deep Archive). I suspect Storj is just too small to attempt to optimise services for many different tiers, and so it might be better to just focus on providing one tier that works well. It’s more difficult for Storj than for centralised services to offer many storage tiers.
Maybe because you can have both a storage node offering storage to others and back up your personal data on other nodes, making it a sort of disk space exchange. That was one of the ideas for Storj some years ago.
I’ve been trying to wrap my mind around how the Storj business model could ever work for quite some time, and tbh I don’t think it can. Let’s quickly look at https://storjstats.info and estimate what Storj’s income is right now:
There are 3 satellites that actually store production data, AP1, EU1 and US1. Together, they store 8,300TB of data currently. So that makes 33,200$ in monthly income for Storj. In addition, we have egress, which in the past 30 days was 2,731.1TB which equates to an income of 19,117.7$.
This ignores the fact that Storj probably gives discounts to big customers.
Let’s assume that Storj pays all the node operators from their Storj reserves, then they can keep the whole 50k USD.
From this they need to pay satellites and their developers. Obviously this isn’t even enough for a single developer. So they need to scale immensely, getting to (hundreds of) exabytes of data stored (and node operators offering this storage) before they run out of Storj reserves while simultaneously heavily reducing node operator rewards so that they can earn something. I don’t think this will work. I’ll enjoy being a node operator while it lasts and is at least a bit profitable, but I won’t invest a penny into hardware and keep a very close look on when it might be profitable to spin down my server disks instead.
1 Like
That was the plan all along, as I understand it. The key to making it work is in execution, and this is what we (attempt to) discuss here. Are you worried about some specific elements of this plan?
Yes, I am worried that we are only in the beginning of the petabyte phase and they already need to reduce payouts. I think their runway isn’t long enough that they will become profitable before money/Storj runs out.
1 Like
It’s… uhm, expected to have to correct the course? Can’t plan everything upfront.