multiaddr design discussion

[jbenet]

multiaddr design discussion

I'm calling a meeting together to discuss multiaddr protocol specs for:

• onion addresses (cc @ianopolous @lgierth @cryptix @david411 @leif)
• i2p addresses (cc @cryptix @lgierth)
• dns addresses (cc @lgierth)
• http addresses (cc @lgierth)
• ws addresses (cc @lgierth @diasdavid)
• webrtc addresses (cc @diasdavid)
• discuss implementation strategies for go and js (cc @whyrusleeping @diasdavid )

not everyone has to come, but please come if you can. or at least drop your thoughts and insights into this issue.

Goals

• (1) Make concrete decisions for high prio protocols: onion, dns, ws
• (2) Make concrete decisions for rest of protocols listed above.
• (2) Make concrete implementation plans for adding support to go-multiaddr and js-multiaddr

Pre-work

please dump down here in this issue all links to relevant discussions, and any further materials you would like everyone to be aware of. lets do as much work now before the conversation so that we just bikeshed/hash out and decide real-time.

Candidate coordinates

• Sometime monday 4/18. subject to availability of people above, and @RichardLitt 's choosing.
• Following monday?
• Another time.

[jbenet]

cc @leif (typo)

[RichardLitt]

In Calendar for 1pm San Francisco // 4pm New York // 9pm London // 10pm Berlin. Right after the go-ipfs sprint hangout on Monday.

[jbenet]

Everyone involved: since no one has commented here nor put links to relevant discussions, we have not had a chance to review the relevant material for each protocol, thus this conversation will be close to useless. I am postponing it to next Tuesday 4/26 (i am not available next monday).

If you're interested in (a) tor and/or i2p support, (b) websocket + webrtc support, (c) dns support, please join the conversation now, and help us outline all the design constraints and considerations here, in writing, well before this call happens.

[daviddias]

There might have been some kind of glitch with github notifications, because I've been online and checking my notifications everyday and I only learned about this repo now (first time I saw the notification). Like it happened to me, it might have happened to others.

Yes, I'm interested :)

[cryptix]

re tor/i2p:

prev discussions of the top of my head: ipfs/notes#37 (also ipfs/kubo#1118)

as stated in these, by me and others: Slapping these networks on top of ipfs and advertising this as user privacy preserving is quite a stretch, if not negligent.
That part just for the record... Maybe we can talk about alternative client behaviour as well.

BTW: I just saw this in my mail inbox and 4 days in advance is short in my book.
also: Tuesday (past 7pm Berlin time) is the only time of the week I can't make room for.. Sorry.

[RichardLitt]

Moved event on Calendar to same time, Tuesday 26th.

[ianopolous]

@cryptix Thanks for those references. I hadn't seen them!

The core issue as far as multiaddr is concerned seems to be whether a protocol address can have multiple components, with the concrete example of onion addresses coming bundled with their hidden service port (e.g. /onion/aaimaq4ygg2iegci:80 ) /onion/$hash/tcp/$port isn't strictly correct as it isn't a tcp port, just an arbitrary label (virtual port) which the hidden service uses to lookup the actual target. This leaves us with /onion/$hash/$port which requires Protocols to support more than one address component, or inventing a new protocol just for the hidden port, like /hiddenport/$port or /virtualport/$port

Are there any other examples of a protocol addresses fundamentally needing more than one component?

[jbenet]

Thanks @cryptix ! :) 👍

BTW: I just saw this in my mail inbox and 4 days in advance is short in my book.
also: Tuesday (past 7pm Berlin time) is the only time of the week I can't make room for.. Sorry.

Yeah, it is, also through a weekend. was best to move it till later. (this meeting was following up conversations on IRC and over email with a few people)

[jbenet]

@cryptix is the current time good for you? (not sure if its past 7pm your time)

[RichardLitt]

Reopen as needed.

[ghost]

This is still very much needed, and at least /dns, /http, /https are high priority and blocking stuff. We'll also need to discuss multiaddr in the context of fc00.

[RichardLitt]

@lgierth Cool. What needs to move forward for this to happen?

[david415]

The multiaddr for Tor onion addresses will need to somehow at least reference the filesystem location of a 1024 bit RSA private key. That is what is needed by the listener side.

The dialer side of course only needs the onion address and port number.

[jbenet]

@david415

• that address should only be seen locally, right? and then that part is removed (decapsulated) when it is sent to the network.
• does it have to be fs location? could it be the key itself? key agent?
• this is a bit tricky. maybe it should only have the hash of the key and the implementation can figure out hash -> keyFile using a local map or something

[david415]

@jbenet the onion address is valid addressing information from anywhere in the Tor network. what do you mean "should only be seen locally"?

• putting the key itself into the multiaddr is forces us to think about client versus server multiaddrs... whereas until the design is symmetrical. you wouldn't want to leak your private key... but you may well mean to give out the onion address.
• yes indeed perhaps it is a good idea to assume that the context which the onion listener operates already has access to all the keys it needs.

[daviddias]

Let's bring DNS and TLS (as in, baked transports with TLS such as https/wss) to multiaddr, we need it more than ever because it is kind of hard to do apps in JS without HTTPS, as cross domain scripts just won't load //cc @lgierth

Update

We have adopted a format for ws, i.e: /ip4/127.0.0.1/tcp/9200/ws/ipfs/QmHash

[ghost]

We didn't get to discussing it this week, let"s do it on Monday.

[ghost]

• plan for /dns: /dns in multiaddrs multiformats/multiaddr#22 (comment)
• haven't posted the plan for /tls yet, but it's going to land in multiformats/multiaddr too

[ghost]

Notes from the discussion: https://hackmd.io/KbAcFYGYEME4AYC0BjALAMwEyI9YjYAjebVARgHZR5x1VoA2C2IA#

[daviddias]

To make sure that no one accidently deletes the notes, pasting them here:

---

multiaddr discussion

DNS

• /dns in multiaddrs multiformats/multiaddr#22

• when using /dns/name.com/ipfs/<key>, we may end up with
  many different nodes, who should not be sharing <key>.
  we can have them present a per-node key <key-i> that
  is signed by <key>. (certificate chain style).

• maybe use /dns1 and /dns2 to try different addresses

• lars to document proposal 3

• jbenet and lars to document examples using specific record types

• make sure the go-is-domain has a regex check (isDomain)
  vs ICANN list check (isIcannDomain)

• let's go with lars' proposal 3 as /dns3 for now.
  and we will likely promote it to /dns.

TLS

• can do: /http and /https, /ws and /wss

• do we need /tls ?

• where is the certificate? (signal root CAs)

• crypto channels need to have keys, out of band today

• make it easy to host public nodes

  • should not require nginx, reverse proxy, etc.
  • reverse proxy is like a form of NAT
  • may want to specifically model (diagram)

• decouple addresses between:

  • "bound addresses" the ones the nodes actually listen on
  • "advertised addresses" the ones the nodes advertise to the world. (this may vary per "network/interface"?)
  • advertised addresses may depend on interface (like nats)

• start isolating libp2p configs

• https and wss on dialer side

  • (not on listener side, because reverse proxy takes care of it)

(0) host the signalling server behind a reverse proxy with https/ws (for the demos)

(1) host the signalling server behind a reverse proxy with https/wss

(2) get js-ipfs do use it behind a page that is loaded from https (can be the gateway)

(3) create "libp2p" key in ipfs/config.json and create an array of "listenAddrs" and "advertiseAddrs"