Sven Slootweg @joepie91@pixie.town

@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.

@frumble@chaos.social Also, more directly pertinent to the situation: why argue against people doing a helpful thing they are already doing, in the first place?

@frumble@chaos.social It's not that simple. A big part of how the situation ended up where it did, is precisely the complexity of the project - and the history of Firefox means that it has not only accumulated a lot of technical debt over the years, but also that the design choices made in its development process were often optimized for short-term results over long-term maintainability and sustainability.

Or to put it differently: if you try to take over a project that was developed to corporate standards, you will need to emulate all of the same corporate dynamics to be able to do that, because those are the assumptions about the environment that will have been encoded in the design. That just sets us up for the same kind of failure again, 10 years from now.

There is therefore a significant benefit to developing a new browser engine from a different set of principles; those of a community-led project where you cannot assume the existence of funding, which recognizes that sustainable maintainability by a potentially small set of maintainers is the most important metric.

(Also, the oft-repeated "don't rewrite your software" advice is related to rewriting for *technical* reasons. That is not the context here, and so you cannot just port over the rationale 1:1 and assume it to hold true.)

@serrebi A little further investigation turned up these two threads:

https://github.com/servo/servo/issues/4344
https://github.com/servo/servo/issues/31321

It seems that the situation can be summarized as "screenreader integration is wanted but going to be a lot of work and nobody has really gotten around to it yet; and the off-the-shelf library for it isn't feature-complete enough yet to support the complexity of a browser".