Multihashes/transport agnostic names in relation to service naming

[ramwan]

https://github.com/jbenet/random-ideas/issues/1 https://github.com/libp2p/specs/blob/master/3-requirements.md https://github.com/multiformats/multihash

IPFS and Libp2p use multihashes, where the hash describes what kind of hash, as well as highly descriptive content addresses which show what transport protocols and ip addresses are used.

Could this be a basis for service naming?

[ramwan]

snippet from libp2p/specs requirements relevant

libp2p is transport agnostic, so it can run over any transport protocol. It does not even depend on IP; it may run on top of NDN, XIA, and other new Internet architectures.

In order to reason about possible transports, libp2p uses multiaddr, a self-describing addressing format. This makes it possible for libp2p to treat addresses opaquely everywhere in the system, and have support for various transport protocols in the network layer. The actual format of addresses in libp2p is ipfs-addr, a multiaddr that ends with an IPFS node id. For example, these are all valid ipfs-addrs:

IPFS over TCP over IPv6 (typical TCP)

/ip6/fe80::8823:6dff:fee7:f172/tcp/4001/ipfs/QmYJyUMAcXEw1b5bFfbBbzYu5wyyjLMRHXGUkCXpag74Fu

IPFS over uTP over UDP over IPv4 (UDP-shimmed transport)

/ip4/162.246.145.218/udp/4001/utp/ipfs/QmYJyUMAcXEw1b5bFfbBbzYu5wyyjLMRHXGUkCXpag74Fu

IPFS over IPv6 (unreliable)

/ip6/fe80::8823:6dff:fee7:f172/ipfs/QmYJyUMAcXEw1b5bFfbBbzYu5wyyjLMRHXGUkCXpag74Fu

IPFS over TCP over IPv4 over TCP over IPv4 (proxy)

/ip4/162.246.145.218/tcp/7650/ip4/192.168.0.1/tcp/4001/ipfs/QmYJyUMAcXEw1b5bFfbBbzYu5wyyjLMRHXGUkCXpag74Fu

IPFS over Ethernet (no IP)

/ether/ac:fd:ec:0b:7c:fe/ipfs/QmYJyUMAcXEw1b5bFfbBbzYu5wyyjLMRHXGUkCXpag74Fu

considerations for using a multihash/multiaddress

Snatched from https://github.com/multiformats/multihash

``` fn code dig size hash digest -------- -------- ------------------------------------ 00010001 00000100 101101100 11111000 01011100 10110101 sha1 4 bytes 4 byte sha1 digest ``` Where can we get IDs for hash functions and whatnot? - potentially allow users to create their own custom suites of hash functions and have that suite ID be specified in a fixed length field in the multihash - multihash has created a [table](https://github.com/multiformats/multihash/blob/master/hashtable.csv)

From jbenet's issue (https://github.com/jbenet/random-ideas/issues/1 perhaps not all of these are immediately relevant)

• being able to hash a service name in multiple ways even with the same hash means there may be a huge number of ways a single service can be referred to with the same hash function
  • solution ?: probably define a set format for hashing service names
• re-purposing UTF implementation

[ramwan]

@CMCDragonkai

[CMCDragonkai]

I like the idea of using multihash spec for our hashes and potentially multiaddr where its relevant. However due to our experience developing the libp2p stack in Haskell, I dont think its ready to avt as the underlying transport. We still want to use the kernel networking stack and take advantage of bpf.

[ramwan]

Upon looking a bit further at multiaddress/hashing, I've thought that potentially we could actually use multihashes as a further layer of indirection between the flow abstraction and concrete network addresses (in the diagram https://github.com/MatrixAI/Relay/issues/9#issuecomment-403346232).

My reasoning for this is to allow interoperability between different network layers - the Matrix network should be able to span IPv4 and IPv6 (and whatever other network addressing schemes people use) as long as there is at least one physical machine interfacing with both networks. Whether the current haskell implementation of multiaddr is suitable or not, I'll have to see.

[ramwan]

Referring to https://github.com/MatrixAI/Relay/issues/9#issuecomment-403713428 where I noted that service names could be regular URLs to allow containers to run outside of a Matrix network without too much change from developers, I'd need to see whether multiaddresses are beneficial to use in the intermediate step of mapping an automaton's virtual flow identifier to physical interfaces and vice versa.

[ramwan]

closing issue as the idea is relevant overall would be better talked about in experiment results, designs and other issues

[CMCDragonkai]

If this is in backlog, the issue should be still open.