What is the upgrade path?

Cross-posting an attempt at an answer from ipfs/specs#152

What is up for technical debate is what we usually call the upgrade path -- how to integrate with existing protocols and infrastructure in a way that:

Makes it easy to simultaneously use the thing in its native environment, as well as the classic environments.
Opens a long term perspective for transition.
Yields an immediate benefit even within existing infrastructure.

Big protocol migrations happen over decades, and it's fundamentally important that new protocols interoperate well, otherwise the migration cost is simply too high. For example the IPv4/IPv6 migration came up with half a dozen IPv4-over-IPv6 and vice versa sub-protocols.

Note that for the upgrade path, we're not constrained to exactly what currently is. Many of the web's protocols (HTML, URLs, etc.) are so-called living standards, which aim to evolve relatively organically. We can propose new APIs and features, weigh in on discussions, and generally participate in the specification and development effort, as we did for example with the Suborigin working group.

Browser developers appear to not be generally opposed to the technicalities of dweb: URIs (and sometimes even inviting), if and only if we make an effort to make them play nice with the existing browser platform.

While browsers play a big role for ipfs (see ipfs/in-web-browsers) and are mentioned here a lot, we also want dweb: URIs to be supported in all kinds of tools/applications/libraries. One example is @Kubuxu's weechat plugin, which makes the URIs clickable.

[...]

These are not fixed serial steps, instead there's more of a wibbly-wobbly concurrence/simultaneity of all four stages. Networks are a wild mess of parts developing into differing directions, at varying speed (just like a rhizome).

ipfs-inactive / faq

What is the upgrade path? #233