Browsers & Standards Work 2026: Call for Community Input

Ecosystem and Usage
1

TL;DR: IPFS is planning the next phase of work to make browsers better for the decentralized web – not just IPFS, but any protocol that needs lightweight crypto, peer-to-peer connections, or native browser integration. We need your input on what features matters most.

Background: What We’ve Accomplished

Over the past 5 years, sustained collaboration with Igalia has delivered real improvements to all major browsers:

  • Ed25519 in WebCrypto API - Shipped in Chrome 137 (May 2025), now available in 79% of browsers. This eliminates the need to bundle crypto libraries for signature verification, reducing bundle sizes significantly for projects using content-addressing, decentralized identity, or verifiable credentials.

  • Service Worker improvements - Fixing Chrome bugs that block adoption of Service Worker-based IPFS gateways

We’ve also collaborated with Little Bear Labs to ship ipfs-chromium and ipfs-electron forks with native IPFS support. While they’re not in the main frameworks (yet!) they show what’s possible. This work has been supported by Protocol Labs and the IPFS Implementations Fund.

What’s Next: 2026 Priorities (Draft)

We’re drafting the 2026 priorities and want community input. While this work is highly subject to browser acceptance, we’ve seen that sustained, precisely-targeted effort does result in success, especially over 2+ year windows. Here is the draft of 2026 priorities:

A. WebCrypto API Expansion

Goal: More cryptographic primitives as browser defaults, eliminating the need for bundled crypto libraries.

  • Curve448 - (High confidence for Firefox, mid for Safari, low for Chrome)

  • Argon2 (better key derivation), SHA3, ChaChaPoly, kMAC - stretch goal, mixed browser signals - W3C report, Github issue

  • HPKE - Chrome/Firefox positive/mixed signals

  • BLAKE3 - Stretch goal

  • Streaming hashing - Via WebCrypto Streams spec (moving to WICG) - stretch goal, mixed signals from each browser - Proposal, Github issue

B. Service Worker IPFS Gateway Support

Goal: Fix Chrome bugs blocking IPFS Service Worker gateway adoption.

C. Secure WebSockets Metadata

Goal: Reduce double-encryption overhead in libp2p over WSS.

  • Feasibility analysis of making connection metadata available on secure WebSocket objects

  • Would allow libp2p to opportunistically skip redundant encryption when outer TLS provides same guarantees

  • Potential prior art: RFC 5705 (TLS Keying Material Exporters)

D. WebTransport Improvements

Goal: More viable transports for browser-based p2p applications.

  • Interoperability testing - Improve test coverage across browsers

  • Firefox parity with Chrome - Mid confidence

  • Safari parity with Chrome - Stretch goal (Apple just started implementation)

E. WebRTC Enhancements

Goal: Better p2p transport options, especially for Service Workers.

F. Protocol Handlers in WebExtensions

Goal: Native ipfs:// and ipns:// support via extensions, path toward Service Worker-based handlers.

  • Ship new WebExtension API - High confidence

  • Dynamic protocol handler URL updates - Allow extensions to update handlers

  • Sub-resource protocol handling - For <img>, <script>, fetch(), etc.

  • Per-CID origin isolation - Research chrome-extension://subdomain.ipfs.extension-uuid/ patterns

  • Service Worker protocol handlers - The end goal (Safari has negative signals)

G. Local-First Browser Support

Goal: Enable local IPFS nodes without mixed content warnings.

H. Content Security Policy

Goal: Better CSP controls for WebRTC and WebTransport to prevent exfiltration.

We Need Your Input!

If your project needs specific features from browsers (whether it’s on this list or not), we want to hear from you! When commenting, please include:

  • Your project name (for coordination)

  • Specific feature(s) you need
    Why? What’s blocked without them?

  • Brief description of your use case
    (e.g. "Project XYZ needs BLAKE3 in WebCrypto because we’re using it for content verification across 10k+ files per session. Current bundle with BLAKE3 WASM is 400KB.” or “We’re building a local-first app for precision agriculture and the localhost secure context issues are blocking our ability to talk to a local IPFS node.”)

  • Whether you can help test/validate when ready

We’re aiming to collect and incorporate a first round of input by Tues, Dec 16, and will also make adjustments throughout 2026.

5 Likes
2

Project: Storacha
Use Case: Distributed CDN

Context: was asked to describe what blocks building a CDN that isn’t a centralized trusted service. These are issues I came across building Saturn, a CDN made up of untrusted nodes serving CID content – these issues were serious enough that the product was not sellable, because integration was an impossibly high lift for customers.

  • Fundamental issue: how to verify integrity of assets delivered from untrusted nodes

    • Current most workable solution: service worker interception – this is how the server worker gateway works

      • Challenges: It’s a massive lift. Service workers don’t work in many envs, they’re a major architecture change for an existing service, and they simply don’t run on first page load, which is when a CDN matters anyway.

    • Other approaches: Browsers have already taken several attempts at specs for resource integrity, but current solutions are too limited and work is stalled.

    • Proposed solution: ship a much more expansive subresource integrity spec or build content-digest verification into the browser (which would still need to be paired with an expanded sub-resource integrity spec, but would provide a healthy mechanism for implementation)

    • MVP Scope Suggestion: start with DASL spec, in fact DASL RAW spec, and work to implement browser verification of DASL assets (aka AtProto blobs)

  • Secondary problem: Content verification for large streaming assets like video is really rough (i.e. videos) without merkle hashes like Blake3. Behind the scenes, the browser converts video tags to HTTP range requests. Various tools exist to verify a partial range of data on merkle hashes like Blake3. Support for blake3 in webcrypto would simplify shipping a service worker that supported video assets.

  • Vision goal: the combination solutions to the above challenges, so that I could just use this and the browser would streaming hash verify my video asset from an untrusted source:

2 Likes
3

Project: Peergos

Use case: sandboxed (exfiltration proof, in its own OS process) serverless apps

Features we want in priority order are:

  1. webrtc CSP flag: Content Security Policy Level 3
  2. The ability to define a Service Worker on a unique origin from a local String (no server involvement at all) that is totally sandboxed from the parent context. This shouldn’t be content addressed, although we could work with that by varying the SW document.
  3. blake3 in webcrypto, ideally with an API for streaming, or even better, parallelising, a large file hash calculation chunk by chunk (think many GBs).

Our sandbox use case is described in more detail here:

and here:

We can, of course, help test any of the above. Our current approach for the sandbox requires assistance from the server (which can be localhost) which serves up the same static document which defines a service worker for all subdomains, isolated with COOP, COEP, and CSP. One problem here, apart from needing a server, is that sometimes the requests are not intercepted by the service worker. We would like to make that impossible.

4 Likes
4

I would like to see a dedicated reserved network port for Local Gateway. 8080 is problematic because it’s being used by many other default software configs, and it can not reasonably be assumed to be available. Ideally, IPFS Local gateway should have something registered with IANA, but I have no idea how long that would be expected to take. But if we could link to gateway via localhost:xxxx and expect that to be available, (be it browser plugin, some kind of forwarding agent, or an actual node.)

1 Like
5

Sorry for being late, I just heard about this yesterday.

This request is based on discussions with various people interested in verified streams in the browser. A feature that’s needed if you want to support downloading files bigger then memory without any workarounds is and implementation of showSaveFilePicker(). This way you can verify the hashes of a stream on the file and support very large files.

It exists already in Chromium, but it lacks support in Safari and Firefox. It’s part of the File System API which Firefox has some reservations, but it’s no longer a hard no (my request it’s really only about this function, not any other File APIs). WebKit has some outdated draft implementation for it.

2 Likes