ipfs/specs

Feedback for the Suborigin working group

Opened this issue · 8 comments

Deleted user commented

@jbenet mentioned in Lisbon that now is the time to direct feedback at the Suborigin working group [1]. In fact it might already be too late as their 31-Jul-2016 was the "recommendation" milestone date. Anyhow I wanna write up our use case and requirements and possible need for changes, and send it their way.

Let me know if this repo is not a good place for this.

[1] https://www.w3.org/2014/12/webappsec-charter-2015.html

Deleted user commented

In fact it might already be too late as their 31-Jul-2016 was the "recommendation" milestone date.

Wrong about this one. I'll try and figure out what the actual milestones for suborigin are. Their website lists Dec-2015 for the respective recommendation milestone, so that's clearly out of date.

Deleted user commented

I think Suborigins still fit our use case and I don't have pressing feedback right now. What's breaking the current suborigins implementation in go-ipfs is the recent requirement that identifiers be lowercase, in order to be able to construct RFC6454-compatible origins.

It looks like we'll need HSHCA here, a "multihash encoded in Base32 RFC 4648, downcased and stripped of its padding", which is fit to be used in hostnames and should yield RFC6454-compatible suborigin-names. Thanks @kyledrake :):)

LOWERALPHA = %x61-7A   ; a-z
suborigin-name = 1*( LOWERALPHA / DIGIT / "-" )   ; DIGIT as defined by RFC5234

Here's a reading list:

  • 👍1
dignifiedquire commented

Thanks @lgierth for this! I will read through the links this week and comment afterwards.

Kubuxu commented

We use base32 without padding in the datastore already so it shouldn't be hard to implement.

As we do that we should support both ipns and ipfs.

So maybe we should do base32 encode whole first two segments of canonical path so we don't limit our self in future.

Suborgin is either way an unique ID and doesn't have to have clear text meaning.

Deleted user commented

So maybe we should do base32 encode whole first two segments of canonical path so we don't limit our self in future.

Mh my thinking was it's not neccessary because there's provably no ipfs object for a given peerid hash and vice versa. And if that assumption falls it's still forward-compatible because we can easily just change the suborigin value since it's opaque to the user-agent. Also since it's opaque, user-agents must not infer information from it, like whether it's /ipfs or /ipns.

The upside I see with just simple v1 CIDs in base32, is that the same value works with ipfs.io/ipfs/<hash>, <hash>.ipfs.io, ipfs cat, and the suborigin header. (and the same for /ipns and <hash>.ipns.name.)

Kubuxu commented

Yes but it should also work for dns names and in future with ipld space and view transformations.

Also changing the suborgin will have side-effect of removing all locally stored data like user settings, keys and other browser stored data.

Kubuxu commented

@lgierth for 0.4.5 we should either: disable suborgins (the only browser implementing them refuses to work with them) or fix it and publish to 0.4.5.

See: ipfs/kubo#3209

I think the suborgins spec is still WIP so maybe we should just disable them for time being.