# Towards a multi-protocol browser - Priorities and Thoughts

## Some questions we need to answer

* Under an http context, resources are identified by its **location**
* How a browser should behave under a mixed scenario ?
* What a browser should do when a non-http scheme is used to identify a resource ?
* top-level navigation vs subresource
* How important is the Web Extension (eg, IPFS companion) for the IPFS ecosystem
* It's fundamentally based on custom handlers, so this approach should be pursued in the mid-term
* Is there any common area between IPFS and other non-http schemes that we should prioritize ?

## Custom Handlers, next steps or dead end ?

* How we could improve the custom handlers to improve IPFS support ?
* Would it benefit other use cases than Web Extensions ?

## Native implementation

* Different approaches
* CAR over HTTP (Brave)
* Would some of the side approaches (eg, Subresource Integrity) bring some benefits to an eventual native implementation of IPFS ?
* Why a browser should ship an alternate networking protocol and not others ?

## Priorities

* What should be our priorties for 2023 ?

## Some ideas

https://cloud.igalia.com/s/tXNAwrfJmodxsTZ

## Minutes

### Introduction

* Brave shipped native protocol impementation in a separate process
* Goal: make chrome to implement something similar, communicating between processes that run IPFS local nodes
* https://hackmd.io/BWQoUqtsR7-OPOfdOAft3w?view
* Trustless IPFS server is a key aspect to provide a good experience of WebExtensions based on the custom handlers
* How to make the browser to look at data, handle it properly, integrity, location, ...
* Looking for ways to acceleate Chrome development on this regard
* There are so many integraiton points when it comes to discuss HTML URLs
- caches, subresource integrity (hashes)
* Content without integrity can lead to privacy and securtity breaches
* There are different elements than have to deal with sources (iframe, videos, ..)
* should we deal with them using custom handlers ? Brian thinks it's not the right approach
* idea: forget about the src attribute and focus on the integritiy att instead
* brian thinks its an approach that makes sense
* it may be possible to implement a polyfill about it
* there is a confluence of people that thinks that it's must be ensure a thing is what is supposed to be (integrity, via hashes)
* lidel explains why is still important to work on the protocol handlers approach ?
- is fine to focus on subresources but protoco handlers is the only way to indicate the integrity of the top level document
* brian: remarks that there is top level and subresources, so differnt scenarios. For top-level it still make sense to rely on protoco handlers.
- but when it comes to a resource, there are multiple ways to retrieve a resource, either http, IPFS or even ftp, so how a custom protocol should make a final decision on the browser ?
* Brian points out that an IPFS site may use HTTP links as well, how to deal with that ? When the html protocol was desesing it was with the aim of being the maximum common denominator of all the available formats
- Would protocol handlers be such common denominator ?
* For now we are focusing on the critical use cases, where the IPFS page is the only one. The trust model is the top propritye, ensuring the user that the content retrieved is the one requested.
* How a URI is validated in browsers today ?
- lidel comments that last time he checkd, the URIs has no-origin, so they are kidn of a special case.
- they have the concept of authority component, instead of location
* brian mentions that data URLs are handled similiarly, but blob are differnt (they can't be loaded from the top document)
* Some about content verification Links:
* https://github.com/schemaorg/schemaorg/issues/2450
* https://github.com/schemaorg/schemaorg/issues/3162

### Priorities for 2023

* 2 approaches: protocol handlers vs native implementation
- most of the ideas would focus on the native implementaion (eg data-* or integrity attr)
* Another line of work Security model (verifiable data)
- brian thinks this ara is worth investing some time on; perhaps not specifically development effort, but to build consensus on the best way to address these issues

* What should be our priorties for 2023 ?
- protocol handler improvements
- SRI experiments
- native support
- https://hackmd.io/BWQoUqtsR7-OPOfdOAft3w
- content verification
- mis/disinfo use cases
- schema.org (brian mentioned two issues)
-
- Ed25519 in Web Crypto API