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

[Jeffrey Yasskin <[e-mail]>]

I worked with Martin to flesh out his ideas for simplifying the bundle URL
and origin design, and we came up with the following. I still prefer the
proposal I presented a couple weeks ago
<https://github.com/WICG/webpackage/blob/master/explainers/bundle-urls-and-origins.md#proposal-a-package-scheme>,
based on the tradeoffs down at the bottom here, but it's quite possible
I've missed things. I'd appreciate this group's input on which way we
should go.

The basic idea here is that:

* Each bundle defines a single origin.
* Bundles identify their contents with paths, not full URLs.
* Metadata can provide a base URL to resolve those paths against.
* We allow a single file to contain multiple origins using nested bundles.
Use cases:
   * Users should be able to share subsets of the web that can link within
themselves, in a way that different sites within those subsets don't have
their storage collide.
   * One request for ads should be able to return the contents of multiple
iframes in a way that those contents can't modify each other.


# 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.

Subsequently, each segment separated by `$`s is the path to look up in a
nested bundle. Any `$`s inside a segment are percent-encoded.


# Origins for nested bundle resources

The origin of one of these holds the information from the URL up to the
last `$`. So for

```
package://distributor.example/bundle.wbn$app/foo.wbn$bar.html
```

* scheme: package:
* host: distributor.example/bundle.wbn$app/foo.wbn
* port: null
* domain: null

We could also hold the part after the first `/` in a new component, similar
to Gecko's OriginAttributes
<https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers#An_extended_origin>,
but OriginAttributes are mostly undocumented, and origins define "opaque
hosts <https://url.spec.whatwg.org/#opaque-host>" to encode this sort of
information into the existing field.


# Navigating across nested bundles

Within something like El Paquete Semanal or the Web Archive, it's
straightforward to store each origin in separate nested bundles, but we
want links from one origin to another to also work within the same
top-level bundle.

Addressing something in a sibling or parent bundle is reasonably
straightforward, with something similar to the following syntax:

```
<a href="package:..$/https/other.site.example.wbn$/path.html">
```

The downside is that if a user wants to take one site out of the big bundle
and use it on its own, and they want links outside that site to land on the
internet, they have to know the mapping from URLs to bundle names and undo
it in all the links. If they don't do this, the links are broken instead.

Similarly, if someone wants to compose a couple of pre-existing bundles,
they have to rewrite links to point to sibling bundles appropriately.


# Comparison

We need to compare "single-origin bundles", described above, with
"multi-origin bundles", described at
https://github.com/WICG/webpackage/blob/master/explainers/bundle-urls-and-origins.md#proposal-a-package-scheme
.

Both use a package:bundle-location$within-bundle format.

Because the single-origin proposal chooses not to encode the whole origin
to fit in the authority URL component, and implies rather than states the
bundle's scheme, I'll compare it to a variant of the multi-origin proposal
that does the same, yielding:

```
package://archive.example/2020-04-01.wbn$https://camera.example/edit.html
```

The difference becomes whether the origin computation includes an authority
component in the last $-delimited segment.


## Single-origin bundles are better:

* Implementers can use a simpler algorithm to compute the origin, ending at
the last $ instead of having to also parse a URL from the last component.

* Including just a single origin may avoid the need for signatures to
specify a subset of the bundle, which could simplify that section.

* Naming subresources with paths instead of URLs is more consistent with
other archiving formats.


## Multi-origin bundles are better:

* Users can expect simple tools to combine and split pre-existing bundles.

* When authors are composing a bundle, cross-origin resources can go
directly into the bundle, instead of needing to rewrite them to same-origin
or put them in a nested bundle.

* Implementations only need to spin up the bundle parser once, which could
affect performance.

* Implementers need to write and maintain tools to rewrite cross-origin
URLs when saving a bundle from a website