The 0.7 rewrite

[Eloston]

This issue is for tracking anything related to the version 0.7 rewrite.

Here are my rough and messy notes I worked on a while ago. These notes were what I was using while rewriting, and for keeping any "shower thoughts" I had. I don't believe they were comprehensive, but I have forgotten many of the details of this project already.

If this rewrite is something that interests you, let me know on here or in the new Gitter room. We can discuss some more before work is done.

[GuardianMajor]

Happy to contribute, let me read through everything, get caught up and that way I can have some useful input for you that won't distract your work.

[Eloston]

#118 has caused me to reconsider the future of this project. Here are my thoughts:

• Given what Google has implemented so far (#118), it seems likely that they will continue to refine that feature until it satisfies the needs of most users who use this extension. In that case, we don't need this extension anymore.
• For users who desire more flexible control (as described in my notes), it may be easier to implement the ideas for 0.7 into uBlock Origin. (EDIT) In addition to being actively maintained, it wouldn't require us to re-invent (or copy) the wheel (i.e. uBO has similar underlying functionaliy to what 0.7 will implement). After all, quite a few ideas for 0.7 (namely the new configuration system) was inspired by uBO.

[GuardianMajor]

I believe that even if they decide to release this feature full on at some point, as you said refine it, there is no guarantee that it won't end up being just another bootstrap for preferring Google related content over others, meaning they will block everyone sure, but they might leave their own and partners who either pay for it or ask for it to be exempted to get through still.

Given their behavior, I have no faith whatsoever that they will actually provide an interface for it either. So it comes down to only those who can hack the CLI or whatnot to get it working, which excludes the real larger public.

I feel a nice interface that is organically developed in the wild with real world users and not just engineers would give a better sense of the general needs and how to remedy them. As many tools that started as external projects but later were adopted wholesale into the browsers themselves, this might be what spurs that initiative.

Just my two cents on it.

[Eloston]

there is no guarantee that it won't end up being just another bootstrap for preferring Google related content over others
Given their behavior, I have no faith whatsoever that they will actually provide an interface for it either.

Both solid points. That would require browser modifications if someone didn't want an extension for this.

I feel a nice interface that is organically developed in the wild with real world users and not just engineers would give a better sense of the general needs and how to remedy them.

I feel that uBlock Origin has done quite a bit in this area. Through its many revisions and tests, it has developed an interface that "just works" for non-technical users, easy-to-access and basic controls (via the popup menu) for those desiring more, and a lot more options for the sophisticated.

By integrating into uBlock Origin, however, it would not have the appeal for corporations and certain groups of users (those who want ads on sites they want to support but get deterred by uBlock Origin's intentions) as a separate extension.

Instead of integrating into uBlock Origin, we could always fork it and strip it down to what we need. It would save us from re-inventing.

[GuardianMajor]

If you want to achieve interoperability, that can be achieved simply by making the code situationally aware by detecting when say uBlock is present, and simply install itself with integration so the user can access it in one place to satisfy those groups and for the ones that don't have it and install it, it will run stand-alone. Perhaps uBlock can also work on detecting this so if say uBlock is later installed on a system that has this one, it will install and integrate as well, that would require tight cooperation of the foundation - but achievable, as many Firefox extensions have extensive interoperability and successfully maintain them.

I would however argue that we should build the solution that works before we worry about how to integrate it with other solutions. To that end, I agree with you that forking it and reducing it to the base framework would save some time and it would give us a starting point that should hopefully better inter-operate with uBlock in the future, sort of future proofing it a bit.

I'm in, let me know what you think. Plus being familiar with the uBlock code will reduce the learning curve to get up and running, so we can focus more on the "magic" of actually doing what we need and hopefully in a way that is a scalpel and not a machete :)

[Eloston]

An interesting read, but it appears my words were more precise than accurate. What I mean by "integrating" is merge with uBlock Origin, not communicate with uBlock Origin. Perhaps I should have used "implement" instead of "integrate".

I don't see any benefit of communicating with uBlock Origin since both projects operate on different parts of a web page in different ways. Merging would have the benefits described above, as well as potentially having more people working on code. But, I'm not certain if gorhill would accept such a feature into uBlock Origin (it mainly depends on whether he considers disabling HTML5 autoplay and autobuffering a form of "blocking"). On a side note, an extension like ScriptSafe may be more appropriate for a merge with, but ScriptSafe isn't very user-friendly.

EDIT: Should note that I'm still leaning towards forking uBlock Origin.

[GuardianMajor]

No, I got what you meant. But in consideration of the other points you raised that some groups won't be happy with that blocking philosophy and might rather just want this. Also that in enterprise solution they might wish a leaner solution. So with that consideration, I suggested the integration. Personally I am fine being on its own.

I understand and agree. I think there is still benefit to forking the base to help more rapid building until we get it to a stable solution. Then we can always tidy up the code and modify its framework once it is done because with the big picture complete, it will be easier to compartmentalize from there.