IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2025/05/25
@eyedeekay
&zzz
+R4SAS
+RN
+RN_
+StormyCloud
+T3s|4
+acetone
+altonen
+dr|z3d
+hagen
+hk
+postman
+qend-irc2p
+snex
+wodencafe
Arch
BubbRubb
Dann
DeltaOreo
FreefallHeavens
HowardPlayzOfAdmin1
Irc2PGuest23402
Irc2PGuest31296
Irc2PGuest59134
Irc2PGuest85336
Onn4l7h
Onn4|7h
SigSegv
Sisyphus
Sleepy
T3s|4_
T3s|4__
b3t4f4c3___
bak83_
boonst_
cumlord
dr4wd3_
duck
elthommy
eyedeekay_bnc
mareki2p_
not_bob_afk
onon_
orignal
poriori
profetikla
r3med1tz
rapidash
shiver_
solidx66
thetia
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
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 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.