Re: [Wpack] Counter-proposal where bundles only contain a single origin

[Marcin Rataj <[e-mail]>]

On 26/08/2020 20:00, Jeffrey Yasskin wrote:
> # URLs for nested bundle resources
>
> ```
> package://distributor.example/bundle.wbn$app/foo.wbn$bar.html
> package:///c:/Users/name/Downloads/bundle.wbn$app/foo.wbn$bar.html
> ```
>
> This fetches the outer bundle by removing everything after the first 
> `$` and:
>
> * If the URL has an authority, replacing the `package:` with `https:`
> * If the URL doesn't have an authority, replacing the `package:` with 
> `file:`.
>
> To allow the outer bundle to be fetched using a third scheme, we would 
> need to add a matching new scheme for addressing inside it.

This proposal sneaks in a controversial change of making the internal 
protocol schemes to be implicit "https:"
It comes at a cost of protocol lock-in, which puts future use cases that 
rely on decentralized content routing and discovery in jeopardy.

For example, it makes it impossible for a resource inside of a bundle to 
use ipfs:// URI (content-addressed protocol) for making network requests 
that:
(1) do not require bundle to point at a specific location of the data 
(heals link rot, improves resilience of a bundle)
(2) provide better integrity guarantees than HTTPS (content-addressing 
means received data can be validated in trust-less manner, based on the 
hash from address itself)

In the interest of supporting distributed use cases, and keeping door 
open for future innovation in this space I suggest changing this 
proposal to avoid implicit defaults of https and always use explicit 
protocol scheme ensure arbitrary URI can be used by user agents in the 
future.

Marcin