Exactly this. It isn't even really "stitching" as YouTube videos are served as a series of short chunks anyways. So you simply tell the player that there are a few extra chunks which happen to be ads. There is no video processing required it is basically free to do it this way on the sever side.
So don't watch it? I would rather the platform all all legal content then trying to be the morality police.
I would also prefer to use third party recommendation engines (like people posting on Lemmy) then one run by any particular platform.
We don't need a new platform. We need 20 new platforms, and authors can post on whichever ones are best for them. Have real competition and real incentive to be better.
I feel the same way. Or felt. It is a wonderful platform that will let anyone upload and share videos at absolutely no cost. Video hosting isn't as expensive as we are often lead to believe, but it isn't cheap. Especially if you want to provide a great experience like different resolutions and qualities.
I used to subscribe to YouTube Premium and was quite happy about it. However they slowly made the platform worse and worse. At some point it hurt to give them money, even if the subscription was "worth it". I just didn't like giving money to people destroying a great platform.
Luckily YouTube still supports RSS. This means that I can easily mix in other video platforms with no bother. I now subscribe to Nebula and have 35 subscriptions there. I also have a handful of PeerTube, video podcasts and other self-hosted creators. It isn't the "majority" of my subscriptions (Apparently I have ~200 YouTube channels that I subscribe to, but a huge number of them are dead, second channels or incredibly infrequent.) but it doesn't matter. All of my subscriptions come to the same "inbox" and it doesn't really matter what platform they are on.
It's not "inherently insecure" at least not to that degree. (Once could argue that lack of E2EE is insecure.) If you stand up an unrelated instance you shouldn't be able to access private messages that don't relate to an account on your instance. So only bugs in your instance, or your conversation partner's instance, will be able to leak those messages.
For software to run on a computer it needs to speak the computer's "language". This is typically called "machine language" but differs across different hardware. For example most modern Intel and AMD processors speak x86_64. This language has ways to express different operations such as "add these two numbers" or "put this CPU core into a low power mode". This is the fundamental way that software works, but running in this language.
There are languages that are completely different, such as ARM which is very common on mobile devices and is the language used by Apple's new M chips. These have basically nothing in common with x86_64.
These languages also evolve over time. For example x86_64 is a significant extension to the older x86 language. For the most part this is fine, it is like the CPU now knows more words, if you use those new words the new CPU will understand them, but older CPUs won't.
RISC-V is a new machine language. What makes it interesting is that it is a free and open specification. This means that anyone can create a new RISC-V CPU, unlike x86_64 where you need to buy a license from Intel or ARM where you need to buy a license from the ARM corporation. Most people think that this openness has major benefits, for example now anyone can create a new processor which may be better, rather than having innovation being stifled by licensing costs (if you can even get a license) or needing to create their own machine language and require huge amounts of effort to migrate software to it.
Note: It is important not to confuse "machine language" with "programming language". When people write software they very rarely write code in machine language directly. Usually they use a programming language which is then converted into the machine language of the CPU it will run on.
Actually a sailor makes sales.
If you just need to intercept the keypresses in webpages then you can inject a content script and handle these. However there is no way with the new WebExtensions API to intercept browser chrome events.
Additionally there is no way to delay events. So if you want to suppress both shift presses you will struggle to do that. If you are ok to let the first one go through suppressing the second one is trivial.
Because proprietary JS is non-free software and they are against running non-free software.
I wonder if it could be something like adding a Link: </post/1234>; rel="activitypub" header or <link rel=activitypub href=/post/1234>. Then a browser (or browser extension) could detect this canonical ActivityPub URL and offer to open it in your configured instance or app. This is basically how RSS feeds work.
Counterpoint: RCS shouldn't exist either. We should use something that isn't tied to our mobile service providers.
To buy the next website that people are making fun of him on.