dr|z3d
zzz: re joining [], that's a separate logging instance than the matches for tunnels where other router hashes are returned, so it can be tweaked accordingly, no?
dr|z3d
line 1354 vs line 1421 in ProfileOrganizer.
dr|z3d
as a side effect of setting to /8, I'm hard pressed to identify any local tunnels that use 2 peers from the same country now.
dr|z3d
they do occur, but much less frequently.
zzz
dr|z3d, [] is for fast tier slices (client tunnels), if there are peers listed its probably expl. tunnels
dr|z3d
zzz: ok, thanks.
dr|z3d
logging aside, all looks fine here. no harm in limiting by /8, either. maybe overbroad, but doesn't appear to be any downside.
zzz
ok, thx for testing, awaiting a final ack from idk
dr|z3d
what's your thinking on /8 vs /16?
dr|z3d
and as a followup question, any thoughts on a custom list that defines ranges by org?
dr|z3d
with a custom list, it might be possible to feed the results of restrictions into sybil detection to get some insight on possible attacks that may currently be going under the radar.
dr|z3d
probably huge scope for false positives, but maybe the data could be of some use.
zzz
/8 seems way excessive
dr|z3d
yeah, in theory, sure, but it's not turfing up too many matches.
zzz
that doesnt mean it's useful
zzz
by org? huh?
dr|z3d
by org.. custom list that defines subnets owned by organisations.. think VPS provides, .gov, companies etc.
zzz
sounds hard to both implement and maintain a list
dr|z3d
implementation is just a question of doing a lookup of possible peers via the list ("oh, two peers from linode, no can do!") and a list, yeah, that's work, but no more so than a manual blocklist.
zzz
so the use case is you trust a particular org enough to use one of its peers in a tunnel but not two?
dr|z3d
yes, that's about the size of it.
dr|z3d
if we don't trust the org per se, then it goes in the blocklist.
dr|z3d
parabo claimed a while back he was running 500 vps's from a single provider to perform sybil attacks.. restricting by org would mitigate that attack path.
dr|z3d
as a side benefit, if a tagged org is used to bring a huge number of routers online at the same time, then that can get flagged.
zzz
dunno why you'd want to sortof-trust something like that
dr|z3d
you're mitigating possible sybil attcks, not casting doubt on the entire org.
dr|z3d
if you distrust the entire org, too much collateral damage. that's the other thing.
dr|z3d
otoh, router sees 200+ routers appear online in a short timeframe from a single org, that gets fed into sybil analysis, short term block is applied.
dr|z3d
re your socks5 plugin, zzz, is that a prelude to incorporating into a default tunnel type in the tunnel manager, with the potential to reference it from an http proxy client tunnel? :)
zzz
already supported for orchid
dr|z3d
so I'm suggesting a new tunnel type, socks4a/5 client, and then, if configured, it can be referenced from an http client proxy tunnel.
dr|z3d
we're working on the assumption that orchid's dead, no?
dr|z3d
it's not dead per se, it just doesn't support v3 .onion addresses, the clearnet proxying is still good to go, but in any event, it's unmaintained, crufty code that should probably die.
dr|z3d
I'm also suggesting that a native socks4/4a/5 tunnel is the way to go, not a plugin.
dr|z3d
and obviously a socks 4/4a/5 server tunnel to compliment the client tunnel would be nice :)
dr|z3d
presumably that would supplant the existing streamr tunnel type that nobody uses.
zzz
we already have a socks client tunne
zzz
l
dr|z3d
yeah, we discussed that before. you said it was untested, possibly broken, and c 2011, no?
zzz
its old but probably works
dr|z3d
if it already works, then great, it just needs the option in the http client proxy tunnel to reference it as an outproxy option.
zzz
if anybody was crazy enough to run a public socks server, maybe
dr|z3d
specify socks tunnel as outproxy or nominate a host:port.
dr|z3d
running a public socks server is a recipe for DMCAs. madness!
dr|z3d
that is, unless you want to run a socks server that routes everything over Tor or some other service. then it's feasible.
zzz
noooooo. the socks client tunnel is for a remote socks server via tunnels
zzz
unless an outproxy is registered, so it already does what you want
dr|z3d
ok, so tunnels for the client. then we need a socks server tunnel that can be nominated as the outproxy, no?
zzz
no, just use std. server tunnel and external proxy
dr|z3d
so how does that replace the current "use plugin as outproxy" functionality?
zzz
we'd have to add code for the socks client tunnel to register as an outproxy so the http client tunnel would send the request to socks
dr|z3d
I think the simplest solution is just to be able to specify an address:port as the outproxy and designate it http/socks4/4a/5.
dr|z3d
I'm confused. you've just said a socks client tunnel is for a remote socks server via tunnels, so not for localhost:9050 for example. so how does registering that with the http proxy client help?
zzz
if the http got a clearnet request, it would send it to the socks tunnel who would send it over i2p to the remote socks server
dr|z3d
http client proxy -> outproxy / ssl outproxy -> either i2p addresses or protocol/host:port (maybe multiple supported?) seems like the path of least resistance.
dr|z3d
what you're suggesting seems like more work if you want to use a native tor instance as the outproxy. you'd then need to configure a socks server for the socks client to talk to, no?
dr|z3d
*native _local_
zzz
I'm explaining how the socks client works. Not promoting it as the best solution
dr|z3d
oh, sure, I get how it currently works. maybe we're slightly at cross purposes.
dr|z3d
the tldr: is basically protocol/host:port support for the outproxy, as an alternative to an i2p address. better than a plugin imo.
zzz
plugins are for experiments. our outproxy support is currently designed around plugins. you're proposing to bypass the experiment and redesign the outproxy support.
dr|z3d
yup. it was a nice experiment (orchid). it worked! and now orchid's on death row, time to up the game and native provide support for proxy hosts :)
zzz
thats not the lesson I took from it but ok
dr|z3d
the main problem with orchid, aside from the fact the code was outdated, was that it wasn't native tor and couldn't be addressed outside of i2p. support for outproxies by host is the next logical step.
dr|z3d
the huge memory footprint wasn't great, either, or the memory leaks.
zzz
disagree. there was nothing wrong with the plugin architecturally. The sole issue that all your complains stem from is that the code base it depended on quickly became abandonware
dr|z3d
not the sole issue. it wasn't addressable outside of i2p, so couldn't replace native tor, and replacing native tor with an inferior implementation was good for an experiment, but limited outside of that scope.
dr|z3d
if you accept the basic assumption that most people who run i2p also run tor, why reinvent the wheel? just use native tor.
zzz
wasn't designed for that
dr|z3d
where it gets interesting is where you replace the native java tor implementation with a tor controller that automatically detects a running tor instance via its control port (tor or torbrowser). that, to my mind, makes for a much more useful plugin.
dr|z3d
github.com/guardianproject/jtorctl or github.com/thaliproject/Tor_Onion_Proxy_Library for example might provide some pointers.
zzz
all written in 15 minutes. I'll polish/test/release if people want it
dr|z3d
sure, give it a polish and put it on stats.i2p, I'll take it for a spin.
dr|z3d
github.com/resolvingarchitecture/tor-client-java also looks fairly minimal.
dr|z3d
if you want a plugin icon, try this one, tweaked from the original tor icon, license is cc (https://commons.wikimedia.org/wiki/File:Tor-logo-2011-flat.svg) -> skank.i2p/tor.png
