&zzz
+FreefallHeavens
+R4SAS
+RN
+ReturningNovice
+StormyCloud
+T3s|4
+acetone
+cims
+eche|off
+fa
+mareki2p
+nilbog
+orignal
+postman
+psychopuck
+qend-irc2p
+rednode
+snex
+wodencafe
Arch
Danny
Irc2PGuest28384
Irc2PGuest66257
Irc2PGuest75631
Irc2PGuest81267
Onn4l7h
Onn4|7h
Over
Sisyphus_
Sleepy
T3s|4_
U1F642
Watson
Zapek
aargh4
ahiru
ananas
anontor
calamares
dr4wd3
duanin2
i2potus
ice_juice
justaperson
luvme
mahlay
makoto
marek22k
n2_
not_bob_afk
onon_
pinotto
poriori
profetikla
r00tobo
rapidash
test7363673
uop23ip
w8rabbit
x74a6
zelgomer
zzz
eyedeekay, I'm working on another fallout from subdbs. All SAM naming lookups are out-of-session
zzz
so b32 lookup side effect is the LS goes in the main netdb
eyedeekay
The lookup doesn't have a client session in that case, so the out-of-session nature is expected right?
eyedeekay
I guess if somebody knows you looked for the LS and then asks for it back from your router Db that could be a leak, and not too hard a scenario to contrive
zzz
no, because even if there is a session, SAM doesn't use it, it looks up on a separate socket
zzz
aka Simple Session
zzz
so the router can only put the LS in the main db because theres no binding to an I2CP session
zzz
well, not a socket, it's in-JVM so it goes straight to the naming service
zzz
but the naming service doesn't know about sessions
eyedeekay
Hm. Yeah so if there is a session then we should find a way put the LS in the client DB associated with the session - otherwise when the application goes to interact with the destination on-session it has to look it up again. Also it's just wrong to put a session lookup into a main DB
eyedeekay
but I forsee a few problems
zzz
it dates back to the original implementation of NAMING LOOKUP which was pretty simple
zzz
it won't be that bad a fix, I'm just figuring out the best way
eyedeekay
I didn't consider the naming-lookup-out-of-session thing to be a problem when I did it because I was only thinking about the API and not about where the LS would end up, major oversight on my part
zzz
ofc this only affects .b32.i2p lookups. Addressbook lookups are fine
zzz
so it's the p2p SAM apps. bittorrent and bitcoin
zzz
so you're talking about oversights in your client side lib?
nyaa2pguy
guessing bittorrent should be mostly fine if trackers track b64 destinations?
zzz
no bc compact responses
nyaa2pguy
ah
eyedeekay
No I thought about the way subDbs would interact with SAMv3 and made the mistake of thinking that out-of-session naming would be fine because people use the NAMING commands to look up hostnames and get back full destinations, I did not consider that it would be valuable to have the lookup associated with a session so the LS ends up in the client netDb at lookup time
zzz
yeah it's not just where the LS ends up but what tunnels are used
zzz
with sam always using simple session the router side loses the association to the client
zzz
since the sam server is inside router context I took some shortcuts which didnt matter at the time
zzz
bumped into this while working on i2cp service record support prop. 167
nyaa2pguy
is it an issue for non floodfill routers? or can netdb queries still happen against those
eyedeekay
floodfill should be unaffected, this is a fairly specific, internal phenomenon related to isolating info clients need from info routers need
eyedeekay
SAMv3 naming lookups are sort of neither because they're out-of-session which is what's not right
nyaa2pguy
ahh okay
zzz
testing sam fix now, looks good so far