Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Background on Address Scheme discussions (dweb, ipfs:// and more) #152

Closed
wants to merge 5 commits into from
Closed

Background on Address Scheme discussions (dweb, ipfs:// and more) #152

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
8558e2a
Background on Address Scheme discussions
flyingzumwalt Mar 3, 2017
23ac76e
better structure for pointing out to many discussions. clarify who ni…
Mar 4, 2017
a515b90
distinguish goals from approaches
Mar 4, 2017
2835fb3
more info about namespace proliferation
Mar 4, 2017
0e0f8c9
rebase branch onto master
daviddias Oct 17, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
157 changes: 124 additions & 33 deletions DWEB_ADDRESSING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,43 +1,134 @@
# ![](https://img.shields.io/badge/status-wip-orange.svg?style=flat-square) Addressing on the Decentralized Web
IPFS Address Scheme and URIs
=================

**Authors(s)**:
- [Lars Gierth](mailto:lgierth@ipfs.io)
The IPFS address scheme is described in [the IPFS whitepaper](https://github.com/ipfs/ipfs/blob/master/papers/ipfs-cap2pfs/ipfs-p2p-file-system.pdf?raw=true) and a proposal for expressing those paths as URIs is described [in this PR](https://github.com/ipfs/in-web-browsers/issues/28). Alternative approaches have been proposed. This document provides a reference point for finding the related discussions and understanding them.

**Maintainers(s)**:
-
# Backround for the Discussions about an Address Scheme for IPFS and `ipfs:` URIs

* * *
The discussions around `ipfs:` vs. `dweb:` is a confusing one that's been going on since @jbenet published the [IPFS whitepaper](https://ipfs.io/ipfs/QmR7GSQM93Cx5eAg6a6yRzNde1FQv7uL6X1o4k7zrJa3LX/ipfs.draft3.pdf), with a number of other approaches being proposed. That design discussion has been going on for a long time, with many lengthy discussions in github issues.

**Abstract**
## Competing Goals

This document is largely incomplete.
There are a few goals tugging against each other:

1. The Noble Goal: Unify the filesystem-database-web rift
2. The Goal of a Quick Fix: Conform to URL orthodoxy
3. The Design Goal: Create Addresses that People will Love Using
4. The Clean-Namespaces Goal: Avoid polluting the scheme namespace with multiple schemes

# Table of contents:
- Introduction
- The precarious web
- Link competition and link rot
- The addressing rift
- DWeb Addressing
- Namespaces
- /ipfs -- immutable data
- /ipns -- mutable pointers
- Addressing data from other content-addressed systems
- Network addressing
- Interoperability
- DWeb Addressing with HTTP
- ipfs:// and ipns:// URL schemes
- dweb: URI scheme
- Content Security Policy / Origins
- Appendix
- DWeb Maturity Model
- FAQ
- Implementations
- Future Work
- Related work
This has led to some competing approaches -- mainly the 'dweb:' Approach and the 'ipfs:' Approach -- and some possible compromises.

## Introduction
Regardless of which goals and approaches resonate with you, there are a number of important factors that have to be handled by any schema. A number of those factors are collected & discussed in these issues:
https://github.com/ipfs/in-web-browsers/issues?q=is%3Aissue+label%3Aspecs

Location-based addressing is a centralizing vector on the web. It lets links rot and drives copies of content into mutual competition.
### The Noble Goal: Unify the filesystem-database-web rift

This document describes a content-based addressing model which provides permanent links that don't rot and are cryptographically verifiable. The result is a more cooperative, resilient, and performant web.
In short, @jbenet (creator of IPFS) wants to fix a mistake that happened 25-30 years ago and sees this current decision as an inflection point where we either A) use this "decentralization" moment to fix the problem or B) let all these decentralized protocols worsen the problem by going along with the existing momentum. In @gozala's words (voicing the perspective of web browser implementers), "While I think that’s a very noble goal, I think it would be hard to sell for a very pragmatic crowd".

#### Unify the filesystem-database-web rift

In conversations documented [here](https://github.com/ipfs/in-web-browsers/issues/4), @jbenet and @gozala cover this topic relatively concisely.

@jbenet explained his rationale:

> The major reason has to do with unifying FSes, Databases, and the Web with a singular way of addressing all data. It's about undoing the harm that URLs brought unto computing systems by fragmenting the ecosystem. To this day the rift between both worlds prevents simple tooling from working with both, and has much to do with the nasty complexity of working with networked data all the modern target platforms. Sorry, this may sound vague, but it's very specific: addressing of data broke when URLs and URIs were defined as a space OUTSIDE unix/posix paths, instead of INSIDE unix/posix paths (unlike say plan9's 9p transparent addressing). This made sense at the time, but it created a division that to this day force "the web" and "the OS" to be very distinct platforms. Things can be much better. Mobile platforms, for one, have done away with the abstractions in the user facing parts, hiding away the rift from users, and only forcing developers to deal with it (clearly a better UX), but problems still exist, and many apps are hard to write because of it. we'd like to improve things, particularly since "a whole new world" of things is joining the internet (blockchains, ipfs, other decentralized web things). It would be nice if there's a nice compatible way to bridge with the web's expectations (dweb://...) but work towards fixing things more broadly.

also

> we'd like to improve things, particularly since "a whole new world" of things is joining the internet (blockchains, ipfs, other decentralized web things). It would be nice if there's a nice compatible way to bridge with the web's expectations (dweb://...) but work towards fixing things more broadly.

also

> A minor reason is not having to force people to swallow N shemes (ipfs:// ipns:// ipld:// and counting), and instead use one that muxes.

#### ... but don't let it prevent pragmatism.

@gozala encouraged pragmatism:
> While I think that’s a very noble goal, I think it would be hard to sell for a very pragmatic crowd like browser vendors. I frequently see standardization process taking specs into least ambitious and most pragmatic direction, I often disagree, but I think often times that’s only way to make progress. Maybe some version of this goal could be articulated in [less] perfectionistic manner and in a more pragmatic one ?

@jbenet agreed to that pragmatism:
> **These goals are secondary in time to getting browser adoption. Meaning that we CAN do things like recommend ipfs:// ipns:// ipld://** IF browser vendors think that it's unlikely to get adoption this way now. We can work on unifying the fs-db-web rift later. **We're not dogmatic, we're pragmatic.** But we want to make sure we push in the right places and try to make as much as we can better.

### The Goal of a Quick Fix: Conform to URL orthodoxy.

The short-term fix that people reach for is to create an `ipfs:` schema, as proposed in https://github.com/ipfs/specs/pull/139. This would conform to established habits around the use of URLs.

### The Design Goal: Create Addresses that People will Love Using

From a design perspective, the challenge is to create a schema that makes intuitive sense, maximizes possibilities, and allows people to identify content with addresses that are reliable, powerful, and pleasant to use.

### The Clean-Namespaces Goal: Avoid polluting the scheme namespace with multiple schemes

If we do this wrong, the growth of decentralized web technologies will cause a proliferation of schemes that will quickly become unwieldy, will discourage interoperability, and will maintain a high barrier to innovation in the protocol space.

## The `dweb:` Approach

### Strengths of this Approach

_PLEASE HELP FILL THESE_

#### Strength: Prevents Proliferation of Schemes and Namespaces

NOT doing this now effectively shuts down future possibilities by making new namespaces "not worth doing the work of introducing a URL scheme".

#### Strength: Getting away from the `://`
as @lidel [comments](https://github.com/ipfs/specs/pull/153#discussion_r104291285)
> I kinda like this _aesthetic_. No matter what prefix is picked, it looks better than anything with `://`
> `/webfs/ipfs/QmT272yei1Zn1eAUq5P9nZyeaKP4oJmVv7CbYvUPyk3aLj/hobby.jpg`
> `/dweb/ipfs/QmT272yei1Zn1eAUq5P9nZyeaKP4oJmVv7CbYvUPyk3aLj/hobby.jpg`
> `/x/ipfs/QmT272yei1Zn1eAUq5P9nZyeaKP4oJmVv7CbYvUPyk3aLj/hobby.jpg`


### Criticisms of this Approach
_PLEASE HELP FILL THESE_

#### Criticism: It's not clear how this helps the whole ecosystem
@lidel [comments](https://github.com/ipfs/specs/pull/152#discussion_r104291969)
> I feel it should be explicitly stated in the document if this single scheme aims to be for IPFS ecosystem only, or something that can be adopted by other distributed systems.
>
> If we want to share it with others, eg. Ethereum, Tor Onion Services etc, then I see potential problem with single scheme: who is responsible for muxing when multiple vendors are in play?
Let's say we have: `dweb://ipfs/Qmbar..` and `dweb://foo/buz`. If IPFS browser add-on provides handler for `dweb://`, FOO is unable to handle its own URIs.
We should plan for this now, and have contingency written down..

#### Criticism: Doesn't fit with the way Browsers identify origins

Some current browsers have trouble with the construction: origin = a:/b/c because they expect: `origin = a:/b`, even though that's not in the URI spec.

### Designing the `dweb:` Schema

A draft spec for the `dweb:` schema is under way at https://github.com/ipfs/in-web-browsers/issues/28

## The `ipfs:` Approach

The short-term fix that people reach for is to create an `ipfs:` schema, as proposed in https://github.com/ipfs/specs/pull/139. That approach seems simple at first, but it's got problems.

### Strengths of this Approach

#### Strength: Fits with Established Conventions & Expectations around URLs

#### Strength: Fits with the way browsers identify origins

When enforcing the Single Origin Policy, some current browsers expect: `origin = a:/b`, even though that's not what the URI spec calls for. The `ipfs:` approach fits with that expectation, with URIs like `ipfs:/<root-hash>/foo/bar`, the origin would be `ipfs:/<root-hash>`

### Criticisms of this Approach

#### Criticism 1: We want IPFS, IPNS and IPLD to be handled by a single schema
Creating an `ipfs:` schema would not be enough because `ipfs:` only refers to mutable content. You would, at the very least, need an `ipns:` schema too.

The `dweb:` schema dodges this by treating IPFS and IPNS as namespaces within a single `dweb` address scheme

#### Criticism 2: This would worsen the filesystem-database-web rift
See [The Noble Goal: Unify the filesystem-database-web rift](#the-noble-goal-unify-the-filesystem-database-web-rift) above.

#### Criticism 3: Will Prevent Innovation by making it hard to mint new namespaces
If we don't push for the `dweb:` approach it will prevent innovation by making it hard to mint new namespaces on the (content-addressed) web.

## Possible Compromises

### Treat `/ipfs:/` and `/ipfs/` as equivalent

In [this cryptic comment](https://github.com/ipfs/in-web-browsers/issues/28#issuecomment-281135393), @nicola (author of the IPLD spec) proposes a compromise. It's a clever way to allow people to use `ipfs:` and `ipns:` addresses without breaking from the `dweb:` address scheme. The protocol-design gymastics involved are a bit confusing. They revolve around the fact that we treat `ipfs` and `ipns` as _namespaces_, not _schemas_. We can just say "`ipfs:/A-HASH`" is equivalent to "`dweb:/ipfs/A-HASH`", allowing browsers to believe that `ipfs` is a schema when actually it's just a namespace within a more fundamental `dweb:` schema. All we have to do to support this is make IPFS treat paths starting with `/ipfs:/` as being equivalent to `/ipfs/` (no colon).

In the end this hack would let you have addresses that look like `ipfs:/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV` while also allowing people to address that same content as `dweb:/ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV` or, in a unix/posic contenxt just `/ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV`.

To quote him from an offline conversation, @nicola poses this as the baseline -- we have to beat this in terms of simplicity of use. Calling it an ugly hack isn't good enough. You need to pose a better solution that creates **cleaner, more reliable, or more powerful addresses**.