IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2025/07/12
~dr|z3d
@RN
@RN_
@Stormycloud
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%Liorar
%ardu
%cumlord
%mareki2p
%snex
+FreefallHeavens
+HowardPlayzOfAdmin
+Onn4l7h
+Onn4|7h
+Xeha
+f00b4r
+hk
+profetikla
+qend-irc2p
+r00tobo_BNC
+uop23ip
+weko
+wew
Arch
BubbRubb
Danny
DeltaOreo
FreeB
Irc2PGuest49541
Irc2PGuest51349
Irc2PGuest59500
Irc2PGuest85022
acetone_
anontor
halloy13412
idontpee
maylay
not_bob_afk
onon_
poriori_
r00tobo[2]
rascal
shaye
shiver_
simprelay
solidx66
thetia
u5657
woodwose
xHarr
zer0bitz
wew dr|z3d, conclusion: doesnt work with ECIES-X25519, doesnt work with ElGamal-2048(not surprising). and finally - works with enabled both
onon_ As far as I remember, the order is important. 6,4 or 4,6
cumlord lol wut 🤣
wew gonna reproduce again to see if it actually like that
wew yep, it works perfectly with both enabled
wew cumlord, it works without specifying the port, confirmed
dr|z3d wew: thanks for testing.
dr|z3d hopefully the issue will disappear when I merged the pq code.
wew dr|z3d, no problem. i would like to test that too. just ping me whenever its ready
dr|z3d if I remember, sure, otherwise just watch for a minor version bump in the channel topic, that will likely indicate we're pq capable.
mareki2p zzz you said you have some i2cp news for me?
zzz yeah
zzz you reported that we don't respond with a session status when you send a destroy session on a subsession
zzz I said I'd research
zzz it's a minor mess
zzz we don't send a session status for a primary session either
zzz in fact we never send session status (destroyed)
zzz if there's any sessions left we don't respond at all
zzz if it was the only session we send a disconnect message
zzz and on the client side we don't handle session status (destroyed) right either
zzz I've added all this info to the spec in a note
zzz haven't quite decided what to do about it
zzz ^^ mareki2p
mareki2p Thank you.
mareki2p Probably should be improved. At least in case of multiple sessions. If client says session disconnect - server should respond "yeah from now on it is really disconnected". And on client side there should be no crashes or exceptions when receieving message with session id that client no longer cares about or has no idea about.
zzz on the client side we disconnect everything and then reconnect. so I can't really send it until thats fixed
zzz and don't know what other impls do
zzz still need to research the history of how we got here
zzz router will also let you destroy primary session and keep subsession open which it probably shouldn't
mareki2p Yes, I was under the impression after reading the docs that this should not be possible.
mareki2p If somebody out there depends on that behavior ... hyrum's law. Should the I2P project follow the docs and break the clients? Or should the I2P project keep clients working and change the docs? Because this willl happen in the future again.
zzz for now it's just a new note in the doc
T3s|4 uname -a
T3s|4 ^nice :)
wew so, dr|z3d, i wanted to know your opinion on i2pd. i'm concerned about quality of code and possible safety problems(c++ right). what's more interesting is GOST crypto. why would it be needed in the first place? anyway, i think this is great project and purplei2p team doing remarkable job
dr|z3d quality of code is awful, ask orignal. :)
dr|z3d as for gostcoin, that's some pet project of orignal's, not sure it's needed as such.
dr|z3d joking aside, i2pd's great when you are memory or resource constrained, runs in places where java i2p can't, like wifi routers etc.
dr|z3d right, the gost crypto stuff is orignal's pet project wrt i2pd.
wew there also was proposal 134 back from 2017 to implement gost sig type. geti2p.net/spec/proposals/134-gost
dr|z3d who was proposing it? orignal?
wew yep, he is. but why would we need untrusted crypto from russia in the first place
dr|z3d well, we don't, that's why it's not in java i2p.
wew i think that was a bit suspicious from him