search

multiformats / multiaddr

Composable and future-proof network addresses
https://multiformats.io/multiaddr
MIT License
424 stars 85 forks source link

Extending multiaddr table per Application #6

Closed daviddias closed 8 months ago

daviddias commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

keks commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

:-1: for UUID protocols. its not hard to make PR with a case for a reserved name.

keks commented 8 years ago

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

daviddias commented 7 years ago

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: https://github.com/multiformats/js-multiaddr/issues/22

Stebalien commented 6 years ago

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.