<zignig>
I met some guys doing a wireless mesh in perth , they have 20+ point to point nodes , the seems keen to get IPFS going , but the wanted to ensure a private swarm.
Leer10 has quit [Quit: Leaving]
pfraze has quit [Remote host closed the connection]
<lgierth>
zignig: they can restrict dials to the ip prefix they're using
<dawuud>
today i wrote a TorDialer and OnionListener
<whyrusleeping>
dawuud: nice!
<whyrusleeping>
shouldnt be too hard to plug that into multiaddr-net
<dawuud>
i'll have to gradually add more features to the OnionListener... it's kind of a hassle to configure tor properly and setup all the permissions so that the onion address can be created via control port and key material read by group member after creation etc.
<dawuud>
whereas the new control port ephemeral onion services api should make this easier
<whyrusleeping>
yeah, but it looks like you have a lot of stuff done already
* whyrusleeping
reading controller.go
<dawuud>
also we can do like txtorcon does and just create a custom torrc and then launch our own tor process
<lgierth>
dawuud: that's what /tor/example.net/tcp/80 could expand to. for the application it's kinda transparent that tor is involved, right? i mean it only knows there's a socks5 proxy
<dawuud>
so the question is weather to make a generic socks multiaddr or individual ones for each protocol that has a socks like interface
<dawuud>
i don't know the answer to that.
<dawuud>
but understand the /onion/ case is different
<lgierth>
can /tor carry ip4 and ip6?
<dawuud>
certainly not. tor only transports streams.
<dawuud>
however the exit nodes use ipv4/ipv6
<dawuud>
also the relays happen to use that as well...
<lgierth>
i think /tor/example.com/ip4/tcp/80 would be fine then
<lgierth>
or .../ip6/...
<dawuud>
yeah
notduncansmith has joined #ipfs
<dawuud>
yeah... the multiaddr doesn't have to represent the protocol stack...
notduncansmith has quit [Read error: Connection reset by peer]
Eudaimonstro has quit [Ping timeout: 252 seconds]
<dawuud>
but instead it could represent a stack of address types that might not be layered using end to end encapsulation
<dawuud>
in that case perhaps /onion/fufu.onion/tcp/80 makes sense?
<lgierth>
is /onion always ip4?
<lgierth>
or tcp without ip below?
<dawuud>
tor hidden service operators can have a application daemon listen locally (usually on loopback) and the tor process proxies connections to that addr:port
<dawuud>
likewise the user of such an onion service connects to their socks proxy usually via ipv4:tcp_port...
<dawuud>
however we could put socks on a unix domain socket
<dawuud>
so conceptually it's not even ip or tcp it's a stream transport
<lgierth>
i see, that sounds like tcp, with ip abstracted away, so /onion/fufu.onion/tcp/80 sounds suitable
<lgierth>
mh ok
<dawuud>
well it's not pure tcp because the congestion management at each relay on the 3 hops of the circuit don't affect the onion connection in the same way if it was a normal tcp
<dawuud>
so in that sense the multiaddr isn't a protocol stack but an addressing stack if we do /onion/fufu.onion/tcp/80
<fleeky>
haha
<fleeky>
wrong window, doh
tjgillies__ has joined #ipfs
<dawuud>
maybe i've gone too philisophical... it's just not clear which conceptual horse to back
<jbenet>
hey-- maybe i can help. sec let me read up
<lgierth>
maybe even /tcp is superfluous. i.e. /onion/fufu.onion/80 simply gives us a a stream for that "tor host" and "tor port"
<lgierth>
showing up at the right time ;)
* lgierth
is lagging very badly
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
<jbenet>
dawuud: let me ask a few questions as its not completely clear to me
<dawuud>
ok
<jbenet>
so, when using "/onion/fufu.onion", what does that resolve to? that means, use a local tor client, look for hidden service "fufu.onion", open a stream to it?
<jbenet>
on the other side, the hidden service operator, how do they specify the listening? they listen on a local addr?
<dawuud>
the .onion address never resolves to any ip address... and i forgot to mention last week that it's not meaning without a pot number
<jbenet>
i.e. does "/onion/fufu.onion" addess the _ip host_ (all ports) or _specifically the http server_ (just the chosen port the operator chose for the service)
<dawuud>
the hidden service operator specifies an ipv4 interface and TCP port number for their service to listen on
<jbenet>
(right, not "resolve", but proxy through)
<dawuud>
the tor process then forwards connections to that local ip + tcp port
<dawuud>
yeah
<jbenet>
so i configure, locally on the service, "pls expose <ipv4>:<tcpport> at <onion-hash>.onion" ?
<jbenet>
or do i configure, "pls expose <ipv4> at <onion-hash>.onion" ?
<dawuud>
"pls expose <ipv4>:<tcpport> at <onion-hash>.onion:<virtport>"
<jbenet>
(the latter meaning that the end user _could_ specify another port to hit another port.
<dawuud>
virtport is just a port number... but it doesn't have to correspond to the tcp port number of the local service
<jbenet>
right, it's a "port on the onion address" sort of
f[x] has joined #ipfs
<dawuud>
right
<jbenet>
does this apply to udp as well?
<dawuud>
we don't yet have a udp transport
<jbenet>
are there plans for one?
<dawuud>
no
<jbenet>
and, the tcp handshake a client of the service sees-- is that sent by the tor proxy? or by the hidden service's tcp listener?
<dawuud>
the client sees the handshake from their local tor proxy
<dawuud>
the client must speak socks to the tor proc... and so it's basically a stream transport
<jbenet>
(the distinction being: "client[http <-> tcp1 <-> tcp1 <-> tor <-> tcp2 ] <------------> [tcp2 <-> tor <-> tcp3 <-> tcp3 <-> http] hidden service" OR "client[http <-> tcp1 <-> tor <-> tcp2 ] <------------> [tcp2 <-> tor <-> tcp1 <-> http] hidden service"
<jbenet>
ok, so it's the first one here o/
* jbenet
wonders how congestion control happens and so on, but oh well.
f[x] has quit [Ping timeout: 260 seconds]
<jbenet>
dawuud: is there any notion of ip here? like, are clients going over ipv4 or ipv6 ? (i think the local client's kernel may demand it's encapsulated as IP only to de-capsulate it immediately, but there may be shortcuts)
<jbenet>
dawuud: i'm wondering whether if i have an ipv6 only network stack, can i speak to a node with an ipv4 only network stack (it _should not_ be a problem, tor should be able to handle this completely without touching IP, but i wonder if there's some stupid problems interfacing with kernels easiyl
<dawuud>
no... ip isn't involved in the sense that it's just a stream transport
<dawuud>
so... we are talking about /onion/...
<dawuud>
but if we use /tor/... then ip is used on the exit node
<dawuud>
like leif pointed out... eventually we should make a readonly mode for tor users to anonymous look at the ip nodes
<dawuud>
jbenet: an ipv4 tor client should be able to talk to a hidden service app listening on a ipv6 addr
<jbenet>
yep, ok. another random question, suppose my browser did not use TCP, but a unix domain socket, and it happened to talk to my tor proxy that way... everything should still be fine, eh?
<dawuud>
yeah that works too
<jbenet>
ok sweet. so it sounds like that port number is fully a "tor port"
<dawuud>
yeah
<jbenet>
(i wonder why even have port numbers at all and not just do different addresses for everything-- it leaks that two services may be on the same machine)
<jbenet>
(maybe to deal with some software that requires talking to <domain>:<port> for some variable <domain> and constant <port>)
<dawuud>
i think because the socks client side needs a port number
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
<lgierth>
yeah i'd figure the port number is there in order for it to look like tcp
<dawuud>
exactly
<dawuud>
you can't tell a socks proxy to just connect to hostname... it needs a hostname and a port number
<jbenet>
but if i chose to go to H.onion:X and H.onion.Y -- i can hit two different services then?
<jbenet>
dawuud: ah, i see that's dumb. yay breaking the end to end model!
<dawuud>
jbenet: yes... H.onion:X and H.onion.Y could be two different services
<jbenet>
ok. just confirming
<jbenet>
i think it should be /onion/<key>/<port> (i wouldn't put the .onion there unless there would be other .<tld> endings that would not make sense as root protocols.
<dawuud>
ok
<dawuud>
sounds good to me
<dawuud>
what do you think about the /tor/... stuff?
<dawuud>
i guess we can worry about that later
<jbenet>
dawuud mind explaining a bit more? so it's for the exit node case?
amstocker has quit [Ping timeout: 255 seconds]
<dawuud>
yes... if an ipfs user would like to use tor to hide their identity/location they could read things from the ipv4/ipv6 ipfs nodes
<dawuud>
this is a client only mode
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
<jbenet>
and from the client mode, they would pick an exit node from which to send to/recv from the peer?
<dawuud>
yes although most tor users aren't explicit about which exit nodes they use
<dawuud>
they user's ipfs connections would connect locally to the tor socks port... and they'd be proxied from the exit node to the ipfs peer