IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2021/12/17
@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+dr|z3d
+hk
+not_bob
+orignal
+postman
+wodencafe
Arch
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest28511
Irc2PGuest64530
Irc2PGuest75862
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 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
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.
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 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