[TOPIC 1/8] Bundle URIs

# Bundle URIs (Stolee)

- Unlike packfile URIs, includes refs, does not need to be delta-ed
	against what server sends
- Doc checked into Documentation/technical
- URI can be provided by user at CLI or advertised by server
- Most users won't experience anything if they git-clone, but it will
	only benefit the git hosting providers. It will allow them to offload
	data to CDNs, being closer to the client.
- With bundle files you can download them and start of from there and
	fetch the objects you're missing in a regular manner.
- Jrnieder: Packfile URIs and Bundle URIs are trying to achieve the same
	thing.  How can we duplicate efforts? E.g. how can we prevent the
	client from leaking information to a possibly untrusted server?
- Stolee: Are you want to provide a way to provide authentication?
- Jrnieder: Analogy to the web - you don't want to leak information to
	websites you don't trust. The security model is pretty complicated, we
	don't want to replicate things like same origin policies.
- Stolee: So, e.g. the server provides a hash of the content expected at
	the bundle URI and the client can verify? We wanted to explicitly
	avoid that because we don't want the server and bundle provider to
	need to know anything about each other.
- Jrnieder: Compare to packfile URIS - Packfile URIs are only advertised
	for the server, so the security model is mostly the same as a
		"regular" fetch/clone
- Jonathantanmy: Another difference: the objects in bundles must be
	associated with refs, you can't just have e.g. large objects.
	Packfiles can contain arbitrary objects.
- Stolee: Let's talk about the security model more on the mailing list
- Ævar: We're also open for a breakout session on this topic