From e7e5c51e95a230e748001b0b91e19ef05dee6c5b Mon Sep 17 00:00:00 2001 From: Mildred Ki'Lya Date: Fri, 8 Jan 2016 09:07:14 +0100 Subject: [PATCH] Talk about escaping keys in merkle-paths --- merkledag/ipld.md | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/merkledag/ipld.md b/merkledag/ipld.md index cb244771..6342b18d 100644 --- a/merkledag/ipld.md +++ b/merkledag/ipld.md @@ -72,6 +72,23 @@ O_5 = | "hello": "world" | whose hash value is QmR8Bzg59Y4FGWHeu9iTYhwhiP8PHCN This entire _merkle-path_ traversal is a unix-style path traversal over a _merkle-dag_ which uses _merkle-links_ with names. +**[In case we use escaping in protobuf IPLD format]** + +In order to not restrict individual path component by disallowing some file names and still allow storing arbitrary data in IPLD objects, path components must be escaped when they are looked up in IPLD objects. + +To escape a path component in order to look it up in an IPLD object: + +- every `\` character in the path component must be replaced with `\\` +- every `@` character in the path component must be replaced with `\@` + +This makes any key containing a `@` character unescaped in an IPLD object not accessible through a _filesystem merkle-path_. This is a reserved key that can be used to store auxiliary data without making it a link and visible in regular filesystems. This data can be made available in filesystems through extended attributes or opening and reading file contents. + +To unescape IPLD object keys that are not reserved and get the corresponding path component: + +- every `\@` sequence in the key must be replaced by `@` +- every `\\` sequence in the key must be replaced by `\` + + ## What is the IPLD Data Model? The IPLD Data Model defines a simple JSON-based _structure_ for all merkle-dags, and identifies a set of formats to encode the structure into. @@ -327,7 +344,7 @@ The conversion to the IPLD data model must have the following properties: - It should be convertible back to protocol buffers, resulting in an identical byte stream (so the hash corresponds). This implies that ordering and duplicate links must be preserved in some way. - When using paths as defined earlier in this document, links should be accessible without further indirection. This requires the top node object to have keys corresponding to link names. -- Link names should not conflict with other keys. +- Link names should be able to be any valid file name. As such, the encoding must ensure that link names do not conflict with other keys in the model. There are multiple ways to do that that will be described next.