IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2022/05/25
@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+dr|z3d
+hk
+orignal
+postman
+wodencafe
Arch
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest15271
Irc2PGuest28511
Irc2PGuest64530
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over
Sleepy
Soni
T3s|4_
Teeed
aargh3
acetone_
anon4
b3t4f4c3
bak83
boonst
cancername
cumlord
dr4wd3
eyedeekay_bnc
hagen_
khb_
not_bob
plap
poriori
profetikla
r3med1tz-
rapidash
shiver_1
solidx66
u5657
uop23ip
w8rabbit
weko_
x74a6
dr|z3d zzz: another possible usecase for restricted routes, one which I'm contemplating right now on account of a server that's super-locked down.. inbound and outbound ports can only be opened on an individual basis.. so nominating specific servers as the first hop presumably would mitigate that?
dr|z3d not entirely sure that would fix the issue, but not sure what else would.
dr|z3d also, noticed you're handling the i2pd key import now.. throw new InvalidKeySpecException("todo"); <-- maybe something other than todo as the exception error? :) "Unsupported key type" ?
zzz the todo won't be seen by the user, it's caught in the loop now, so it will fall through to the unsupported key type exceptino
dr|z3d ok, no problem then. thanks.
zzz I saw you bypassed merging the translation updates rev, on purpose, or you need a better process to not miss things, or you're not supporting translations any more, or?
dr|z3d mostly because upstream translations are becoming less and less relevant for I2P+
zzz ok, so it's going to gradually become english only
dr|z3d no, the existing translations are good, manually submitted .po updates are accepted, and I'm diving into poedit myself to do some stopgap translations.
dr|z3d there are a lot of new strings appearing in I2P which mostly don't appear in I2P+, so pulling translations every cycle doesn't make much sense.
zzz if you werent doing your own translations, you could just take ours and get as much as you can out of it, but since you are, you'd have to use gettext tools to merge them somehow
dr|z3d yeah, merge hell in essence. translations aren't in a bad shape, in any event, in some cases better than I2P, coverage wise. so it's all good :)
zzz idk put up some machine translation service eepsite, with some scripting you could probably translate the whole corpus for all languages, who knows what the quality would be
dr|z3d the quality would be pretty abysmal. :)
dr|z3d I know, I've used google's translate on website text, and the feedback is always along the lines of "awful" :)
zzz sure for the longer sentences, but you'd get a lot of impact just from restricting to e.g. 1 or 2 words
dr|z3d that said, for the target audience, badly translated text might inspire someone to do the work to make it good.
dr|z3d and sure, true, keyword translation might have a better signal to noise ratio.
zzz that was always my theory, almost any translation is better than nothing
zzz re: server lockdown, are you talking about destination ports for outbound sockets/packets that's part of the equation?
dr|z3d yeah, dest ports, indeed.
dr|z3d server's locked down ridiculously tight. would like to get something working, it's on a 10Gb pipe.
zzz but there's some facility to whitelist?
dr|z3d ports can be whitelisted individually, sure.
zzz so whitelist every destination port 9151-30777
dr|z3d when I say individually.. I mean *individually*
dr|z3d you can't specify a range.
zzz for i in 9151..30777; do; whitelist $i; done
dr|z3d no, it's not a standard linux firewall.
dr|z3d there is no firewall active on the system itself, it's one level above.
dr|z3d and the one-level-above firewall is a GUI app, no option to whitelist more than one port at a time.
zzz then yes, that's a use case for restricted routes
dr|z3d ok, thought it might be, wasn't sure. and we just specify comma separated ips for the nominated routers?
zzz restricted routes is not implemented
dr|z3d Oh, I thought you said you'd tested shouldSelectExplicit() previously. my bad. or maybe that's something slightly different.
zzz slightly different and janky
dr|z3d well, 10Gb/s router would love to have access to restricted routes :)
zzz more of a test mode
zzz well, jrandom said it would happen in 3.0, we're not there yet
dr|z3d 3.0, sometime in the text millenium.
dr|z3d *next
zzz the ancient thread on my forum lists some of the things R.R. _could_ mean, and _might_ require
zzz its really just a handwaving catchall term at this point
dr|z3d yeah, looked at that. well bypassing restrictive outbound firewall policies, definitely top of my list right this moment.
zzz but without full R.R., wtf good is 10Gbps if a) it's all going to a handful of presumably much slower routers, and b) nobody can build a tunnel through you?
dr|z3d well, this is the question I'm asking. if the router could nominate a proxy, as i2pd permits, that's half the issue fixed. sure, the bottleneck then is the upstream proxy, but 10Gb/s is never going to see full usage anyways, same for 1Gb/s, so I dunno. just trying to work out some strategy to get things moving in the right direction.
zzz hidden mode + 1 hop tunnels + explicit peers will get you started
zzz if you want longer tunnels you'll have to change how explicit peers works to put your favorites at the closest hop
zzz and not use them for the farther hops
zzz but >1 hop tunnels is going to be more fragile/janky
zzz because there's a bootstrap problem
dr|z3d hmm, as you say, janktastic. :|
dr|z3d I guess what would be useful is an outbound proxy option, since inbound traffic is fine, or the option to nominate routers to act as proxies for outbound traffic.
zzz a "proxy" network role (IB or OB) would be some brand new network architecture thing and a huge amount of work
dr|z3d yeah, figured as much. :|
zzz to the extent things can be accomplished with existing protocols its a lot easier
dr|z3d well hidden mode doesn't achieve much more than a foot in the door of the network. not really a viable solution.
zzz thats why hidden mode + closest-hop restrictions are more viable
zzz sure but why would anybody want to connect to or route a tunnel thru such a router?
dr|z3d hidden mode, no good, not if you want to share bandwidth. as it is, router is hosting 25 part tunnels and seems to think it's OK, status-wise.
zzz if you're using your friends as closest-hop, then a tunnel thru them and you as colluding routers is undesirable
dr|z3d if I can delegate alice to handle all my outbound traffic, what would that be, reverse hole punching (?), then I can function more or less normally as a router.
dr|z3d well, not "alice", but routers I trust/own.
dr|z3d but, sure, it's problematic on the collusion front I guess.
zzz you're useless as OBEP or IBGW, and as middle hop only with two of your friends on either side?
dr|z3d i2pd allows you to nominate a proxy to route all your traffic through. but you're suggesting that's a huge amount of work. is it useful in this context? dunno..
dr|z3d yeah, router x won't want to route through router y just to talk to me. so hmm.
zzz we don't bother trying to route tunnels through hidden mode routers and usually avoid firewalled routers too. Are they some great untapped resource that would benefit the network?
dr|z3d except via introducers, which is a different proposition.
zzz why bend over backwards trying to use some other type of handicapped router
dr|z3d the answer to that question is "probably not", rhetorical though it may have been :)
dr|z3d otoh, there are probably a not-insignificant amount of routers out there that could be contributing more were it not for restrictive outbound firewall rules.. campus dorm routers etc.
zzz i2pd-type proxying is feasible, yes a lot of work, but for now like with ygg we leave that problem space to i2pd
dr|z3d maybe restricted routes in this context is the wrong focus. a proxy approach is perhaps more useful, yes.
dr|z3d not pushing for a proxy approach, anyways, just raising the issue, hopefully not too forcefully.
zzz the network architecture is that everybody wants to talk to everybody, so as soon as that's not true (your router, ygg-only, ipv6-only, ...) it gets ugly in a hurry
dr|z3d very true.