Extending multiaddr table per Application

[daviddias]

Anything in the works to make it plugabble? In case I need to support some custom protocol for my app like:
"/ip4/104.236.151.122/david-protocol/best-protocol-eva!"

[jbenet]

The problem is agreement on the protocol table. multiaddr requires reserving a name + code.

but yes, it should be extensible.

not sure what the best way of doing this is that will not lead to just packing a bunch of protocols nobody else cares about into everyone's code.

for now, for the ../ipfs/... addrs, we just defined it app-side. we could add ipfs for convenience here, but not sure what bar to set for "my-random-protocol-i-just-made-up" given registering a name assigns a code and may increase the space cost for others. (iana numbers are full of dead protocol numbers nobody uses...)

[jbenet]

(anyway, very open to suggestions, just mentioning constraints)

[keks]

One idea would be to define a meta-protocol uuid that is followed by a longer id that can be chosen freely by third-party implementors. If one of these protocols gains traction, it can still be included in this file.

Example:

code    size    name
511     V       uuid

Say uuid 213ae898-1892-44c2-a79e-ae512734ce38 is a repliable datagram in the I2P network SAM spec. So the string representation of a multiaddr of using a repliable I2P datagram would be

/uuid/213ae898-1892-44c2-a79e-ae512734ce38/$destination

UUIDs are always 16 bytes long, so this is how they can be stored in the binary representation.

Alternatively, the uuids could be longer and actually ipfs-adresses of the protocol specification document.

[keks]

Hang on, I just realized that this breaks the (/proto/value/)+ criterium. Maybe just remove the uuid part in the beginning:

/213ae898-1892-44c2-a79e-ae512734ce38/$destination

if the text is an unknown protocol, assume its a UUID.

[jbenet]

👎 for UUID protocols. its not hard to make PR with a case for a reserved name.

[keks]

I thought this was the part that didn't scale well?

[daviddias]

Now with the multicodec table being universal for all multiformats, we can achieve this more easily by having reserved spaces for domain specific protocols.

See implementation discussion here: multiformats/js-multiaddr#22

[Stebalien]

So, this becomes a problem when proxying/passing multiaddrs around. Concretely,

go (dialer) --tcp-> js (relay) --websocket-star-> js (listener)

Currently, go doesn't know about the websocket-star protocol so it literally can't dial this address even though all the underlying transports should be able to do so.

Unfortunately, we can't just pass over the unknown protocol codes as we have no way of knowing their argument lengths. In some cases, we can solve this by parsing the first part of the address and passing the rest to the next hop but I'm not convinced that completely solves the issue.