Spec refining: Relative paths in IPLD

[nicola]

(reposted from ipfs/specs#112)

Originally in interplanetary paths I included the possibility of having relative paths.

Here I am proposing to add in the specs (and in the js-ipld implementation), the ability to resolve relative paths.
Having relative paths saves space (../, instead of a full hash), helps avoiding splitting things in multiple pieces (../ instead of creating a new object) and finally, allow circular relationships: merkle graph!

{
  nicola: { '/': hashNicola },
  david: { '/': hashDavid }
}

{
  name: "Nicola",
  friends: [{'/':'../david' }]
}

{
  name: "David",
  friends: [{'/':'../nicola' }]
}

---

cc @jbenet, @mildred, @dignifiedquire

[dignifiedquire]

Would these relative paths be restricted to the current object?

[nicola]

We could either restrict them to the current object or as in the proposed in the example, for external objects

[jbenet]

• On one hand, i think this violates the idea of the DAG and will be confusing to people. It's ultimately a dag, but one typical property of DAGs is that when you traverse down an edge, you won't find parts you've already traversed. This effectively turns the DAG into a DG with the possibility of traversal cycles. I don't like that.
• We need to flesh out a lot more complex examples and find "where it confuses everything". Meaning let's figure out "how confusing can this get" and see if we want to stomach that confusion/complexity.
• I think if we do this, we should not restrict it to current objects. it breaks the "transparent resolution" abstraction.

[jbenet]

here's some fun

---
# obj1
a: ../

# what does /ipld/<obj1-cid>/a/a/a/a/a/a/a/a/a/a point to?

---

---
# obj2
a:
  aa:
    aaa: ../../../a/aa/aaa
aa:
  a: ../../
  aa: ../../
  aaa: ../../

---
#  obj3
a: <obj2-cid>/aa
aa: <obj2-cid>/a/aa
aaa: <obj2-cid>/a/aa

# what does /ipld/<obj2-cid>/a/aa/aaa/a/aa/aaa/a/aa/aaa point to?
# what does /ipld/<obj3-cid>/a/aa/aaa/a/aa/aaa/a/aa/aaa point to?

[jbenet]

I'm sure we can craft much worse things. but just a taste of what this enables. It's like a DAG goto

[dignifiedquire]

If we allow the traversal across object boundaries these paths are not unambiguous anymore. Look at this example:

# AAA1
name: cool
value: 1
great: BBB/value

# AAA2
name: cooler
value: 2
great: BBB/value

# BBB
name: secret
value: ../value

In this case great is equal to 1 or 2 for AAA1 and AAA2 respectively. This to me seems very unintuitive and risky. Also what happens if the property does not exist, e.g.

# AAA3
name: something
great: BBB/value

then we look at

AAA3/great = ???

[nicola]

I do understand your complexity concerns and I do share your fears, but at the same time I think that there is something great in this, so let me be the devil's advocate

On the general idea of relative paths

• Relative paths are not new, we have been using them in URLs for years!
• Using relative paths will make the graph a DG on the abstract representation, but at the physical representation it, it is still a DAG

On errors:

• If a path does not resolve upwards, it is the same error that a path does not resolve downwards, the value does not exist.
• If a path goes beyond /, it is an invalid path
• These errors are triggered at evaluation time.

@dignifiedquire in your example, the BBB object will have an invalid path it taken individually. If linked from AAA1 and AAA2 it will not.

The main reason why I would like to have something like that is to avoid having to specify relations through linking through time. For example if I have an RDF object where A links to B and B to A and this relation is not defined by time, it would be great to timestamp this relation at time 0. This would make authenticating RDF much simpler than creating OP-logs. This would be something like this:

Implicit (relative paths that are local)

hashX

{
  A: { rel: ../B }
  B: { rel: ../A}
}

Explicit (relative paths across objects)

// sorry I will just use JSON, but this applies to JSON-ld and any other RDF format
hash0
{
  A: hash1,
  B: hash2
}

hash1
{
  rel: ../B
}

hash2
{
  rel: ../A
}

[Stebalien]

I'm strongly against allowing relative paths between objects for several reasons:

1. It means objects don't have "canonical" paths that traverse exactly one object. That is, I'd like to be able to convert /ipld/HASH/my/long/path//rest (where a new object starts at //) into /ipld/HASH/rest and treat them as interchangeable paths. With this proposal, those might be different objects.
2. This is problematic from a security perspective. Currently, I can sign an object at any level of a DAG and know what I'm signing can't change under my feet. With relative links like this, that no longer holds true.

[jbenet]

(( Yeah. relative links may be a siren feature. So attractive and powerful, but tons of complexity introduced. ))

[nicola]

@Stebalien

1. I am not sure if this example should be supported - but no it would not work if it would be
2. you don't just sign the leaves (so the objects have only have relative links), it would be meaningless not having the parent not signed

(I am personally not arguing for or against, I just want to make sure we dont cut off features)

[nicola]

In the previous call (ipfs/team-mgmt#181, see the results here: ipfs/team-mgmt#181) we have concluded that:

1. (to agree) We want relative links in the object itself (so no relative links across objects), these links should not form cycles and parsers/resolvers should return errors (although I think if an object has very many relative links, it could become expensive to check for cycles)
2. 🎉 There are ways to represent cycles (on a data structure level) on an application level
3. 🎉 No relative links across objects

[Stebalien]

🎉 No relative links

... from a child object to a parent object.

[nicola]

Updated, thanks @Stebalien

[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]