Spec refining: Mutable links in IPLD

[nicola]

As soon as we allow mutable links in IPLD we lose some of the functional authenticated data structure properties. In other words, we cannot any more do reasoning that assume immutable datasets.

Proposal 1: assumption on the name spaces

However, we could allow mutable links, as long as mutable link can be differentiate from an immutable one, say "/ipns/HASH", we are able to specify in the IPLD parser that IPNS is mutable (which add complexity to the parser as soon as we are going to have other addresses)

Proposal 2: explicit mutable links

Being explicit, say that / is immutable, ~ is mutable. However developers can run in a lot of errors by putting immutable links in ~ (which is safe) and viceversa (that is not safe)

{
  test: { '~': '/ipns/hash'}
}

---

cc @diasdavid, @dignifiedquire, @jbenet, @mildred

[daviddias]

P2 would make the selector/path traversal have to handle the caching, while the implicit/namespaced would defer that to the subsystems that handle that resolution. Caching is hard, both in making the hard decision and on letting users do it, if it makes sense, we might do both.

[jbenet]

• we may loose the "functional" part. the "authenticated" may still remain (can authenticate with signatures in ipns) if we force an authenticated namespace. but may increase complexity.
• the question to decide is whether "mutable links" are part of IPLD or part of something larger. (i would think something larger is the right decision, but im not 100% sure)
• we can have a link be { /: /ipns/...} and IPLD would not natively resolve through it, throwing it up to the user / client. a better resolver can then pick up and resolve through ipns. This is actually how the name resolution code in go-ipfs works right now, allowing us to resolve /ipns/<dns-name>, /ipns/<hash-of-public-key>, /ipfs/<hash-of-object>/... It's a resolver with child resolvers.
• the ~ is a neat idea. but where does it stop? why just / and ~? why not a bunch of other things? At first pass, i think it's going to be much simpler to allow other links (external-to-ipld links) under /, which are denoted with the namespace.
• think of the link as an fs-IRI. (IRI with a different scheme identifier).

[jbenet]

• i will say though that mutable links are a much requested feature, and feature in SFS originally, and i think they're super awesome to have. i'm just not sure at what level to put them in. Mutable namespaces seem like a thing above IPLD. (like authenticated streams are above IPLD)

[nicola]

Thanks @jbenet. This is my actual problem:

Given an IPLD graph, I want to prove a few things according to the graph shape. To do this, I need to make sure that the links that appear are all immutable (it is fine to have mutable links, as long as I can distinguish them). How can I distinguish immutable with mutable links?

• It is fine to have mutable links and lose the functional aspect (as long as we have this distinguisher)
• This distinguisher can be one (like ~) or individual per namespace (like ipns, dns, and the next 10 mutable name spaces).
• Choosing between either is fine, (1) one is very generic and it is a new keyword, (2) the other one is clean (backward compatible if it means anything) but requires parser knowledge (which I think it is also fine, since eventually the parser, even if we use ~, it is expected to know how to parse /ipns, or to consider ONLY /ipld immutable).

I kind of prefer that we make sure our parsers know the table of the immutable namespaces and leave it as it is (see my very last point)

[jbenet]

Yes, use mutable namespaces.

Remember that doing things like putting the distinguisher in the link key
means sideband knowledge. This type of thing is pernicious-- it's what
multiformats are all about avoiding. The namespace makes sure it remains
in-band
On Sun, Aug 7, 2016 at 05:13 Nicola Greco notifications@github.com wrote:

Thanks @jbenet https://github.com/jbenet. This is my actual problem:

Given an IPLD graph, I want to prove a few things according to the graph
shape. To do this, I need to make sure that the links that appear are all
immutable (it is fine to have mutable links, as long as I can distinguish
them). How can I distinguish immutable with mutable links?

• It is fine to have mutable links and lose the functional aspect (as
  long as we have this distinguisher)
• This distinguisher can be one (like ~) or individual per namespace
  (like ipns, dns, and the next 10 mutable name spaces).
• Choosing between either is fine, (1) one is very generic and it is a
  new keyword, (2) the other one is clean (backward compatible if it means
  anything) but requires parser knowledge (which I think it is also fine,
  since eventually the parser, even if we use ~, it is expected to know
  how to parse /ipns, or to consider ONLY /ipld immutable).

I kind of prefer that we make sure our parsers know the table of the
immutable namespaces and leave it as it is (see my very last point)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIcoXveSfNMSoI2eGMJeU4IV384V9vhks5qdaHRgaJpZM4JWhIn
.

[jbenet]

IPLD parsers need only to understand /ipld.
On Sun, Aug 7, 2016 at 07:06 Juan Benet juan2@benet.ai wrote:

Yes, use mutable namespaces.

Remember that doing things like putting the distinguisher in the link key
means sideband knowledge. This type of thing is pernicious-- it's what
multiformats are all about avoiding. The namespace makes sure it remains
in-band
On Sun, Aug 7, 2016 at 05:13 Nicola Greco notifications@github.com
wrote:

Thanks @jbenet https://github.com/jbenet. This is my actual problem:

Given an IPLD graph, I want to prove a few things according to the graph
shape. To do this, I need to make sure that the links that appear are all
immutable (it is fine to have mutable links, as long as I can distinguish
them). How can I distinguish immutable with mutable links?

• It is fine to have mutable links and lose the functional aspect (as
  long as we have this distinguisher)
• This distinguisher can be one (like ~) or individual per namespace
  (like ipns, dns, and the next 10 mutable name spaces).
• Choosing between either is fine, (1) one is very generic and it is
  a new keyword, (2) the other one is clean (backward compatible if it means
  anything) but requires parser knowledge (which I think it is also fine,
  since eventually the parser, even if we use ~, it is expected to know
  how to parse /ipns, or to consider ONLY /ipld immutable).

I kind of prefer that we make sure our parsers know the table of the
immutable namespaces and leave it as it is (see my very last point)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIcoXveSfNMSoI2eGMJeU4IV384V9vhks5qdaHRgaJpZM4JWhIn
.

[nicola]

Thanks @jbenet. Ok, we agree that we will use the name space as distinguisher. 🎉

The namespace makes sure it remains in-band

(maybe bikeshedding here) I don't think that the namespaces are descriptive of their mutability properties the way you describe "in-band". To understand if a path is going to be immutable or not you will need a table of namespaces saying which one is immutable, which one is not (which to me sounds out of band). An in-band solution, imho would be something like prefixing a bit to a path to describe mutability.

IPLD parsers need only to understand /ipld.

Not when we have something like:

hash0
{
  bestFriend: {'/' : '/ipns/currentBestFriend/name'}
}

How does IPLD resolve this hash0/bestFriend, assuming that the parser has locally all the data it needs? Is this done by the parser (hence the parser needs to understand beyond that?) or IPLD would not resolve that? Or we avoid having IPNS in IPLD link objects, but they can be interpreted on the user/application level?

Also, in this case:

1. I will not be able to know that this path is mutable or not, by looking at the path hash0/@bestFriend would (I don't like this, @ would be the bad distinguisher you are mentioning - kind of equivalent to ~)
2. I will be able to know whether this path is mutable or not by looking at the object & finding that bestFriend points to an IPNS and I will need to have a table somewhere telling me that IPNS is actually mutable (so my parser will need to know this)

[jbenet]

Yeah I hear you.

You also need a table of some sort to know that bit means mutability. It's
different, less info sideband and more flexible (many namespaces can use
that bit), but it's not completely in band either. Trade offs.

May be that mutable bit would be a better way. I'm just not are atm. Trying
to keep down abstraction overheads/friction, but I also recognize I'm
biased. I'm reminded of "/ipld /ipfs /ipns" or "/ip/ld, /ip/fs, /ip/ns".
Many Trade offs too.
On Sun, Aug 7, 2016 at 09:05 Nicola Greco notifications@github.com wrote:

Ok, we agree that we will use the name space as distinguisher.

(maybe bikeshedding here) I don't think that the namespaces are
descriptive of their mutability properties the way you describe "in-band".
To understand if a path is going to be immutable or not you will need a
table of namespaces saying which one is immutable, which one is not (which
to me sounds out of band). An in-band solution, imho would be something
like prefixing a bit to a path to describe mutability.

IPLD parsers need only to understand /ipld.

Not when we have something like:

hash0
{
bestFriend: {'/' : '/ipns/currentBestFriend/name'}
}

hash0/bestFriend

In this case:

1. I will not be able to know that this path is mutable or not, by
   looking at the path hash0/@BestFriend would (I don't like this, @
   would be the bad distinguisher you are mentioning - kind of equivalent to
   ~)
2. I will be able to know whether this path is mutable or not by
   looking at the object & finding that bestFriend points to an IPNS and I
   will need to have a table somewhere telling me that IPNS is actually
   mutable (so my parser will need to know this)

How does IPLD resolve this pathing, assuming that the parser has locally
all the data it needs?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIcod4NN4p0laJLIoBJUm2UA_CryT8Uks5qddgjgaJpZM4JWhIn
.

[singpolyma]

Namespaces seem to no longer be used in links at all... have we given up on mutable links?

[rvagg]

Closing due to staleness as per team agreement to clean up the issue tracker a bit (ipld/team-mgmt#28). This doesn't mean this issue is off the table entirely, it's just not on the current active stack but may be revisited in the near future. If you feel there is something pertinent here, please speak up, reopen, or open a new issue. [/boilerplate]