**** Hoping that #Google/#YouTube will fail, could help to destroy the best of the Internet ****
I'm seeing a lot of people apparently rooting for Google /YouTube to fail, to be split apart by the government, to be intensely regulated and otherwise subject to massive fines and other actions.
It's difficult to emphasize how shortsighted a viewpoint this is, for among the pantheon of Big Tech, on balance Google is very much a good guy, and one of the last bastions against what amounts to a horrific takeover of the Internet by government, a takeover that is being pushed by politicians on the Right and the Left.
Is Google perfect? Of course not. Hell, there are aspects of Google I've complained about for many years, and pushed back on both publicly and during those periods that I was working inside.
But most of the complaints about Google/YT (ads, Play Store, etc.) have become overblown politically-motivated excuses to try micro-control content.
Google is bending over backwards to build an ad ecosystem that can still provide advertisers with enough info to be useful without risking people's privacy. But that's not enough for many observers. They don't want any ads. They don't want even anonymous "tracking" that can't possibly hurt users. Seemingly, they want everything for free. And often they tout the tired old "you are the product" mantra that was never true but is so often blindly parroted.
Meanwhile, government is on the cusp of imposing vast new tracking -- tied to government IDs -- requirements on the Internet in the name of "protecting the children" -- potentially turning the Internet in the U.S. into a nightmare clone of China's Internet regime, where you can end up in prison for accessing the wrong site.
You think it couldn't happen here? Think again. Pay attention to what the politicians are saying and the laws being passed in various states -- and the cases before the Supreme Court right now!
Most people who use the Net don't have a clue how much they could lose, and how quickly, if these government efforts succeed. They have been seduced by political rhetoric and are standing on the edge of a cliff that they don't even realize exists.
And unless this changes immediately, you can likely kiss most of the best of the Internet goodbye. -L
1. Big problem with Google's ad biz is the Google/FB duopoly; a substantial part of the publishing industry used to rely on ad revenue; no longer, only G & FB are allowed to make ad money now. Fortunately there is bipartisan litigation aiming a cannon at this problem.
2. You say:
>> Google is bending over backwards to build an ad ecosystem that can still provide advertisers with enough info to be useful without risking people's privacy.
With respect, I entirely disagree.
@timbray I find it fascinating how many people who claim that they only object to "bad" ads use ad blockers set to block ALL ads. They don't want to pay with money. They don't want to pay with time. They just want it all for free.
Somebody was bitching to me recently about YT ads and was boasting about an extension that blocked them all. And I said why don't you subscribe to YT Premium and help support the creators that way? And they responded, "why should I when I can get it all without paying and without ads?" The epitome of uncaring selfishness.
@lauren @timbray YouTube is *stupidly* expensive and complex to maintain, and people have no idea how much so. (And when they guess they're usually off by an order of magnitude or three) If Google hadn't bought it when we did then the service would've died.
That may or may not be considered a good idea, but if people want YouTube to exist in anything like its current form without being attached to Google then they need to cough up a *lot* of money and resources. There's no indication they want to, and splitting it out and adding in all the proposed restrictions will make it unviable. Which, again, is maybe fine with people, but if folks want it split and still working then there's a big additional cost.
Lauren knows this but very few other folks are aware of it, I suspect.
@wordshaper @lauren @timbray
Decentralized platforms for video work great for downloading content. But streaming is very inconsistent (if not mostly mostly unusable). That is also a plus since centralized services generally try to upsell downloading as a "premium" feature.
The biggest weakness of decentralized video is lack of a coherent monetization strategy. ActivityPub comes close since you have view counts which can be presented to in-stream sponsors.
If other decentralized protocols like SSB become as popular as broadcast TV, you could estimate viewship with something like nielsen ratings.
@customdesigned @lauren @timbray That's a view people take, sure, but unfortunately both scale and the network conditions a majority of the world lives with tend to make it fall over very hard in practice.
Video is stupidly huge compared to text, which is an insane amount of bandwidth and disk storage, plus CPU time to re-encode the video at different resolutions because honestly most of the world *can't* watch your video at the 1080p (or even 720p) that you encoded it, plus even more storage for those alternate versions of the video. Plus there's either the latency issues in delivery if you store it on a central server, or the increased insane disk storage if you want to distribute it closer to the end users.
It's really... decentralized video platforms right now are only useful for toy, low-usage applications. Maybe in a decade they'll be closer to viable but I suspect it'll at best be "closer to" and not "actually" viable.
@wordshaper @customdesigned @timbray I don't even understand the "streaming is inconsistent" complaint. In fact, video streaming in general works remarkably well now, even for relatively low downstream speeds, with CDN deployment helping quite a bit, of course.
@lauren @customdesigned @timbray Yeah, honestly 99.5% of streaming quality complaints in the US and EU are "your local wifi sucks" or "your geography hates cellphone towers". In the rest of the world it's ~80% those reasons with more "your mobile phone company kinda sucks".
It's very, very rarely an issue with YouTube itself. Not never, certainly, but really rarely and when it is it gets fixed for everyone really quickly.
@wordshaper @customdesigned @timbray Exactly. And I've personally watched how a YouTube problem when it did occur was triaged and repaired with great speed. Most impressive.
@lauren @customdesigned @timbray Yep. It's fine for people to not like the underlying centralization of YouTube, or the fact that Google's running it. I'm OK with that, even if it's not my view. It's just... if you want an alternative that works about the same then you're gonna spend more resources than you probably can conceive of, and if you want one that uses fewer resources then you're going to have seriously degraded capabilities.
I suspect, honestly, that most folks in addition to not understanding the scope of what youtube spends also have no idea (within several orders of magnitude) exactly how much video YouTube and the other big video services host and ingest on a minute-by-minute basis.
Podcasts do not need the centralization (especially when combined with ipfs-like localized caching). However, federated things like peertube cannot do performant live streaming.
Question: does multicast enable a more decentralized live streaming? Isn't that the purpose?
@customdesigned @lauren @timbray multicast really only works at the local network level. So no, not in this case.
@wordshaper @lauren @timbray Do you mean the protocol wasn't designed to work on a global level?
Or just that few routers actually implement it and thus is only really implemented at the local level?
@lauren @wordshaper @timbray Yes. And my question was about "live streaming", which is exactly the broadcasting model (plus lower bandwidth text feedback from viewers). For on-demand viewing, a decentralized system should just stick to podcast (i.e. download on demand in the background).
@customdesigned @lauren @timbray there is no broadcasting, as such, in a network with multiple segments. The best you can manage is one stream per end network and have a listener there that echoes the point to point stream to broadcasting locally. That’s really unlikely to save any bandwidth since in the vast majority of cases you only have one listener per end network.
@wordshaper @lauren @timbray Reading the RFCs (1112,4604,5771), the protocol creates a distribution tree for each multicast group. Packets go over each link involved exactly once - vs multiple times when clients simply connect multiple TCP streams to the source (YT et all massively replicate the sources). In particular, a small federated source only transmits a packet once, and routers duplicate according to the distribution tree to reach all subscribed clients.
It requires routers to actually implement the protocol. I'm getting the impression that blocking it is similar to lack of IPv6 - a scheme to force centralization.
One possible issue, is that the distribution tree must be updated when links fail, new recipients subscribe, etc. I'll have to check out the PIM protocol for the distribution tree.
The BATMAN-ADV protocol works for layer-2 multicast on segmented networks via a simple flood protocol. A packet is sent over every link exactly once. However, this requires each station to send a periodic packet to quickly adapt to change like failed links or removed stations. This becomes a lot of bandwidth at around 1000 nodes.
Just like with refusal to to IPv6, lack of IP-multicast implementation just means decentralized fans have to use an overlay network to do the necessary replication and routing. Since you have to join a multicast group anyway, this is not a big problem - except that it is additional software for non-technical users. I also have to look overlay networks that already do IP-multicast.
@customdesigned @lauren @timbray for this to work it would, amongst other things, require every router in every backbone network to know about every broadcast. That just isn’t feasible.
Broadcast protocols, at best, can maybe sorta work on one single network. Border routers are always going to block broadcast packets because routers outside the network the broadcast starts in won’t be keeping track of anything, and as such a broadcast packet from another network can only ever be a bad idea.
@wordshaper @customdesigned @timbray I also find use of the word "scheme" regarding the low uptake of multicasting and slow uptake of IPv6 to be inappropriate. There was no scheming involved, it just turned out that existing methods worked well enough to make major modifications in vast numbers of routers and other gear unnecessary.
@lauren @wordshaper @timbray What happens is that the IPv4 net becomes a switching fabric for the real network protocols that run on top of it. That is fine, except for users not in the know, who are shocked to learn you don't actually need, e.g. SIP servers - just connect directly to the called party.
These overlay protols tend to use crypto to authenticate source IP - which allows for secure source routing, replacing SSL certs with firewall rules, and other benefits. I see IPv8 is incorporating much of those ideas.
@lauren @wordshaper @timbray That's not to say SIP servers aren't useful for other features, like conferencing, consolidated logging or voice message services for an enterprise, etc.
@wordshaper @lauren @timbray That makes sense. And is an additional reason to run it on an overlay network, which limits the routers/nodes which need to know.
Yes, the real reason multicast was disabled was billing issues (reasonable - figuring out how to pay for things is a tricky part of engineering). So it does need an overlay network. M-bone was an early IP4 multicast network. Looking into whether internet radio (and tv) uses m-bone or a successor.
@lauren @customdesigned @timbray yeah, and then when the ramifications of having a broadcast transport in combination with huge networks that aren’t ASTs, so broadcast packets would transit forever… yeah, the basic broadcast idea was interesting but it there’s a reason that basically every piece of network kit on the planet filters them out.
@customdesigned @wordshaper @timbray One interesting aspect is that originally multicasting (to a considerable extent) was based on a typical "broadcasting" model of many people listening (or viewing) to the same thing at the exact same time. As on-demand, user choice applications came to dominate, this model became less and less useful.