Skip to content

Commit

Permalink
Merge pull request #140 from multiformats/marco/multiaddrs
Browse files Browse the repository at this point in the history
Interpreting multiaddrs
  • Loading branch information
MarcoPolo authored Sep 30, 2022
2 parents c950ec4 + 5787c6d commit c964d9a
Showing 1 changed file with 38 additions and 0 deletions.
38 changes: 38 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -44,6 +44,44 @@ Multiaddr solves these problems by modelling network addresses as arbitrary enca

Multiaddr was originally [thought up by @jbenet](https://github.com/jbenet/random-ideas/issues/11).

## Interpreting multiaddrs

Multiaddrs are parsed from left to right, but they should be interpreted right
to left. Each component of a multiaddr wraps all the left components in its
context. For example, the multiaddr `/dns4/example.com/tcp/1234/tls/ws/tls`
(ignore the double encryption for now) is interpreted by taking the first `tls`
component from the right and interpreting it as the libp2p security protocol to
use for the connection, then passing the rest of the multiaddr to the websocket
transport to create the websocket connection. The websocket transport sees
`/dns4/example.com/tcp/1234/tls/ws/` and interprets the `tls` in this context to
mean that this is going to be a secure websocket connection. The websocket
transport also gets the host to dial along with the tcp port from the rest of
the multiaddr.

Components to the right can also provide parameters to components to the left,
since they are in charge of the rest of the multiaddr's interpretation. For
example, in `/ip4/1.2.3.4/tcp/1234/tls/p2p/QmFoo` the `p2p` component has the
value of the peer id and it passes it to the next component, in this case the
`tls` security protocol, as the expected peer id for this connection. Another
example is `/ip4/.../p2p/QmR/p2p-circuit/p2p/QmA`, here `p2p/QmA` is passed to
`p2p-circuit` and then the `p2p-circuit` component knows it needs to use the
rest of the multiaddr as the information to connect to the relay node.

This enables nesting and arbitrary parameters. A component can parse
arbitrary data with some encoding and pass it as a parameter to the next
component of the multiaddr. For example, we could reference a specific HTTP path
by composing `path` and `urlencode` components along with an `http` component.
This would look like
`/dns4/example.com/http/path/percentencode/somepath%2ftosomething`. The
`percentencode` parses the data and passes it as a parameter to `path`, which
passes it as a named parameter (`path=somepath/tosomething`). A user may not
like percentencode for their use case and may prefer to use `lenprefixencode` to
have the multiaddr instead look like
`/dns4/example.com/http/path/lenprefixencode/20_somepath/tosomething`. This
would work the same and require no changes to the `path` or `http` component.
It's important to note that the binary representation of the data in
`percentencode` and `lenprefixencode` would be the same. The only difference is
how it appears in the human-readable representation.

## Use cases

Expand Down

0 comments on commit c964d9a

Please sign in to comment.