Can you explain in more details what do you have in mind?

Sorry for the long response, my laptop charger just died.

In details:

• #981: There was a discussion about improving the release process, does it was resolved in release #14730?
• #2697: Why there's still no separate repository for only the rulesets? As I see, the migration process will not be so smooth for the ruleset maintainers.
• #1291, #1292: @J0WI has already mentioned that some features are missing from Chrome/WebExtension version.
• #17868: I don't see any progress in the discussion of UI/UX feedback.
• #12232: While it says that this extension using 40-80 MB of memory, mine is using over 120 MB.

I suppose the issues above can be resolved by making "beta_2.0" (or something like that) branch and apply backward-incompatible changes there.

Also, maybe it's better to make some things from scratch than rewriting that.

Currently I see 90MB memory usage.

Generally, I like this idea. I personally feel like the extension (not rulesets) development is slowing down to crawl. We should discuss it with actual EFF employees though. I can try developing (locally, I don't want to develop my own "competitor" to HTTPS Everywhere) my own attempt on how the extension could work if it were possible to rebuild it from scratch using today's best practices. I also want to take advantage of the fact all currently targeted browsers (including Tor Browser) support ECMAScript modules natively now.

One can mention #17143 as well

#12232: While it says that this extension using 40-80 MB of memory, mine is using over 120 MB.

I might have missed something but I don't see any claim on the memory usage in #12232 matched your description. I am guessing that you are referring to #16092. This measurement calculate the theoretical memory consumption by the rulesets, not the extension itself.

I am open to the idea of refreshing the extension since the current code have some assumption which limit the performance. I believe this will also imply a breaking change to the ruleset format. If #17143 (comment) can be resolved, we should rewrite the whole extension in WASM, such that the improvement can be very obvious. However, I am concerned that #17268 will limit our effort to fully rewrite the extension given the uncertainty on the Google's side.

@cschanaj I think we should use #17268 as an opportunity to grow. Brave devs have confirmed they will not introduce anti-adblock code and will neutralize such code if it will be added by upstream. Currently there is no decision for Ungoogled Chromium.

@Hainish can you join the discussion?

I've closed #981 since the release process has improved significantly since this issue was opened.

I will leave #17868 until @zoracon is back in a few months.

#12232 will be greatly improved by the addition of the WASM module: #18093

#1292 is not currently prioritized.