Define /unix
#174
Define /unix
#174
Conversation
Adds a protocol note for how to encode paths to Unix domain sockets as strings, that may include the delimiting character of `/`. This allows us to append other tuples to the multiaddr while also ensuring we can round-trip the address to a string and back. This doesn't affect the binary representation of the multiaddr since everything is length-delimited. Takes inspiration from #164 and proposes using URI encoding for the segment, the same as the `/http-path` component. One difference is if the path is to represent the filesystem root, it must be included in the value portion of the tuple, otherwise it can be omitted.
Need to resolve how to encode unix paths so peer ids can be appended to them - multiformats/multiaddr#174
|
Are there any backwards compatibility issues? Is anyone using this multiaddr currently? |
I'm not sure how heavily it's utilized, but kubo can use those addresses. e.g. https://github.com/ipfs/kubo/blob/4009ad3e5a502518ddc7d48a888707f812ddc629/docs/config.md?plain=1#L219 |
I haven't looked too deeply at usage, but I'd suspect so. The question is what to do about it. There are a bunch of issues that are basically about the failures related to protocols (like http or unix) in taking unescaped paths like #139 #55. They were also known from the earliest days multiformats/go-multiaddr#31. Maybe the answer is to just break it, or to say that implementations MAY/SHOULD/MUST preferentially try looking for the entire path as a socket and if that fails will try with just the first path segment as a socket. Not specific to this PR, but between http-path and this perhaps worth biting the bullet on specifying how "path" types should be done in general. Maybe the answer is just to require them all to be escaped, maybe it's something else (e.g. closer to @Stebalien's proposal in multiformats/multiformats#55). |
|
There will be backwards compatibility issues with the string representation of the path due to the escaping, though not with the binary representation. I think this is used but not very commonly. The js stack can also use unix addresses but currently only as a terminal element, that is no tuples can follow it. Arguably the lack of escaping has harmed it's use - I know I've tried to use it a few times over the years but always come up hard against the inability to append anything else to the address and the various issues asking for clarification etc speak to a need for this.
I wonder if this could get exploited by making longer paths with segments that mirror tuples after the unix section? Possibly with
I kind of think so. The original PR was merged in haste, the question about if we need to append things to it was unresolved. It was flagged as experimental and subject to change so..
It's interesting that - it seems to mandate parsing paths left to right, we recently switched multiaddr-to-uri to parsing right to left to support some forms of multiaddr. It also doesn't seem to say much about escaping so we'd probably still need to solve the same problem there. |
|
Are there any further thoughts here? |
|
@achingbrain: Since I just noticed it wasn’t mentioned I'd just like to mention my old MultiAddr proposal from 2019 again: #87 It’s mainly about argument to individual MultiAddr path segments, but it also proposes syntax for encoding paths in MultiAddr segments:
This is IMHO significantly easier to read than using percent-encoded local file system paths. |
|
Thanks, I didn't see that issue. I like your proposal for using To solve this particular issue though, I would prefer to be consistent with other multiaddr tuple types. HTTP has already solved this problem by percent escaping the characters so I think we should use that here too. |
|
@achingbrain: I can see where you’re coming from, but I’d just like the point out that the major benefit, besides nicer style, is the fact that it’s backwards-compatible! (We are talking about MultiAddr v1 here after all. 🙂) I know most of the MultiFormat people tend to lean on the string-representation => unimportant side, but at least By contrast, Not saying you shouldn’t go with your proposal, but that is something to thoroughly consider I think! |
|
Are there any limitations on the character set that can be used in a path? I'm assuming that the characters are all UTF-8 encoded so unicode characters like ↑ (e.g. up arrow, UTF-8: |
Not really, it's kind of the wild west since most "unix" implementations can trace their lineage prior to UTF-8 and other modern conveniences. POSIX has a definition of portable file name characters but realistically it could be UTF-8, ASCII or char[]. I think just not NUL As per this proposal Full details are in RFC 3986, linked to from the proposed changes in the PR. |
Summary
Adds a protocol note for how to encode paths to Unix domain sockets as strings, that may include the delimiting character of
/.This allows us to append other tuples to the multiaddr while also ensuring we can round-trip the address to a string and back.
This doesn't affect the binary representation of the multiaddr since everything is length-delimited.
Takes inspiration from #164 and proposes using URI encoding for the segment, the same as the
/http-pathcomponent.One difference is if the path is to represent the filesystem root, it must be included in the value portion of the tuple, otherwise it can be omitted.
Before Merge