@eyedeekay
&zzz
+R4SAS
+RN_
+altonen
+hagen
+hk
+mareki2p
+not_bob_afk
+orignal
+postman
+qend-irc2p
+snex
+wodencafe
Arch
Daddy_
Daddy_1
Danny
DeltaOreo
FreefallHeavens
Irc2PGuest58427
Irc2PGuest60590
Irc2PGuest63042
Irc2PGuest92548
Irc2PGuest95056
Onn4l7h
SigSegv
Sisyphus
Sleepy
SlippyJoe
T3s|4_
Teeed
acetone
ardu
b3t4f4c3__
bak83
boonst
defaultnick
dr4wd3
dr|z3d
eyedeekay_bnc
guest7621
not_human
onon_
poriori_
r00tobo
rapidash
shiver_
solidx66
u5657
uop23ip
w8rabbit
weko
x74a6
zzz
got jetty 12 console kinda working, total shitshow
dr|z3d
what's the issue with jetty?
dr|z3d
or is it a ton of issues?
zzz
they changed everything
zzz
except for the parts they only changed a little, but you have to hunt for them
dr|z3d
sounds super tedious.
dr|z3d
probably the wrong question, but have you ever considered switching over to tomcat?
zzz
yeah and this is just for the console. eepsite will require jetty.xml changes and yet another migration tool
zzz
no, we're in way too deep
dr|z3d
ok, I thought you might say something like that.
dr|z3d
haven't messed with tomcat much, but I did like their web ui for configuration when I looked at it.
snex
imo drop it entirely and make people host eepsites elsewhere
dr|z3d
it's not about eepsites.
dr|z3d
the console runs on jetty.
dr|z3d
eepsites are just a bonus.
snex
fuckin java
zzz
the thing is, we start the router programatically but we start the eepsites via xml config, so it's two completely separate porting exercises
dr|z3d
so when you say kinda working for the console, what's looking janky right now?
zzz
auth, logging, i2pcontrol socket, x-i2p-location filter, classpaths, ...
dr|z3d
dang, that's a big old pile of snakes you're wresting with there, then.
zzz
its like baskin robbins, there's a lot of flavors, have to pick the right one
snex
mmm flavored snakes
dr|z3d
haha
zzz
but debian didn't package all the flavors and I already picked wrong
dr|z3d
can we not just decouple jetty from debian and use our own?
zzz
ofc, and we'll have to for most versions except trixie
qend-irc2p
zzz, I wanted to ask about SAM. For application development, the FORWARD mode is really convenient and requires minimal code for integration with I2P. Could you please tell me if there are any plans to add support for creating socks or httpproxy-type tunnels in SAM? That would be very convenient since it wouldn't require restarting the router, and more importantly, it would make it easy to integrate I2P
qend-irc2p
with various frameworks
zzz
no
zzz
if you want socks or http proxy, you do it in i2ptunnel, no router restart required
qend-irc2p
zzz: but in i2pd we should restart router. For example, I would like to use a server tunnel in FORWARD mode within my application to receive incoming requests. At the same time, I also need inter-server communication using the same b32 address. If such functionality were supported, I could establish a client tunnel of type SOCKS or HTTP proxy and then use curl or any other library to handle the requests
zzz
then take your complaint to i2pd. no restart required for java
zzz
SOCKS and SAM are apples and oranges. Makes no sense to use one to create the other.
dr|z3d
you don't need to restart the i2pd router.
dr|z3d
just service force-reload
qend-irc2p
While it's true that SOCKS and SAM serve different purposes, the idea behind requesting SOCKS or HTTP proxy support via SAM isn't about mixing protocols, but rather about simplifying application development workflows. From a developer's perspective, using SAM in FORWARD mode is already a great low-code solution for handling inbound traffic. If we also had the ability to spin up a client tunnel (like
qend-irc2p
SOCKS or HTTP proxy) through SAM using the same destination (b32 address), it would eliminate the need to manually handle streaming connections, packet parsing, or low-level socket logic. Instead of writing custom code to manage outbound I2P connections via SAM STREAM sessions, developers could simply direct traffic through standard tools or libraries without writing any extra networking code — just by
qend-irc2p
pointing them to a local SOCKS or HTTP proxy bound to the same SAM destination.
qend-irc2p
dr|z3d: Ideally, tunnels should be managed programmatically — via an API or an interface like SAM — without the need to interfere with the operation of the entire router
dr|z3d
sure, well, that's something to put to orignal, but service i2p force-reload won't interfere with operation, it'll just load up the new configs, so you should be able to script that.