this post was submitted on 13 Jun 2024
606 points (96.5% liked)
Technology
59105 readers
4009 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
If the file is that poorly seeded, and therefore extremely sparsely watched, then the laptop with a broken screen in my closet can serve it to anyone who wants it.
The only reason we need a scalable system, is to handle high demand / broad appeal media and in that case, what you describe WON'T happen.
For low demand media, https off my mom's coffemaker will do just fine.
That means anyone posting 100-200 video to youtube today, can easily handle all these situation with less expense than the price of whatever camera they filmed the content with to begin with.
Youtube only exists, because us, old internet fucks, got lazy and relied on google for mail and video.
We could EASILY EASILY EASILY done it ourselves.
A service people want to use is typically one with redundancy and high availability. Your laptop could overheat, have a drive failure, spontaneously lose its wifi connection, or a million other things. It's fundamentally unreliable.
Scalability isn't just about distribution. It's about reliability and convenience - two things your system as described lacks by design. A video file that no one but you has ever seen has the same exact degree of accessibility as one served to millions.
This is the copium talking. If it had been easy to do and monetizable, it would have already been done. That's the other part of the problem here. There is no incentive for anyone to use this system to consume or distribute content other than to decouple from Google. Opposition to an existing service is not enough of a motivator for people to use a system. It has to provide some comparative benefit that outweighs the cost incurred by continuing to use the other service. The big thing that Youtube has is, obviously, content. Exabytes of it. Your new service would have...nothing. We have left the age of services starting up and gaining massive movements of people behind them. We are now in an age of the internet in which the inertia of existing services will carry them decades into the future. Youtube is now too big to fail, and too big to be replaced.
We are in the age of the toy internet, it is all about to crumple like a house of card bought on cheap credit and unviable business models. Youtube is not long for this world and nobody will miss it. The only question is how much of it Archive Team can save before if goes up in flames. Well, the good parts of it, that's easy but can we save the garbage too, I'm not sure. Take any channel on youtube and its creator can easily serve it's entire catalog out of a obsolete chromebox with two usb sticks on the side. Even as small as a terabyte would still be mostly empty space. Youtube was built defective by design using 1970s ideology, it is immensely wasteful.
I want to see how you can serve thousands or millions of people with a Chromebook in your closet. And if you say p2p, that doesn't deal with spikes in demand and a lot of old content will just vanish even easier than on YouTube. Also it would rely on people being willing to seed.
The main limitation is the 1 gigabit network. It can push out 260 3megabit streams or 50 15megabit streams at the most.
That's already an enormous amount of concurrent viewers that covers 99% of content on youtube.
To achieve this, you can't be wasting processing power anywhere, a straight copy to network from pre encoded files, no live transcoding.
No scripting, no encryption either. If you really need that, which you almost certainly don't, then install a recerse proxy on your openwrt router.
Now, if you want to scale, which almost no video really needs, then you'll send the client a script. The client is a source of inifinite scaling, compute and bandwidth.
Each client just needs to rebroadcast two streams of the file.
As excess clients connect, you tell them to get the stream from the stun/turn server. This punches through both sides of the nat. And puts two clients in communication. First client sends its copies of the received stream chunks, with preference from the beginning of the file. One client can get the stream from multiple other client and once it has a few stream chunks in the cache it can serve them to new clients.
It doesn't take many doublings before you have more bandwidth than the whole internet. All the logic for organisation, hash checking, stream block ordering etc etc is a small text file from the server, signed by the server's certificate. It runs entirely inside the client's browser.