~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%ardu
%cumlord
+FreefallHeavens
+HowardPlayzOfAdmin
+Onn4l7h
+Onn4|7h
+Over
+Rogueone
+Sh0ck
+Xeha
+hk
+onon_
+poriori
+profetikla
+qend-irc2p
+r00tobo
+romer
+uop23ip
+waffles
+xHarr
Arch
BravoOreo
BubbRubb
C342
Danny
FreeB
GucciferZ
Irc2PGuest38151
Irc2PGuest52770
Irc2PGuest77400
Irc2PGuest82806
Liorar_
Meow
acetone_
aisle
anontor
halloy13412
mareki2p_
maylay
moe
nilbog-
nnm--
not_bob_afk
pisslord
pory
r00tobo[2]
shiver_
sidereal
simprelay
solidx66
thetia
u5657
weko_
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.
wew
about gost crypto i meant that. look github.com/PurpleI2P/i2pd/blob/openssl/libi2pd/Gost.cpp
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