@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+StormyCloud
+dr|z3d
+hagen
+hk
+lbt
+not_bob_afk
+postman
+radakayot
+weko
+wodencafe
Arch
Danny
DeltaOreo
FreeRider
FreefallHeavens_
Irc2PGuest32178
Irc2PGuest32605
Irc2PGuest38796
Irc2PGuest54664
Irc2PGuest59134
Irc2PGuest63915
Irc2PGuest77229
Irc2PGuest90091
Leopold
Nausicaa
Onn4l7h
Onn4|7h
Sleepy
Soni
Teeed
acetone_
aeiou
aisle
ardu
b3t4f4c3___
bak83
dickless
dr4wd3_
eyedeekay_bnc
foobar
mareki2p
orignal
poriori
profetikla
qend-irc2p
rapidash
shiver_
solidx66
thetia
u5657
uop23ip
w8rabbit
x74a6
orignal
I tested with this test vectors github.com/openssl/openssl/blob/master/test/ml_dsa.inc#L1830
eyedeekay
Sorry got distracted for a moment but yes zzz I do have a deduplication plan, so right now we've got goSam which is very convenient but lacks features and sam3 which is very feature-rich but suffers from code quality issues, go-sam-go is a refactor of sam3 to improve it and fix the code quality issues, at which point goSam and sam3 become consumers of go-sam-go
eyedeekay
that way I deal with my code quality issues, unify on a single go SAMv3 library, and goSam and sam3 can present the same APIs that people are already used to
eyedeekay
then the hierarchy of go sam libraries becomes(from low level to high level) go-sam-go->goSam/sam3->onramp->go-i2p-bt/go-i2ptunnel/go-i2p-smtp
eyedeekay
ofc the way to remove the redundant mini SAM library from i2pkeys is to migrate it to go-i2p, which will be possible soon