adam/ipfs-blog
1
0 Fork 0
mirror of https://github.com/ipfs/ipfs-blog.git synced 2026-10-31 02:11:57 +01:00
Code Issues 17 Packages Projects Releases Wiki Activity

Update src/_blog/2023-ipfs-companion-MV3-update.md

Browse Source 
Co-authored-by: Marcin Rataj <lidel@lidel.org>
This commit is contained in:
Nishant AroraandMarcin Rataj authored and GitHub committed 2023-11-29 00:28:41 -07:00
1 parent 2e6bf83275
commit c87cc4c88c
1 file changed
+1 -1
Download Patch File Download Diff File Expand all files Collapse all files
src/_blog/2023-ipfs-companion-MV3-update.md
+1 -1
View File
@@ -36,7 +36,7 @@ However, it turns out that the `declarativeNetRequest` API is not as secure as i
This becomes an issue for genuine extensions like IPFS-Companion, which used the `webRequest` API to intercept requests to a given IPFS resource and redirect those to be loaded via the local gateway. This is a key feature of the extension, as it allows users to access the content via the local gateway instead of the public HTTP gateway, which is a centralized service.
## Planning the migration
## The Plan
The discussions around this topic started soon after MV3 was announced. There is tons of scenarios and information in [Issue #666](https://github.com/ipfs/ipfs-companion/issues/666). The first step was to spike out a rudimentary version of the extension using the MV3 APIs and see if it was possible to achieve comparable functionality. This was done in [PR #1078](https://github.com/ipfs/ipfs-companion/pull/1078) by [@MeAndDaveJustice](https://github.com/meandavejustice) that helped a lot in understanding the challenges.