update ipld spec with new link fmt #101
Conversation
|
There is still a paragraph referencing
|
|
The section on |
|
|
||
| If an application wants to use the `@link` key for other purposes, the application itself is responsible to escape the keys in the IPLD object so that the application keys do not conflict with the `@link` key. When discussing application specific paths, it may be worth escaping all keys starting with `@` in case future versions of IPLD make use of other keys. | ||
| **Object with pseudo "link object" at `files/cat.jpg` and actual link at `files/cat.jpg/link`** |
There was a problem hiding this comment.
This seems to be new to me and problematic when building it into the resolver. I was under the impression key like "link" would not have a special meaning, but with this you are effectively giving them one.
Also this seems ambiguous to me, consider this object:
{
"files": {
"cat.jpg": {
"coolLink": {"/": "/ipfs/Qm..AAA"},
"link": {"/": "/ipfs/QmBBB"},
"mode": 0755
}
}
}then how should files/cat.jpg be resolved? Objects are not inherently ordered in JavaScript so we can not guarantee the same resolution if we say first come, first serve.
There was a problem hiding this comment.
@dignifiedquire no, there's nothing special going on. the link keyword here is not special at all, it just shows how someone might model a data structure that requires associating properties with a link. Ex:
> ipld get .../files/cat.jpg
{
"coolLink": {"/": "/ipfs/Qm..AAA"},
"link": {"/": "/ipfs/QmBBB"},
"mode": 0755
}
> ipld get .../files/cat.jpg/coolLink/
<resolves through coolLink>
> ipld get .../files/cat.jpg/link/
<resolves through link>
There was a problem hiding this comment.
Okay great, then I just misunderstood
|
@dignifiedquire thanks, removed those |
This changes the spec to update the link fmt. Please review it carefully and suggest changes. This was a great simplification. thanks everyone.
See: