Is the real concern about forking the userbase and ecosystem, and the fork won't have the critical user base to become self-sustaining?
Edit: added paragraph for clarity.
But consider this, from Debian's ca-certificates package:
---
This package includes PEM files of CA certificates to allow SSL-based applications to check for the authenticity of SSL connections.
It includes, among others, certificate authorities used by the Debian infrastructure and those shipped with Mozilla's browsers.
Please note that Debian can neither confirm nor deny whether the certificate authorities whose certificates are included in this package have in any way been audited for trustworthiness or RFC 3647 compliance. Full responsibility to assess them belongs to the local system administrator.
---
So as long as Mozilla allows OSes, and presumably other browser forks, to benefit from their CA vetting and monitoring activities ...
There really is a lot that does, or should, go into browser development and maintenance.
Now it looks like it will once again break (this time permanently).
I'm in the same boat with other folks. Why use Firefox if it's just a poor man's Chrome clone?
Mozillas browser.html project may be helpful too, but it seems to be a bit too experimental for now.
For an extension to get support, we need to rank it as in-demand, and then try adding it to Brave to see what missing chrome.* APIs it might need. https://twitter.com/bravesampson is leading this charge, using https://github.com/brave/browser-laptop/projects/1 to keep track and engage with developers.
For future extension APIs that go beyond the chromium ones, we won't support XUL, but I'd like to take advantage of our Muon (https://github.com/brave/muon - we forked Electron, because security) React.js-based front end.
In 2Q2017 I'll hope to have more to say about extensions and where we'll go. Interested extension developers are welcome now to join our https://community.brave.com/ discourse. Thanks.
I was not talking about the type of extension that allow to do some common things based on small api created specifically for that.
I am more interested in extensions that get full access to existing react components, and can modify the browser ui in arbitrary ways, e.g. by adding splitview similar to what cloudy has, or adding proper tabs on mobile instead of carousel.
Brave UX will evolve but slowly and without big changes that break too many users (Australis). Still, we need to be able to change our UX. So if we have powerful extension APIs into that UX, we can't promise never to break extensions that use those APIs in ways that become unsupportable.
All we can do is try to co-evolve nicely and cooperate better. I don't see a silver bullet here, but I do see how Mozilla has burned a lot of add-on developer good will -- and we won't make that mistake at Brave.
I seriously looked at it when australis happened before classic theme restorer was stable, but at the time they seemed to have no interest in anything but desktop windows. I suspect a single-platform browser (especially when the platform is windows) is a non-starter for most people.