Sven Slootweg (soft-deprecated) @joepie91@pixie.town

@nomis@chaos.social Oof :( Good luck!

@serge @josh0 I'd recommend looking through his Twitter feed for a bit. It doesn't take long to run into "no politics", "no CoCs" and "free speech" rants, and all the other right-wing 'cancel culture' rhetoric.

It's also not a single incident; I've seen various complaints about Kling floating around for a long time now (but have not kept active track of them), which altogether paint a picture of someone who is not safe to be around, and not to be trusted with the safety of vulnerable people.

@jonny lmfao what. I guess this appears to make perfect sense if you're a rich white dude with a residential fiber connection two miles from every server you hit and you think network partitions don't exist

@yamuis Nou ja, 'vragen'...

@Cheethoepuff I've mostly seen people use Owncast, which is decentralized in the sense that you're expected to run it yourself for your own stream (or have someone run it for you, of course).

I used it for a stream of me playing Beat Saber a while ago and it worked quite well for me. But it definitely seems more designed for "run it yourself" than for "have someone within your community run it for the whole community".

@serapath Oh yeah, this definitely would need to be an organized and deliberate thing, for basically the reasons you describe - simply building a browser and arbitrarily picking-and-choosing features wouldn't work.

@serapath So here's a fun and perhaps non-obvious one: we can actually already do this ourselves.

One of the more interesting insights I've gathered from interacting with a lot of non-computer people, is that "using multiple browsers" is a surprisingly widespread practice.

Some people do it to keep accounts separate, some people do it because different things work a little better in different browsers, and so on. The reason doesn't really matter, the point is that having multiple browsers for different 'apps' is tolerable to a lot of people.

Which means that it'd be entirely possible to simply... not implement the whole spec. To establish a restricted set of "things a browser actually needs to function for real-world applications", and only implement those, and call it done. And if a specific app needs more, users can use another browser for it.

Especially if you can find a unique 'selling point', like being faster than established browsers, or some kind of special integration, this is a viable way to gain a foothold in the 'browser marketshare'!

The main insight here is that "what people need from a browser" and "what specs demand from a browser" are not the same thing and that allows us to redefine the playing field without having to convince any standards body, as long as we make sure that we get the "what people need" part right.