feat(chromium): add protocol_handlers manifest key#1358
Draft
Conversation
add protocol_handlers for ipfs://, ipns://, dweb:// and their web+ prefixed variants to the chromium manifest, matching the existing firefox configuration. this enables native protocol handling in chromium once the browser implements the protocol_handlers WebExtensions API (currently in development). the handler code already exists in ipfs-request.js, so no JS changes needed. chrome ignores unknown manifest keys, making this safe to add now.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Important
This is parked until Chromium ships with
protocol_handlerssupport for Manifest V3 browser extensions.For now, this PR can be used for testing (build extension and load into a test build from Igalia).
TBD when we ship it – we will coordinate with Igalia.
Summary
This PR adds
protocol_handlersmanifest key to the Chromium build, preparing IPFS Companion for native protocol handling ofipfs://,ipns://, anddweb://URLs.This aligns the Chromium manifest with Firefox, which has supported
protocol_handlerssince 2017. Chrome currently ignores unknown manifest keys, so this change is safe to ship now and will activate automatically if/when Chrome implements the feature.What this enables
Once Chrome ships the
protocol_handlersAPI, users will be able to:ipfs://links and have them handled by IPFS Companionipfs://bafy...directly in the address barchrome://settings/handlersipfs://(test page:ipfs://bafkreia72r46hbyeozencwzmb7drksaxwg7cqve6wsor336eo72nkklnki)Implementation notes
protocol_handlersconfig frommanifest.firefox.jsontomanifest.chromium.jsonipfs-request.jsdweb.link(same as Firefox)Status
The
protocol_handlersAPI is not yet supported in Chrome stable. Igalia is actively working on bringing this feature to Chromium, and we hope to see it land sometime in 2026, though there's no clear ETA yet.This PR gets Companion ready and available for testing in dev builds of Chromium that include the prototype:
Background: Igalia's multi-year effort
We've been collaborating with Igalia since 2022 to bring this capability to Chromium:
2022: Foundation work
2023-2025: WebExtensions API
Why this matters beyond IPFS
Igalia designed this as a vendor-agnostic WebExtensions API, not an IPFS-specific feature. Any extension will be able to register custom protocol handlers. This benefits decentralized protocols (IPFS, DAT, SSB, Bitorrent, Bluesky/ATProto, etc.), application deep-linking, enterprise tools, and any future protocol needing browser integration.
Next steps
This redirect-based approach is a stepping stone. Future work will explore ServiceWorker-like handlers that resolve protocols directly within the extension. See ipfs/in-web-browsers#212.
Thanks
Thanks to the Igalia team for their continued effort on this. Good progress is being made toward improving how browsers handle non-HTTP URIs.