If you used something like ipfs, syncthing, or generic
torrents you could easily distribute anything you want at
large scale at no cost, as long as people were interested
in having it.
The problem there of course is the "as long as people were interested in having it" part. You can publish stuff for free on Freenet, but to a first approximation, nobody actually uses Freenet. If a torrent/magnet URI runs out of seeds then it dies forever, unless you have a way to contact former seeds and beg them to give you a copy, etc etc. Bandwidth costs money, and always will. Distributing files costs money, and always will.
The UX of peer-to-peer file sharing will always be more complex than "go to this WWW URL" if just to avoid the free-rider/spam problem.
> "but to a first approximation, nobody actually uses Freenet"
There's a very good reason for that. The people that know about Freenet and could promote it won't because of the issues it has with CP. Due to the distributed nature of the platform, and the high volume of CP that is supposedly hosted there (I've never used it, but that's what I've heard) you basically can't use Freenet without hosting CP.
Regardless of content, my biggest technical problem with Freenet is that it's a cache, not storage. You don't know when something is going to disappear. Link rot is even more unpredictable on Freenet than the open internet, and if you upload something, you don't know if it's going to need re-uploading.
There are a collection of private trackers run by motivated volunteers and paid for with meager donations which have collections far superior to the best paid services or archives anywhere or at any time in history.
They do this by erecting and maintaining virtual economies where what you can get is limited by how much you've shared.
You don't really need 100% uptime trackers, DHT lets you do peer to peer file discovery. There are trackerless torrents, the only problem being how you get the torrents in the first place, but all that takes is a magnet URI from the original uploader / creator somewhere.
So, you're suggesting that SoundCloud seeds all the files instead of offering the download option. Perhaps this could work if "play-in-browser" vs "download" ratio is not too big.
I haven't actually kept up to date recently on the project, but the ML is super active. I believe they now have a working localforage backend to store torrents - the implementation already works flawlessly, and there is a hybrid client in the same node package family that can seed the same files to both webtorrent cleints and traditional UDP clients.
But it is extensionless and seamless and just uses webrtc data channels and websockets.
There are implementations which approximate bittorrent written entirely in javascript. It's possible.
However, I really doubt infrastructure costs dominate SoundCloud's money problems. Significant, yes. But a major engineering overhaul developing an entirely different architecture for distribution which might either not work or alienate customers is probably not an appropriate move when in that situation.
Maybe it could be something to do as a clean shut-down to help things live on (an amazing thing when dying companies do things like this to end well) but not ... expected.
Mathematically, as the download count for each file approaches 1.0 (or even lower), a privately-funded torrent seed server starts to look more and more like a traditional file host.
Soundcloud & co require the content provider to upload the content too. If you want to share the content, provide the seed. If you don't want to share the content, don't upload to soundcloud, don't provide the seed.
If the provider decides to shut down or no longer renews the licence for a piece of content then the content will disappear. Torrents on the other hand only require that at least one seeder has to actively seed the content. Soundcloud has to host the initial seeder anyway which means that they are in practice not worse for longevity than a central file server as long as soundcloud continues business.
> The problem there of course is the "as long as people were interested in having it" part.
The problem is that ISP are actively trying to constrain torrents with deep packet inspection or ongoing surveillance of other centralized bodies. Torrents would see a much more widespread use if such barriers were removed.
> The UX of peer-to-peer file sharing will always be more complex than "go to this WWW URL" if just to avoid the free-rider/spam problem.
For the end user, clicking on a torrent has zero UX issues. That's why torrents took off so easily in the first place, and why they still exist nowadays.
The UX of peer-to-peer file sharing will always be more complex than "go to this WWW URL" if just to avoid the free-rider/spam problem.