Protocol specifiers are ambiguous?

[icefoxen]

If you use Unix file paths and delimiters, it seems like it would be really easy to make things ambiguous.

First off, I don't see a "file" protocol type, is this the the unix protocol type listed in protocols.csv?

If so, what happens if I make a file path /home/icefox/tcp/127.0.0.1/foo and try to represent it as a multiaddr path?

/unix/home/icefox/tcp/127.0.0.1/foo

Okay, that's a little artificial, and you could specify that you can disambiguate from context; a unix protocol address cannot contain a tcp protocol subaddress. Though that seems to defeat the purpose; things stop being self-describing and become context-dependent. (And on Plan9 you certainly can do TCP via the filesystem.)

Okay, what about a more concrete example using already defined protocols:

/wss/example.com/http/example.com

Is this accessing the websockets endpoint wss://example.com/http/example.com, or is it trying to nest the HTTP protocol inside the websockets endpoint wss://example.com/ ?

[ntninja]

(Yes, I know this has been open for quite some time, but since nobody responded…)

I think you were being misled here:
MultiAddr is not about describing paths to data, but rather about describing paths to endpoints (applications on hosts). Your example of trying to describe a file path (/home/icefox/tcp/127.0.0.1/foo) therefor makes no sense in the context MuiltAddr, since it simply cannot describe these kinds of things. There is also no application you need to talk to to get access to that file hence there is no need for MultAddr at all.
(You could argue that you are still talking to the kernel hence on could argue that /kernel or /kernel-vfs or maybe also just /file may make sense, but that's not really what you meant to say.) The /unix protocol refers to Unix domain sockets, not UnixFS-paths by the way.

Regarding the second example (/wss/example.com/http/example.com): First of all this doesn't mean what you probably intended it to mean, since that literally says establish a secure websocket connection somewhere using the HTTP/WS host field example.com, then talk HTTP for host example.com over that connection. As in, you are generically describing HTTP tunnelled over WSS here. You are also not adding any kind information where an application using this should connect to establish that WebSocket connection in the first place; a smart application may figure out that you meant /dns/example.com/tcp/tls/ws/example.com/http/example.com – or it may not. So, to stick with the well-known URL notation, what you actually described there is closest to the HTTP base URL http://example.com/ tunnelled over wss://example.com/ but it cannot fully be expressed like this. So yes, you could say it is being nested.

@Stebalien: Do you think this answers the above questions decently?