Stork may have some properties of a CDN, but it’s not a CDN in the traditional sense. Their marketing also doesn’t claim this. Compared to other storage solutions without CDN, the performance is great. Now you could call that creative language and I would agree, but it’s not necessarily wrong.
Though some of the comparisons with large established platforms just seem unrealistic to reach for. Companies who pay massive amounts for peering agreements or even hosting cache servers at ISPs are always going to be a step ahead. But also costly. The upside is that Storj doesn’t necessarily need peering agreements because the decentralized nature avoids bottlenecks already. But they can’t possibly beat cache servers hosted at ISPs.
Servers are hosted at interchanges or exchanges at data centres for a reason as there is meters between all the connected servers of the world via Fibre uplinks @ 100GB+.
Let’s make sure we don’t make misrepresentations of the product that go against the wording of the product.
Are you a developer? Or a holder?
Try to stay objective to follow the title, Video uses CDN’s, your own server cache demo made using NGINX + a few servers would have better performance than 2+ seconds TTFB.
Heres what I found in 1-2 minutes of looking around the website.
Node operator and enthusiast developer. I wouldn’t call myself a holder. I get paid in STORJ, but I see that as a means to an end, rather than an investment.
I guess they do mention CDN-like performance, which I agree is a stretch.
To be honest, I bother little with reading the marketing language. I’m more interested in the white papers and design docs. There are properties of CDNs that the network has (mostly when used natively) but ttfb isn’t one of them. Distribution and throughput though, yes.
It would actually be cheaper for Storj to use R2. Which is why it’s ultra important to reduce latency for video, as R2 cannot compete on FTTB if storj was tuned for extremely fast loading from cache times. But I guess CF CDN (Free with R2) + R2 for $0.015/GB is still probably faster for FTTB and cheaper.
I’d trust the SLA & terms of storj more though, good god do CF love to boot people randomly.
Believe there would be more money in distributed CDN as a service than storage and storj has a huge head start. But latency & load times for media are extremely important.
Just for example, if you’re serious about video, and you’re profitable or a media company that will be profitable, you’re thinking, Akamai (Binge, Disney+, Foxtel, HBO Max, Maybe Netflix in certain regions), Cloudfront (integrated with S3, Netflix uses S3) etc Probably less Bunny, Cloudflare or Google. Maybe R2 will change that. But Disney surely is not going to move their libraries from S3 to R2 just because the egress is free, they’re hyper tuned these companies for delivery, every ms counts in tens of millions of dollars.
R2 is definitely not meant for the scale of anything close the video platforms you mentioned. They’re really cagy about their actual limits, but you can expect to be booted if egress consistently outpaces the stored amount of data. Their free egress is also kind of shady, as they still charge per operation. And in a streaming video context, I really wonder whether that ticker goes off with every new section of video requested by the client.
Now I’m not gonna claim Storj is ready to deal with customers of that scale either. But I think there is potential to get there. Check out page 63 of the white paper. https://www.storj.io/storjv3.pdf
It describes how automatic demand based scaling could be implemented. Since this whitepaper was written, Storj has already created functionality to direct pieces to a certain geographical area and this could in theory be used to do location based on demand scaling. Which could be really powerful for TTFB improvements. Especially if they are able to also start tiering nodes based on response time and put time sensitive data like video streams on the fastest nodes in the area. That would further incentivize node operators to speed up their systems as well.
I haven’t hear them mention this feature much lately, but I’m still hoping they plan to implement it to expand the types of use cases Storj can serve. Features like this could basically give the network native CDN like capabilities. (btw, I sure hope the part about pausing access temporarily can be avoided. That doesn’t really sounds acceptable.)
There is no egress limits on the developer terms, because the locations are 100GB+ links, they are clear about this in their discord. Reads are category B and don’t cost much to anything per read. It’s insignificantly small, would be dollars, maybe max hundreds of dolalrs in PB scale.
The cache to the CDN (Also free) is where the terminology from legal might be up for interpretation, but the R2 product is not under the same CDN caching terms, it’s under the developer terms, it’s free without egress limit, they say (CF), in their terms & in their discord, and from their CTO on product hunt.
But if you really push it, you might get an enterprise call. Too which, is common at PB+ scale. That’s a lot of data moving.
I do hope to see Storj answer for TTFB, they’re obviously working on it.
