The future of content filtering (declarativeNetRequest, Manifest v3, and beyond)

[joey04]

This is both an FYI and some follow-on questions.

The FYI -- For those who haven't yet heard, Google is planning a severe reduction in extension capability for blockers and other content filters. Their current draft of changes includes deprecating the webRequest API and replacing it with declarativeNetRequest. This will only permit a fixed number of purely declaritive rules in a single json list. Moreover, the browser will have final say on what requests get blocked or redirected.

For more info, see this uBlock Origin thread. It has all of the relevant links.

I have two follow-on questions:

1. Is there any interest from the developers here to integrate a filtering engine? I realize this is a big request, but the new API will eliminate the possibility of uBlock Origin, uMatrix, and other robust extensions. Since this project recommends those on the wiki, it will impact this project and its users. My idea is to modify Brave's engine, which is already integrated but has only AdBlock Plus level functionality.

2. If not, can you recommend how to undertake such an effort? I have experience working with large C++ codebases, but nothing browser-related. Any tips, gotchas, etc. would be appreciated.

[travankor]

https://www.bleepingcomputer.com/news/software/google-begins-testing-extension-manifest-v3-in-chrome-canary/

[aluo-x]

@Eloston

So it seems like Google is intent on delivering Manifest V3 now, rendering extensions like ublock-origin and uMatrix far less powerful. It seems like there are a few possible choices, in terms of difficulty:

1. Do nothing, and in the future limited adblocking can happen with declarativeNetRequest with up to 30,000 static rules, and 5,000 dynamic rules. I suspect in the future most people will migrate to this option.

2. Port over the adblock engine used by Bromite @csagan5, with additional modifications to allow for filter subscriptions etc. Seems like a fairly reasonable patch, and self contained.

3. Port over the adblock engine used by Brave, which seems to support easylist, and ublock-orign style filter lists, and seems to include for subscriptions. Doesn't look too bad, with around 10K lines of code in the core, and maybe 1K lines in the C++ ffi. Some sort of UI will likely be needed, but that could potentially happen outside the scope of this project.

4. Use any Brave patches once released to restore Manifest V2, .since they seem to indicate they will patch it out eventually. However, it is uncertain if extensions for uBbock-origin will continue to be developed for such a small minority.

[Eloston]

Option 1 is viable. But this will happen by default, so it isn't really worth discussing.

Option 2 and 3 could also work. But first, I'd like to know more about Bromite's adblock engine so we can compare them.

I'm also fine with Option 4 if it comes to fruition and it doesn't break any existing functionality.

[emanruse]

Having merely "ad" blocking is not enough for privacy and security. uBO does more than that. uMatrix can do even more than uBO along the lines of blocking 3rd party requests and type based ones. That is what we need to have in future too.

IOW: simply supporting "ad blocking rules" (which some other browsers do) will not be enough to preserve uMatrix functionality.

Long term: I wonder how hard it would be to "translate" uMatrix to C/C++ in order to have a browser which has that functionality built-in. Then that would not depend on what is available to extensions (which may be even worse in future). Additionally it would be more efficient (CPU wise) as the functionality would not have to pass through layers of JavaScript etc.

[Eloston]

Long term: I wonder how hard it would be to "translate" uMatrix to C/C++ in order to have a browser which has that functionality built-in.

Probably difficult. I suspect that it took Brave developers a few weeks worth of full-time work to implement the first iteration of their general-purpose blocking engine at the very least.

Then that would not depend on what is available to extensions (which may be even worse in future).

It might be easier to maintain custom extension APIs, but that depends on how much of the underlying components Google will be changing. However, would it be useful to augment Chromium's extension APIs to match Mozilla's WebExtensions? I don't know what Firefox's extension ecosystem is like.

[emanruse]

@Eloston

It might be best to consult @gorhill.

[csagan5]

I am following this discussion with interest however I do not think content filtering is something that ungoogled-chromium should focus on: it can, but then it would be best to start a separate project just for that part as it is potentially huge compared to the rest of the patches.

The approach I chose for Bromite is the least painful/more practical to maintain: to follow upstream. They have developed a content filtering engine (please go make some reading about it, it's quite advanced) and any alternative will always have less manpower behind it. It is also possible (and not surprising) that the subresource filter engine will be radically changed in the future, for example once upstream takes over the "game" of content filtering, having practically destroyed all extensions' competition. The current iteration of this engine can be used without any privacy compromise (it is not tightly integrated with cloud services etc) and that is why I chose it; if this fact would change (overal several development cycles) then Bromite would have to go back to the drawing board in a discussion similar to this one.

If I were to look for a content filtering solution (either for Bromite in the future, given the above-described unfavourable scenario or for ungoogled-chromium now) I would stay with the Chromium-based engine which has the best maintenance/support.

I made a list some time ago here: https://github.com/bromite/bromite/wiki/AdBlocking

The choice seems to be between SWE WebRefiner and Brave; they both are very unfriendly to integrate because of the commits mess (no clean patches), and the former was abandoned IIRC.

If someone knows about other adblock engines for Chromium please edit that wiki page and mention them in this discussion.

In conclusion: picking Brave's engine, or any other, or developing hybrid solutions as mentioned above (unrealistic) are IMO all worth of a separate project or sub-project.

I suggest "project" because you would absolutely want contributions if something like this was ever started, and it would be best that multiple FOSS browsers use it rather than a single one.

What would such project cover?

If using the subresources filter engine:

• (desktop) patches for the UI to allow adding filters in AdBlockPlus format
• (android) patches for the UI to allow managing filters (I developed a very simple one, with one URL edit field, for Bromite)
• (core) patches to convert them on-the-fly to the subresource filter binary format
• possibly other patches to add functionality, you can look at Brave's features for example

If using Brave's engine:

• basically cleanup of Brave's patches so that they can be used for desktop/android

@thestinger what is your opinion about "framing" the development of what is being discussed here? I assume it's also not something strictly on-topic for Vanadium but my thinking is that if there was a separate project about this, multiple browsers would be able to benefit from it.

I'd like to know more about Bromite's adblock engine so we can compare them.

@Eloston the engine used in Bromite is exactly the one used by Chromium upstream, with little changes. The biggest change I had to develop from scratch was a mechanism to download filters without using extensions, you can find relevant information in the URLs I have put in previous comments.

This was also documented here and here at time of release.

• Port over the adblock engine used by Bromite @csagan5, with additional modifications to allow for filter subscriptions etc. Seems like a fairly reasonable patch, and self contained.

@aluo-x there is no Bromite adblock engine, see above link. The patch is only for downloading updates in a simple and secure way without using the extensions system. The modifications I did to the subresources filter engine are minimal (removing unnecessary safe browsing integrations and other types of navigation throttles).

[emanruse]

I do not think content filtering is something that ungoogled-chromium should focus on

ungoogled-chromium is about privacy.

Content filtering/hiding does not (necessarily) improve privacy. It may be cosmetic or partial.

However request blocking can give privacy and that aligns with this project's overall goal.

[csagan5]

@emanruse by the same reasoning we could add VPN or TOR capabilities to ungoogled-chromium. My point is that it is a non-trivial feature to develop/support/maintain and cannot be simply added as a "patch" or a few patches; see my previous comment for the rationale.

[emanruse]

by the same reasoning we could add VPN or TOR capabilities to ungoogled-chromium

I use ungoogled-chromium with Tor proxy all the time. Yes, it would be quite good to have more control like in Tor browser (switching identity etc) and better anti-fingerprinting. What is wrong with that reasoning?

My point is that it is a non-trivial feature to develop/support/maintain and cannot be simply added as a "patch" or a few patches; see my previous comment for the rationale.

Ungoogling Chrome is itself a non-trivial task (although it may look like a patch work). Still that doesn't mean it is worthless, irrational or that it should be easily denied because it requires effort.

If your point is to say that the primary goal should be just content filtering (and not request blocking) because it is easier to do - that would be a completely worthless effort because Falkon browser already has built-in support for ad blocking rules + it was not developed by Google in the first place. But Falkon cannot even dream of what uMatrix can do.

[gmt]

Sorry to add more noise here. But just a quick note about the economics of critical mass and open source:

When some hypothetical abstract fork maintainer merges X->Y patches, because, even though they don't like it, "critical mass" is going to be lacking for feature X, what's really going on? Let's assume, all things being equal, we would prefer to fork and maintain the code, except for the concern that feature "X" will no longer have critical-mass adoption levels and therefore will represent wasted labor or marginalize our fork.

There is a game-theoretic problem here. Feature "X" may stand a chance of surviving upstream's "X"->"Y" move, if enough forks keep feature "X" alive. If a bunch of small forks play 'follow the leader' because of 'critical mass' reasoning, like the above, then upstream wins by default due to a lack of challengers. But if a bunch of forks stay with "X", upstream may be forced to revert their decision, or may simply become marginalized due to declining user-base. It would seem that somehow upstream has tricked down-streams into acting against their collective better interest in such a situation.

In this case, the "X" is a bunch of content filtering functionality with entire ecosystems built around it. It is threatened by "Y," a proposed inferior feature which upstream claims is "for the children" (correction: "for security"). Upstream's project-owner has a revenue-model-scale conflict-of-interest and nobody but upstream seems to want "Y".

Normal people might not know about this yet. A lot of them might find out the hard way when this stuff lands. At that time, the critical mass thing will probably get decided. Are convenient migration paths available to them, that don't force to make a decision like "I guess I have to take this abuse, because, convenience?"

Some people finding themselves in that position will/should not move to ungoogled-chromium because it lacks the Google-cloud-sync they rely on and/or want. Perhaps they will have to find some other fork or make a compromise and adopt "Y-brand" content-filtering.

But other people are not using those features. For them, ungoogled-chromium offers, potentially at least, the same or better value proposition as upstream. It seems to me it would be a shame for ungoogled-chromium not to be an option for disgruntled users of ublock0 and other plugins, at that moment, when a plurality of chrome users will have decided to reconsider what web-client they are going to use, going forward.

[csagan5]

@gmt my comment is about developing a solution to the "banishing" of ad blocker extensions (declarativeNetRequest, Manifest V3 etc) as a stand-alone, cross-browsers project. (I am frankly surprised about how it could be read in any other way...)

For the records, I agree with what you wrote and that is exactly the reason why I would give the community effort more success chances if it were to be coordinated with other open source projects and exist as a stand-alone, cross-browsers project instead of being developed within ungoogled-chromium or Bromite or Vanadium (GrapheneOS) or Inox or Iridium or any other open source project which has privacy in mind - but would not be able on its own (because of resources and because of the issues that arise when trying to properly define the scope) to tackle the problem being discussed on this issue.

If it is successful enough it might even set a "de facto standard" and facilitate projects forking Chromium.

[gmt]

@gmt my comment is about developing a solution to the "banishing" of ad blocker extensions (declarativeNetRequest, Manifest V3 etc) as a stand-alone, cross-browsers project. (I am frankly surprised about how it could be read in any other way...)

My rant above isn't in response to anyone in particular... more of a coffee-fueled non sequitur attacking the argument (which may not even be seriously proposed above) that there's no point to this discussion, because upstream has a (decreasingly) benevolent dictatorship over the browser plugin ecosystem.

(tbc: in general Google has dropped a lot of really great open source into the AOSP/chromium repos resulting in great benefits to lots and lots of people. But perhaps they sometimes forget that in FOSS, you can't just unilaterally decide to remove something people don't want removed (well you can, but ...))

If it is successful enough it might even set a "de facto standard" and facilitate projects forking Chromium.

Your line of thinking above, iiuc, takes my point as a given, but is focused instead on how to fix the problem, not only on day 1, but in a more sustainable/maintainable way, i.e., where we don't end up with as many content filtering frameworks as browsers. I think it's a fantastic idea. No doubt, the devil's in the details but I can't think of any reason those particular devils couldn't be managed if enough people worked together on it.

Which brings us to the biggest problem with both our remarks and many others here, namely that our time is clearly better spent coding up solutions than hanging out here bikeshedding :)

[csagan5]

our time is clearly better spent coding up solutions than hanging out here bikeshedding :)

I consider the time spent discussing possibilities of open source projects coordination extremely well invested; this is my opinion based on the direct experience with the maintenance burden of Chromium patches. I can roughly estimate how wasteful it is for multiple projects to do that, often for the same patches/purposes.

[emanruse]

I consider the time spent discussing possibilities of open source projects coordination extremely well invested; this is my opinion based on the direct experience with the maintenance burden of Chromium patches. I can roughly estimate how wasteful it is for multiple projects to do that, often for the same patches/purposes.

The most efficiently spent time and effort would be if all those projects' intelligent developers join forces to work on a new browser instead of patching existing ones in which corporations dictate everything. Then that community would have the power to influence web standards too. Unfortunately that is not happening and the behemoths are ruling.

[emanruse]

BTW something interesting (perhaps a good starting point for further development?):

https://tech.slashdot.org/story/19/11/24/2055219/new-tracking-prevention-in-microsofts-edge-will-hit-google-the-hardest

[Eloston]

I think our first step is to implement something simpler, like Bromite's filtering approach (maybe not exactly, because Bromite is under GPLv3 and we're under BSD 3-clause. Would need @csagan5's input). That way, we will have a solution by the time Manifest v3 comes around.

In the long term, I think the best option based on what's currently available is to use Brave's filtering enigne. Brave has a solid implementation that will be well-supported for the foreseeable future. However, there might be a few licensing hurdles with Brave's code (I would need to know the details of MPL 2.0 to be sure).

Based on what I've read so far, I think the ideal solution would be to bring back Manifest V2 or add support for WebExtensions. Extensions provide a layer of abstraction and decoupling that makes the whole system more robust; i.e. it's easier to develop and test extensions than code in the browser. And with features like WebAssembly, the runtime performance loss should be marginal. Not to mention that there is already a large extension ecosystem we can use.

I am also open to participating in a collaborative effort to develop a new filtering engine. This is not necessarily to the exclusion of the previous two options though; if we have enough manpower, I'd like to investigate all of these long-term solutions a bit more to scope them out and assess them properly.

[travankor]

I doubt that copyleft licensing is a concern for the average user of ungoogled chromium -- at least it isn't for me. That said, you could make it optional if it's a problem.

By the way, MPL 2.0 is also a copyleft license. It's similar to the LGPL but a bit less strict when linking with proprietary projects AFAIU.

From my limited knowledge of web/content blocking, uMatrix/uBo is still the most powerful of all the available options. I think all the other options are inferior (either in quality of blocking or UI/UX or number of toggleable blocking features), but I haven't found a comprehensive comparison and analysis on the privacy effectiveness of various blockers. An analysis of the privacy goals required from a blocker would be a good way to frame the discussion IMO. There are probably university papers in this area, so maybe something to look for.

[Eloston]

I doubt that copyleft licensing is a concern for the average user of ungoogled chromium -- at least it isn't for me. That said, you could make it optional if it's a problem.

I was referring to licensing problems for ungoogled-chromium development. We don't use a copyleft license (we use BSD 3-clause), so it may pose some challenges in how we include features from copylefted projects.

[black-ish]

It has been a while and wanted to ask what is the current status of this? Is Manifest V3 already in effect and is the API removed?

[jstkdng]

@black-ish https://developer.chrome.com/extensions/migrating_to_manifest_v3

the old api wont be removed anytime soon

[stephenhawk8054]

As far as I see, Google has posted the timeline for phasing out Manifest V2. https://developer.chrome.com/docs/extensions/mv3/mv2-sunset/

[gothmog123]

so any news on what UC's strategy is gonna be?

[nikkehtine]

My suggestion is to support both the current format and Manifest v3, and develop an independent extension manager, that integrates with the browser and has the ability to install and update extensions from a source (like GitHub, GitLab, Codeberg repos, other specific URLs, as well as Chrome Web Store) so that we don't have to rely only on Chrome Web Store for extensions (similar to userscript managers like TamperMonkey).

I do realize that would be a pretty ambitious undertaking though, but it should be easier than implementing a browser-native content blocker.

[johannesrld]

regarding user-scripts, would it be possibly to use bromites implementation of userscripts? or is that out of scope

[black-ish]

Soo. the time is nearer than ever, anything?

[RFLEpicGamer]

So, ungoogled chromium will still support manifest v2 after 2023?

[gothmog123]

So, ungoogled chromium will still support manifest v2 after 2023?

even if they do that ublock origin won't maintain a chrome version just for ungoogled chromium and brave

[RFLEpicGamer]

Are you sure?

[gothmog123]

Are you sure?

no

[dm17]

Curious how this could help

I am following this discussion with interest however I do not think content filtering is something that ungoogled-chromium should focus on: it can, but then it would be best to start a separate project just for that part as it is potentially huge compared to the rest of the patches.

The approach I chose for Bromite is the least painful/more practical to maintain: to follow upstream. They have developed a content filtering engine (please go make some reading about it, it's quite advanced) and any alternative will always have less manpower behind it. It is also possible (and not surprising) that the subresource filter engine will be radically changed in the future, for example once upstream takes over the "game" of content filtering, having practically destroyed all extensions' competition. The current iteration of this engine can be used without any privacy compromise (it is not tightly integrated with cloud services etc) and that is why I chose it; if this fact would change (overal several development cycles) then Bromite would have to go back to the drawing board in a discussion similar to this one.

If I were to look for a content filtering solution (either for Bromite in the future, given the above-described unfavourable scenario or for ungoogled-chromium now) I would stay with the Chromium-based engine which has the best maintenance/support.

I made a list some time ago here: https://github.com/bromite/bromite/wiki/AdBlocking

The choice seems to be between SWE WebRefiner and Brave; they both are very unfriendly to integrate because of the commits mess (no clean patches), and the former was abandoned IIRC.

If someone knows about other adblock engines for Chromium please edit that wiki page and mention them in this discussion.

In conclusion: picking Brave's engine, or any other, or developing hybrid solutions as mentioned above (unrealistic) are IMO all worth of a separate project or sub-project.

I suggest "project" because you would absolutely want contributions if something like this was ever started, and it would be best that multiple FOSS browsers use it rather than a single one.

What would such project cover?

If using the subresources filter engine:

• (desktop) patches for the UI to allow adding filters in AdBlockPlus format
• (android) patches for the UI to allow managing filters (I developed a very simple one, with one URL edit field, for Bromite)
• (core) patches to convert them on-the-fly to the subresource filter binary format
• possibly other patches to add functionality, you can look at Brave's features for example

If using Brave's engine:

• basically cleanup of Brave's patches so that they can be used for desktop/android

@thestinger what is your opinion about "framing" the development of what is being discussed here? I assume it's also not something strictly on-topic for Vanadium but my thinking is that if there was a separate project about this, multiple browsers would be able to benefit from it.

I'd like to know more about Bromite's adblock engine so we can compare them.

@Eloston the engine used in Bromite is exactly the one used by Chromium upstream, with little changes. The biggest change I had to develop from scratch was a mechanism to download filters without using extensions, you can find relevant information in the URLs I have put in previous comments.

This was also documented here and here at time of release.

• Port over the adblock engine used by Bromite @csagan5, with additional modifications to allow for filter subscriptions etc. Seems like a fairly reasonable patch, and self contained.

@aluo-x there is no Bromite adblock engine, see above link. The patch is only for downloading updates in a simple and secure way without using the extensions system. The modifications I did to the subresources filter engine are minimal (removing unnecessary safe browsing integrations and other types of navigation throttles).

@TheStinger or anyone else know if there is progress or news about how to block ads in Vanadium (GrapheneOS's ungoogled chromium)? Any way ublock origin could be run to @TheStinger's security standards?

[mpaunovic]

It looks like it's not half as bad as people thought it was going to be regarding uBO:

https://github.com/uBlockOrigin/uBlock-issues/issues/338#issuecomment-1242401687

https://chrome.google.com/webstore/detail/ublock-origin-lite/ddkjiahejlhfcafbddmgiahcphecmpfh

[RFLEpicGamer]

I'm gonna give ublock origin lite a try as soon as I get back home, I'm not sure if this extension will be able to block YouTube ads

[MasterKia]

If you explicitly give it extended permissions for YouTube, then theoretically it can block ads there too (using scriptlet injection).

More details: https://github.com/gorhill/uBlock/blob/master/platform/mv3/description/en.md

[RFLEpicGamer]

Both AdBlock didn't work on YouTube ads

[jstkdng]

I've been looking into this, and even if we somehow ported brave's changes, the extension developers would have to support it. Gorhill has said that he won't maintain 2 versions of ublock iirc.

[MasterKia]

True, no response from Gorhill here: https://github.com/uBlockOrigin/uAssets/discussions/14544#discussion-4337846

[jstkdng]

It'd be great to have some sort of repository exclusive to supporting v2 where all chromium forks could get their patches and contribute new changes if/when brave decides that supporting V2 is too costly to them. If that doesn't happen then we'll just have to go the manual way, after all, brave has an economic incentive to keep as many users using brave with their crypto and ads. Wouldn't suprise me if their changes include code exclusive to brave.

[MasterKia]

It'd be great to have some sort of repository exclusive to supporting v2 where all chromium forks could get their patches and contribute new changes

Well someone has to step forward for that idea to work; could that "someone" be the ungoogled-chromium project? But maybe it's too much to ask.

Google Chrome, Microsoft Edge and even Opera^(?) are out; Only Brave and Vivaldi comes to mind but would two rival projects collaborate on something?

Vivaldi has also said that "_They want extension developers to reach out to them about potential independent extension store_".

[TopHatProductions115new]

I would, but I don't think I have the experience or know-how to pull that.

[awebeer256]

IMO, the best-case scenario to deal with this entire issue would be a pair of projects, each of which would develop and maintain a Chromium patch that would be available to all Chromium-based browsers.

One patch would restore the webRequest API for extensions. (And maybe other APIs too, but that's the only one I've heard of that Google is dropping.)

The other would provide one-click installation and (user-disableable) automatic updating of extensions from all existing extension stores (not sure if Firefox's would be technically feasible), and from any arbitrary URL. That way, an independent extension store, while nice for discoverability and reviews, would not be required. Extension developers could just host directly on GitHub/GitLab. Call it the Stylus/userstyle model.

[ghost]

The mv2 sunset page has been updated for clarity.

Until 2024, it should be trivial (I hope) to patch the enterprise policy to always allow mv2 extensions to run. They haven't specified so I'm not certain which one yet. Users could also locally set the relevant policy (on Windows, it could be as simple as a registry key at HKLM\Software\Policies\Chromium). This should suffice until they fully remove the policy and make maintenance require more work.

Similarly, for extensions that can comfortably work around the other mv3 restrictions such as arbitrary code execution ― and only require the blocking webRequest API, this can also be solved with patching or setting the relevant policy (ExtensionInstallForcelist). They are not removing the API but restricting it to a user-defined list of extensions, so developers should be able to port their extensions to mv3 and assume blocking webRequest still works as long as users set the policy.

I hope this helps.

[TopHatProductions115new]

The mv2 sunset page has been updated for clarity.

Until 2024, it should be trivial (I hope) to patch the enterprise policy to always allow mv2 extensions to run. They haven't specified so I'm not certain which one yet. Users could also locally set the relevant policy (on Windows, it could be as simple as a registry key at HKLM\Software\Policies\Chromium). This should suffice until they fully remove the policy and make maintenance require more work.

Similarly, for extensions that can comfortably work around the other mv3 restrictions such as arbitrary code execution ― and only require the blocking webRequest API, this can also be solved with patching or setting the relevant policy (ExtensionInstallForcelist). They are not removing the API but restricting it to a user-defined list of extensions, so developers should be able to port their extensions to mv3 and assume blocking webRequest still works as long as users set the policy.

I hope this helps.

Just saw this:

• https://www.ghacks.net/2022/09/29/google-delays-the-death-of-manifest-v2-extensions-to-2024/

I thought that it was originally supposed to go out in 2023, so the deadline appears to have been extended a bit. A welcome change. More time to decide on a decision...

[SeaKhaki]

My opinion is that this is significantly more than just a debate regarding uBlock Origin, but rather browser API compatibility in general. This change will affect every single user worldwide.

[SeaKhaki]

Has there been any further interest from the community to develop a patch?

[dm17]

This might be a good opportunity to have a synergistic effort that would deduplicate a lot of similar efforts. For example, there is no adblock in Vanadium because it is a potential security threat (not to mention the fact that chromium for android doesn't support extensions). So with manifest v3 and all of these ungoogled forks piling up - I'm thinking a "many birds with one stone" type of effort (whereas the stone is a development process :) could be ideal. More described here: https://github.com/ungoogled-software/ungoogled-chromium/discussions/1395

[SeaKhaki]

If there is in fact interest in being involved, I’d be happy to lead this. At this stage the best thing that can be done is to establish a central discussion revolving these topics, and decide on a method of integration which could be adopted and maintained. Is there a group chat or discord server preferable?

[networkException]

For ungoogled-chromium itself we have a Matrix room

[SeaKhaki]

The ideal would be to either have something on GitHub or Discord mainly just so less advanced users might be able to participate, obviously this is all still assuming people are still interested

@Eloston are you still involved in this discussion?

[dm17]

The ideal would be to either have something on GitHub or Discord mainly just so less advanced users might be able to participate, obviously this is all still assuming people are still interested

If someone isn't advanced enough to use the communication technology that the top developers prefer, then they aren't advanced enough for their opinion to matter - and the noise they generate will only serve to disincentivize those who must put put in the real work from even getting started.