@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+dr|z3d
+hk
+not_bob
+orignal
+postman
+wodencafe
Arch
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest15271
Irc2PGuest28511
Irc2PGuest64530
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over
Sisyphus
Sleepy
Soni
T3s|4_
Teeed
aargh3
acetone_
anon4
b3t4f4c3
bak83
boonst
cancername
cumlord
dr4wd3
eyedeekay_bnc
hagen_
khb_
plap
poriori
profetikla
r3med1tz-
rapidash
shiver_1
solidx66
u5657
uop23ip
w8rabbit
weko_
x74a6
dr|z3d
yeah, true, there's no one size fits all solution
eyedeekay
anonymousmaybe I was confusing eeproxy and httptunnel, httptunnel is the one that works best/is simple
eyedeekay
httptunnel is the one that contains multiproxy
anonymousmaybe
yeah was working with SAM as well right?
eyedeekay
Yes it uses SAM for all of it's tunnel-building needs
anonymousmaybe
yeah but was solving different stuff
eyedeekay
No that's the one that does per-site or per-pseudonym tunnels
anonymousmaybe
anyway i think you need a network complex designer which is hard to find tbh
anonymousmaybe
maybe we need some communications with some anon-devs projects or similar like gnunet,tpo,namecoin..etc they might have good ideas on how to solve this
eyedeekay
Well it's just a smarter proxy, though. Tor has 5 little torrc options that ultimately control this behavior on their end, the one most relevant to us is probably `IsolateSOCKSAuth`
eyedeekay
IsolateSOCKSAuth is what httptunnel/multiproxy emulates
anonymousmaybe
can it be implemented directly within the tunnel?
eyedeekay
Not without breaking at least one existing feature
eyedeekay
It can readily be pluginized or packaged as a freestanding app
anonymousmaybe
plugins is horrible, HTTP i2p tunnel is sick by itself and need its own design fixation
eyedeekay
Then a freestanding binary is the path of least resistance
eyedeekay
Although the line is thinner than it used to be
anonymousmaybe
break existing feature like what?
eyedeekay
Offhand, encrypted leasesets might break, anything that *requires* a persistent tunnel will break, existing dest timeouts will no longer make sense
eyedeekay
It's really a browser tunnel and very little else
anonymousmaybe
"anything that *requires* a persistent tunnel will break" sound good to me
anonymousmaybe
because it shouldnt at the first place.
eyedeekay
Unless you run a service that authorizes specific users by client destination
eyedeekay
Which is actually useful
eyedeekay
Private nextcloud services might do this, for instance.
anonymousmaybe
isnt the tunnel different for server VS http (surfing the net)?
anonymousmaybe
i mean user can make a static tunnel for that purpose
eyedeekay
Yes, but suppose you have a NextCloud instance you only want to make available to a handful of authorized HTTP clients, you might have your clients persist a destination in order to authenticate so that other observers cannot tell you're hosting a NextCloud instance
eyedeekay
anonymousmaybe: i mean user can make a static tunnel for that purpose
eyedeekay
^ this is why I think it needs to be 2 tunnel types, "HTTP Proxy" and "Browser Proxy" for instance. The needs are actually different
anonymousmaybe
we can call it persistent tunnel and browsing tunnel
anonymousmaybe
persistent for stuff like i want to use as client to client without changing like login to SSH
eyedeekay
Probably more descriptive, persistent might be better
anonymousmaybe
or as you said a nextclould or so
anonymousmaybe
that would be good idea
anonymousmaybe
browser tunnel is persistent as far as the eepsite kept open, once closed the tunnel close
eyedeekay
It's also easier to accomplish, because you can mostly reuse persistent tunnels inside of the browsing tunnel, all it has to do is organize them
anonymousmaybe
ofcourse we are talking about multiple-isolated tunnels each one for each destination/eepsite/website
eyedeekay
Yes
eyedeekay
Or Auth Header or whatever
anonymousmaybe
sound good to me
eyedeekay
Lots of models are easy to build once you're able to multiplex HTTP proxies
anonymousmaybe
actually from the same browsing tunnel we can make a feature built inside it by adding something like:
anonymousmaybe
add your websites/HTTP for persistent tunnel: [empty field]
anonymousmaybe
once user put like xyz.i2p inside it
anonymousmaybe
a persistent static tunnel will be created for it
anonymousmaybe
so all other browsing will be non-persistent dying tunnel except those in the filled in the empty field
eyedeekay
IIRC I planned to do that in multiproxy for anything that used an encrypted leaseset
eyedeekay
But regardless it requires the tunnel multiplexing ability
anonymousmaybe
yeah sure require that
anonymousmaybe
i hope this to be one of the top priorities
anonymousmaybe
DHT kadmelia vs R5N/Freenet style thats another major enhancement but lets leave it for its time
eyedeekay
UDP tunnels are on top of my list right now but I can make this after that
anonymousmaybe
what is this UDP tunnels?
anonymousmaybe
you mean some issues discovered in UDP connections need to be fixed?
eyedeekay
We're going to make it possible to build UDP tunnels across I2P for some cases using the Hidden Services Manager/I2PTunel in Java I2P
eyedeekay
Feature add not bug fix
eyedeekay
i2pd has had them for a while but not I2P
anonymousmaybe
ah thought it support that
anonymousmaybe
have you looked at QUIC and is it beneficial in/for I2P?
anonymousmaybe
since we are talking about UDP stuff
eyedeekay
QUIC is informing the design of SSU connection migration at least
anonymousmaybe
i have stupid question but i hope to get an answer for it lol
anonymousmaybe
in the tunnel there is an option called "Enable Direct Client-to-Client protocol. Note that this will compromise your anonymity and is not recommended."
anonymousmaybe
if assuming my client will be directly connecting to the other X client and im willing to expose myself but what about the other client?
anonymousmaybe
am i going to expose his IP and connect to him directly?
eyedeekay
It will only work if both ends enable it IIUC
eyedeekay
BRB can do DCC over SAM
eyedeekay
But it won't work with the IRC tunnel version
eyedeekay
So can Dispatch for that matter
anonymousmaybe
ah so if the server allow DCC option then his server IP can be exposed but ofcourse by his will because he choose that
anonymousmaybe
am i thinking correctly?
anonymousmaybe
if yes, then thats is dangerous to be abused by an attacker
anonymousmaybe
but yeah Tor has this option called no hop or single hop feature
eyedeekay
No it's that if the DCC option is enabled then the 2 IRC clients will be able to establish a direct connection between eachother, exposing their IP addresses to eachother
anonymousmaybe
ah sorry its only for IRC thing? not general feature?
eyedeekay
Yes IRC only
anonymousmaybe
oh i got it wrong
anonymousmaybe
thanks for the explanation
eyedeekay
no problem
dr|z3d
yeah, except DCC over I2P creates a second dest so no ip is exposted.
dr|z3d
*exposed.
dr|z3d
this is my understanding based on comments by zzz. I'd always thought dcc was a no no, but apparently it's safe using the IRC client tunnel.
dr|z3d
that's it's flagged as unsafe in the tunnel manager is probably why no one uses it.
eyedeekay
Stood up a site mirror, just as a warning this one may slightly differ from the official mirror at times because I'm using it to make potential changes visible before they go on i2p.net/geti2p.net