First draft of ipfs: URI spec, see #138 #139

pawal · 2016-09-30T13:15:31Z

No description provided.

ghost · 2016-11-02T02:39:46Z

Hey, thanks so much, and sorry for keeping this waiting so long. I'll take a proper look and provide feedback in the next 2 weeks

daviddias · 2017-02-13T16:12:02Z

@nicola this should be on the IPLD org, correct?

ghost · 2017-02-14T01:35:44Z

@nicola this should be on the IPLD org, correct?

Not sure, the fs: URI scheme doesn't seem coupled to IPLD. It sits at the root of the path namespace (it defines the path), and IPLD is just in /ipfs or /ipld.

nicola · 2017-02-14T20:34:24Z

Although it does not belong to ipfs either..
IPFS in the browser?

pawal · 2017-02-14T20:37:35Z

Not sure exactly what you guys are referring to when you say that which sub-project this belongs to. The spec does not refer to either fs: or ipld.

Is there something I should change in the document, or are you thinking of where to publish the spec?

ghost · 2017-03-07T02:09:42Z

Hey @pawal, I'm just getting back into the addressing scheme discussion and it looks like we're pretty close to consensus on the ipfs:// and fs: schemes, their semantics, and the upgrade path. Which is awesome, given the complexity of the issues, and the constraints \o/

Just want to let you know that I'm sorry we weren't very responsive to your PR and contribution (and even stumbled in here with unrelated stuff). Let's wrap up the other discussion and then update the IANA registration docs. I definitely wanna get these sent off :) It's just that wrapping up the addressing scheme discussion is a prerequisite.

From what I understand it'll likely be three documents in the end, for ipfs://, ipns://, and fs:. Do you know how strict IANA are when it comes to registering schemes? Is there a chance they will tell us to revisit everything and come back with just one scheme?

pawal · 2017-03-07T08:07:13Z

Thank you for your update. Just let me know what changes you are planning.

In this case IANA makes us of expert reviewers for registration of new types, and several of them are friendly enough. There is no problem having ipfs and ipns now, and later come in with another URI registration. But we should probably not change ipfs or ipns too much if we want to register them. (Errata is ok.)

You can have a look here and read some of the non-RFC documents: http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

Also read RFC6920 as background material, and reference it in your conclusions.

nichtich · 2017-10-27T09:22:57Z

Any progress on this issue? I need to reference datasets via URIs so IPFS would only be an option if there is an URI scheme

lidel · 2017-10-27T10:29:24Z

I think it is worth noting that a plan was created,
see four stages of the upgrade path for path addressing and

tl;dr

Short-term, URLs:

ipfs://{hash} → http://127.0.0.1:8080/ipfs/{hash}
ipns://{hash} → http://127.0.0.1:8080/ipns/{hash}

Long-term, URI:

dweb:/ip[f|n]s/{hash} → http://127.0.0.1:8080/ip[f|n]s/{hash}

pawal · 2017-10-27T10:38:25Z

So this PR is essentially ok?

lidel

I added some notes on things that changed since 2016 :-)
cc @lgierth for sanity-check

lidel · 2017-11-03T00:16:24Z

uri/README.md

+
+For different applications to handle ipfs references there need to be URIs registered. In order to for applications to understand how to handle the references, the URIs needs to have specificaitions. The generic syntax for URIs are described in [RFC3986](https://tools.ietf.org/html/rfc3986).
+
+The consensus of which URIs need to be specified can be found here: https://github.com/ipfs/go-ipfs/issues/1678#issuecomment-157478515


I think this was updated and superseded by @lgierth's comment at #152 (comment), no?

lidel · 2017-11-03T00:16:56Z

uri/README.md

+
+# Overview
+
+The discussion on what URI schemes that are needed is concluded [here](https://github.com/ipfs/go-ipfs/issues/1678#issuecomment-157478515). The discussion lead to the consensus that these URI schemas are needed:


I would add #152 (comment) here too

lidel · 2017-11-03T00:17:38Z

uri/README.md

+
+ * **[ipfs://](./ipfs.md)** style URI that references IPFS content with the multihash and filepath.
+
+ * **[fs://](./fs.md)** style URI referencing ipfs-specific AND non-ipfs specific hash resolution mechanisms


According to #152 (comment) fs:// URL is replaced by dweb: URI

lidel · 2017-11-03T00:31:12Z

uri/ipfs.md

+Applications/protocols that use this scheme name: ipfs
+
+Scheme syntax:
+   ipfs://ipfs/&lt;multihash&gt;


I think we just go with ipfs://{cid} these days

lidel · 2017-11-03T00:32:05Z

uri/ipfs.md

+Scheme syntax:
+   ipfs://ipfs/&lt;multihash&gt;
+   ipfs://ipfs/&lt;multihash&gt;/path
+   ipfs://ipns/&lt;multihash&gt;


..and ipns://{peerid} instead of ipfs://ipns/{peerid}

daviddias · 2019-10-17T07:13:48Z

@pawal I was going to rebase this PR onto master, but found that it got created in your fork. Would you prefer:

rebasing yourself
creating a new branch from this repo so that I can then rebase it myself?

pawal · 2019-10-17T07:16:16Z

I could perhaps do the rebase later this week. Thanks for the heads up.

I have moved libp2p to github.com/libp2p/spec, keeping all of the commit history there. Some justification given in libp2p/website#8, but mostly this is clear; we have a libp2p organization, and the spec should be there, not in IPFS, now.

change formating to serializing in Record System definition for consistency.

All the code treats it as a `time.Time` and that's the only thing that makes sense here. I know it's just an example but good, correct examples help understanding the ideas and reasoning behind a spec.

…#186)

Co-Authored-By: Adrian Lanzafame <adrianlanzafame92@gmail.com>

Co-Authored-By: Alan Shaw <alan.shaw@protocol.ai>

Co-Authored-By: Adrian Lanzafame <adrianlanzafame92@gmail.com>

Co-Authored-By: Alan Shaw <alan.shaw@protocol.ai>

pawal · 2019-10-20T12:55:20Z

@daviddias Hi, I rebased my fork now. Not sure that everything worked out ok, but it looked fine to me.

lidel · 2019-10-21T20:18:34Z

IIRC this PR was adding two files in uri/ and now changes stuff all over the place 😬
@pawal Try copying uri/ somewhere safe, then delete local branch and recreate it from latest master + add uri/ back and force-push.

pawal · 2019-10-22T09:26:17Z

@lidel - ok, will resubmit. There has been some proposed changes in this PR, but I will redo my original PR and we'll start from there.

lidel · 2019-10-23T13:47:57Z

Thank you! Let's continue in #222

jbenet added the status/deferred Conscious decision to pause or backlog label Sep 30, 2016

First draft of ipfs: URI spec, see #138

fd687ae

ghost self-assigned this Nov 2, 2016

Patrik Wallstrom added 2 commits November 16, 2016 12:10

Merge remote-tracking branch 'upstream/master'

001074a

changed to double-slash since it is paths

f697953

ghost added the status/ready Ready to be worked label Jan 10, 2017

This was referenced Mar 3, 2017

Why doesn't ipfs use real URLs? ipfs/ipfs#227

Closed

Publish dweb: URI spec draft and documentation ipfs/in-web-browsers#28

Closed

This was referenced Mar 3, 2017

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

Closed

Add timthelion's opinion on the dweb:/ipfs vs /ipfs/ debate #153

Closed

lidel requested changes Nov 3, 2017

View reviewed changes

lidel mentioned this pull request Nov 3, 2017

spec: ipfs: and ipns: URI schemes #138

Open

RichardLitt and others added 6 commits October 20, 2019 14:52

Fix links to repos (#144)

95ea52f

Move libp2p to libp2p/spec (#134)

bb43338

I have moved libp2p to github.com/libp2p/spec, keeping all of the commit history there. Some justification given in libp2p/website#8, but mostly this is clear; we have a libp2p organization, and the spec should be there, not in IPFS, now.

match description identifiers

0de7fc8

change formating to serializing in Record System definition for consistency.

feat/public-api/cli - dag-api (#150)

143894e

first pass on the bitswap spec (#95)

621bef0

change r.Expires from time.Duration to time.Time (#140)

e1500be

All the code treats it as a `time.Time` and that's the only thing that makes sense here. I know it's just an example but good, correct examples help understanding the ideas and reasoning behind a spec.

daviddias and others added 23 commits October 20, 2019 14:52

tidy things a bit

a3bc19e

Update README.md

0bff981

fix: update repo specs according to the current state of go-ipfs repo (…

1818bf2

…#186)

spec maintainer protocol stub

78b4d2c

reorg things

99b0293

normalize spec files

d4166c6

add maintainer protocol

5c04552

Update SPEC_MAINTAINER_PROTOCOL.md

5d1d914

Co-Authored-By: Adrian Lanzafame <adrianlanzafame92@gmail.com>

Update SPEC_MAINTAINER_PROTOCOL.md

d641583

Co-Authored-By: Adrian Lanzafame <adrianlanzafame92@gmail.com>

Update README.md

d80ede1

Update SPEC_MAINTAINER_PROTOCOL.md

2d3e9df

Co-Authored-By: Alan Shaw <alan.shaw@protocol.ai>

Update SPEC_MAINTAINER_PROTOCOL.md

f27c4ec

Co-Authored-By: Adrian Lanzafame <adrianlanzafame92@gmail.com>

Update SPEC_MAINTAINER_PROTOCOL.md

97ca93f

Co-Authored-By: Alan Shaw <alan.shaw@protocol.ai>

Update README.md

d0cec2b

Update README.md

f53f981

Update README.md

09e28aa

Update README.md

157eef3

Update REPO_FS.md

c5afe96

Update REPO_FS.md

7bd377c

improve wording

71019eb

remove spec maintainer protocol for now

cf71f06

Add bridged chats

75e203e

use matrix.io instead of riot, move matrix before irc

9ed6cf5

pawal added a commit to pawal/specs that referenced this pull request Oct 22, 2019

First draft of ipfs: URI spec, see ipfs#138, replaces PR ipfs#139

736491a

lidel closed this Oct 23, 2019

lidel mentioned this pull request Apr 1, 2020

Move IPFS addressing spec to ipfs/specs #248

Open

14 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

First draft of ipfs: URI spec, see #138 #139

First draft of ipfs: URI spec, see #138 #139

pawal commented Sep 30, 2016

ghost commented Nov 2, 2016 •

edited by ghost

Loading

daviddias commented Feb 13, 2017

ghost commented Feb 14, 2017

nicola commented Feb 14, 2017

pawal commented Feb 14, 2017

ghost commented Mar 7, 2017

pawal commented Mar 7, 2017

nichtich commented Oct 27, 2017

lidel commented Oct 27, 2017 •

edited

Loading

pawal commented Oct 27, 2017

lidel left a comment •

edited

Loading

lidel Nov 3, 2017

lidel Nov 3, 2017

lidel Nov 3, 2017

lidel Nov 3, 2017

lidel Nov 3, 2017

daviddias commented Oct 17, 2019

pawal commented Oct 17, 2019

pawal commented Oct 20, 2019

lidel commented Oct 21, 2019 •

edited

Loading

pawal commented Oct 22, 2019

lidel commented Oct 23, 2019


		For different applications to handle ipfs references there need to be URIs registered. In order to for applications to understand how to handle the references, the URIs needs to have specificaitions. The generic syntax for URIs are described in [RFC3986](https://tools.ietf.org/html/rfc3986).

		The consensus of which URIs need to be specified can be found here: https://github.com/ipfs/go-ipfs/issues/1678#issuecomment-157478515


		# Overview

		The discussion on what URI schemes that are needed is concluded [here](https://github.com/ipfs/go-ipfs/issues/1678#issuecomment-157478515). The discussion lead to the consensus that these URI schemas are needed:


		* [ipfs://](./ipfs.md) style URI that references IPFS content with the multihash and filepath.

		* [fs://](./fs.md) style URI referencing ipfs-specific AND non-ipfs specific hash resolution mechanisms

First draft of ipfs: URI spec, see #138 #139

First draft of ipfs: URI spec, see #138 #139

Conversation

pawal commented Sep 30, 2016

ghost commented Nov 2, 2016 • edited by ghost Loading

daviddias commented Feb 13, 2017

ghost commented Feb 14, 2017

nicola commented Feb 14, 2017

pawal commented Feb 14, 2017

ghost commented Mar 7, 2017

pawal commented Mar 7, 2017

nichtich commented Oct 27, 2017

lidel commented Oct 27, 2017 • edited Loading

pawal commented Oct 27, 2017

lidel left a comment • edited Loading

Choose a reason for hiding this comment

lidel Nov 3, 2017

Choose a reason for hiding this comment

lidel Nov 3, 2017

Choose a reason for hiding this comment

lidel Nov 3, 2017

Choose a reason for hiding this comment

lidel Nov 3, 2017

Choose a reason for hiding this comment

lidel Nov 3, 2017

Choose a reason for hiding this comment

daviddias commented Oct 17, 2019

pawal commented Oct 17, 2019

pawal commented Oct 20, 2019

lidel commented Oct 21, 2019 • edited Loading

pawal commented Oct 22, 2019

lidel commented Oct 23, 2019

ghost commented Nov 2, 2016 •

edited by ghost

Loading

lidel commented Oct 27, 2017 •

edited

Loading

lidel left a comment •

edited

Loading

lidel commented Oct 21, 2019 •

edited

Loading