`stream.address` definition is wrong

[staltz]

When a connection stream is created and it is passed to onConnection(stream), we calculate the address as:

https://github.com/ssbc/ssb-tunnel/blob/1afa107e12d50f566ced078de4c17b68cdcf827b/index.js#L129-L132

If Alice receives a connection from Bob through a Portal, then that address is supposed to be tunnel:${portalid}:${bobid}, where bobid is provided as the 2nd argument in

https://github.com/ssbc/ssb-tunnel/blob/1afa107e12d50f566ced078de4c17b68cdcf827b/index.js#L178

Here's the problem: when Portal calls Alice's connect(), the RPC this.id refers to the Portal, so the address turns out to be tunnel:${portalid}:${portalid}.

---

The solution should be something like: when the Portal forwards the connect to opts.target, it should also define opts.origin. Then, once the target handles it, it will have info on the origin. What do you think @dominictarr ?

[arj03]

I was testing ssb-tunnel and ran into a similar problem. It seems as if port randomly happens to be the same as instance (0) if its not defined.

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

[staltz]

I think this is still relevant, but not sure because my I forgot the details about this. In ssb-room I fixed this by introducing opts.origin: https://github.com/staltz/ssb-room/blob/6d02ff79a52fb9d7bd87ec024b3de5468f4ae278/tunnel/server.js#L100 and https://github.com/staltz/ssb-room/blob/6d02ff79a52fb9d7bd87ec024b3de5468f4ae278/tunnel/client.js#L208

Changes in ssb-room should be sent upstream to ssb-tunnel

[dominictarr]

The portal should not forward the origin. the target knows the origin because they authenticate with shs. the portal could easily lie about the origin!

I see that there is test coverage that the rpc.id is actually the target and that the target sees the source id too. https://github.com/ssbc/ssb-tunnel/blob/master/test/tunnel.js#L63-L64

I think the correct solution here is just to drop the second element from the address. This code just sets up a multiserver transport, but it's not authenticated until shs happens (which is handled by multiserver after the transport is established). Just because the peer connected through a portal doesn't mean they are also running a tunnel end point.

[dominictarr]

@staltz how does ssb-rooms use address? does it expose it to the user at all? will they believe the stream.address() or will they use rpc.id? (the latter is the secure one)

[dominictarr]

I just noticed https://github.com/ssbc/secret-stack/commit/d48649261455b0a41955de0874428a41b41148d3 I guess you are using this somewhere @staltz ?