dr|z3d
zzz: the easiest way to push http traffic to Tor over i2p is with an intermediate http proxy that can forward to socks. In that case, either an http or standard server tunnel is fine. If the Tor exit guy's proposing to offer a socks proxy instead, that's a different issue.
dr|z3d
if otoh, the guy is planning on running a multi-homed outproxy without forwarding to Tor, then http/standard tunnel should be fine, assuming he's only planning on providing an http proxy. but from your comments yesterday, it's not entirely clear what the proposal is.
dr|z3d
I can provide some details on configuring an http service via pm if required.
zzz
yeah I just wish we had a recommendation, not 'either will work'. This 2019 thread comes the closest to the issues: zzz.i2p/topics/2706
zzz
or, as a thought experiment, if we were to create the perfect 'i2ptunnel outproxy server' tunnel type, what would be the requirements? I have no idea
zzz
the 2019 thread talks about stripping i2p-specific headers, for example
eche|on
reaching eepsites got really worse... takes up to 10 min and x retries to load discuss.i2p, zzz.i2p or even the tracker
zzz
hmm
zzz
looking at your deadlock now
eche|on
ok
eche|on
(the reachability is since 1.6 worse than before IMHO)
eche|on
not looked into it, guess the leaseset, but...
zzz
the deadlock matches what dr|z3d reported in october
zzz
it's right at startup, it's not a stray bullet that hits later
zzz
eche|on, I think I fixed it, pushed to idk git, please test -8
zzz
eche|on, what were the symptoms? was it stuck right at startup or did it crap out later?
eche|on
ok, will do later on
dr|z3d
zzz: tunnel type comes down to 2 things: server headers (type) leaking, and http queries potentially being logged. http server tunnel removes the server id but keeps http queries in the logs. standard tunnel type does the opposite.
dr|z3d
performance-wise, there's no noticeable difference.
dr|z3d
as for a custom outproxy tunnel, some basic requirements would be suppressing server headers from being sent to the client, minimal http logging
dr|z3d
support for hostname blacklists either via textarea or external lists would be handy, but can be handled elsewhere.
dr|z3d
tunnel filtering could be extended to support hostnames, for example.
dr|z3d
if there's some custom configs that can be applied for zero-hop outproxies, that wouldn't hurt either.
dr|z3d
as an alternative to a custom outproxy tunnel, the standard tunnel could come with a couple of checkbox options which would make it more suitable for outproxy duties:
dr|z3d
[ ] Never log protocol requests .. [ ] Do not send server id headers to client or somesuch.
dr|z3d
Or rather, http tunnel has the option to suppress protocol logging, and the standard tunnel has the option to suppress headers.
zzz
std tunnel doesn't know about headers
dr|z3d
yeah, exactly, so if you're using a standard tunnel, the outproxy server's headers will be passed along, which isn't great if you want to hide the outproxy stack/server from clients.
zzz
what I'm getting at is, independent of implementation, we need a list of outproxy requirements w.r.t. headers, error responses, etc.
zzz
the 2019 thread dances around it but without conclusions
zzz
and also mixes together both tech reqmts and policy reqmts for a project recommendation/default
dr|z3d
you mean zab's post?
dr|z3d
that wasn't helpful then, and it's not really helpful now. it was mostly a reaction to arctic running his outproxy using i2p+.
zzz
agreed, it raises several issues but there's not many answers in there
dr|z3d
you need a light flailing, zzz, for this: _log.warn("PLRIJ before comm system started");
zzz
:)
zzz
be nice, I'm wearing the socks you gave me for christmas, will let you see them soon
dr|z3d
*** chuckles ***
dr|z3d
in other news, I looked at both eclipse and netbeans with a view to being able to edit the itoopie gui visually. unfortunately, both apps appear to require that the panels/forms are originated in the app.
dr|z3d
FlatLaf seems to be the goto skin for Swing apps these days, netbeans has it an option.
dr|z3d
skank.i2p/flatlaf.png (all times in UTC, obviously)
