~dr|z3d
@RN
@RN_
@T3s|4
@eyedeekay
@postman
@zzz
%Liorar
%acetone
%ardu
%cumlord
%snex
+FreefallHeavens
+Xeha
+bak83_
+hk
+mareki2p
+profetikla
+qend-irc2p
+r00tobo
+uop23ip
+weko
+wew
AHON1
Arch
BubbRubb
Danny
DeltaOreo
FreeB
HowardPlayzOfAdmin
Irc2PGuest248832
Irc2PGuest47444
Irc2PGuest54105
Meow
Onn4l7h
Onn4|7h
anontor
halloy1341
maylay
not_bob_afk
onon_1
orignal_
pisslord
poriori_
r00tobo[2]
shiver_
simprelay
solidx66
thetia
u5657
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 :)