How is that not a split of the network? You’re literally separating CDN traffic out to a different satellite and different set of nodes. My point is that this isn’t necessary at all if automatic scaling of RS availability is implemented. All nodes could participate just like they do now.
As for pricing, CDN pricing usually deals only with bandwidth. This makes sense as the data replicate and distribution strategy the CDN takes has massive impact on how much storage is used and really shouldn’t be the concern of the customer. I would say the same applies to Tardigrade CDN. Storj Labs should be responsible for how dynamic scaling and distribution works and shouldn’t charge customers more just because those steps require more storage on nodes. Since CDN’s would usually lead to the vast majority of costs being related to egress anyway, that makes sense for Storj as well.
So my suggestion would actually be to ditch storage pricing for CDN use cases or maybe stick with storage pricing as if there wasn’t additional storage being used to upscale availability. Considering $0.045 per GB, that’s actually competitive with other CDN’s. This pricing only falls apart when you look at the volume discounts on offer by the competition. Though I’m sure Storj Labs could offer such discounts as well to a certain extent. This means the pricing model actually already fits CDN use cases quite well. Which is even more reason not to separate the two on the network level.
What’s most important is to actually have a browser based uplink to recombine the segments. I think the implementation of QUIC which is being worked on right now could serve as a nice communication protocol for that. The way access grants work now, a read only access grant could be created for the specific files and used by the browser. Still quite a few challenges to overcome. There was a nice post outlining those challenges here: JS library for the browser - #7 by jtolio
Another route would be to use the multi-tenant gateway hosted on multi-region cloud as the http endpoint. This is especially important if you want to enable client applications without a full browser to be able to download files as well, like podcatchers for example.
I don’t see how that’s going to change. When delivering lots of small files, it’s all about latency. And latency is pretty much the only issue you can’t fix if you rely on a world wide network of nodes on consumer connections and hardware. There is no way to compete with the performance of cloudfront and akamai on that. However, there are plenty of use cases for things like videos, podcasts, file sharing, and others, where the importance shifts to bandwidth. And Storj can definitely compete on that front.