Description
Introduction
The original issue is more than four years old, the community has been seeing the MV3 Saga unravel, but the reality in 2023 is we need to tackle this head-on to provide a path forward for users that rely on companion on such browsers.
🧪 Beta Testers Needed
Read Discuss Post: https://discuss.ipfs.tech/t/announcing-ipfs-companion-mv3-rc-beta/16442
Beta Webstore Link: here
Report Beta Bugs: here
The Problem
MV3 in itself is not the issue, it's an innocent change going forward. The problem lies with the webRequest API and going forward:
The non-blocking implementation of the webRequest API, which allows extensions to observe network requests, but not modify, redirect, or block them (and thus doesn't prevent Chrome from continuing to process the request) will not be discouraged. As an alternative, we plan to provide a
declarativeNetRequestAPI.
The Proposed Solution
The idea in simpler terms is to branch the builds such that we can produce a build for clients that support blocking webRequest API and the ones that do not (e.g. Firefox will support blocking webRequest even with the MV3 change)
This boils down two having two implementations of the webRequest:
Blocking WebRequest BuildNon-Blocking WebRequest Build
Identifying the nature of webRequest from code will be hard, but can be spiked out to validate if this is something we can deduce in code, otherwise we can split the build process such that we build artifacts based on what variation of webRequest API client supports.
The Non-Blocking WebRequest will ship with extra feature, which would:
- observe the webRequest URLs.
- Implement a LFU-Cache to update the list of URLs serviceable by companion.
- Use
declarativeNetRequestAPI to update the URLs to be blocked up to the permissible limit. - There exists a sample implementation using
declarativeNetRequestAPI. - Redirect requests as companion would normally do.
Known Risks
- It is understood that there would be cases where the URLs will be serviceable by companion but not blocked, but would eventually be blocked and served by configured node.
- LFU cache can be biased during a heavy browsing session which could make some URLs sticky. LRU cache is not an option as that would evict staple URLs if not used regularly. A good approach could be a hard-coded TTL to evict caches to manage the bias.
Metrics Collection
- Optionally we can collect top N hosts from the LFU to ship by default with the companion releases. This could cover a huge base and give companion a head start, this will later auto-optimize based on the usage patterns.
Related Issues and PRs:
Deadline
March, 2023- September -ish, 2023
ETA: 2023-06-30
