mesh
ls -l
mesh
whups
RN
ls -AFGhlp
RN
alias="ls -pG"
RN
oh, wrong window
zzz
yes, somewhere in client manager code is where you want to create/destroy subdbs
zzz
look for where the per-client SKMs are created/killed
zzz
but before we all dive deep into it I think you guys should do some high level planning and push out the current schedule significantly, to vastly increase testing and mitigate risk
eyedeekay
Updated the forum announcement with new dates
zzz
ok. I'm adding a big comment to #406 now
zzz
what version is git.idk.i2p running because I'm still getting 100% POST failure rate
eyedeekay
2.3.0 from the deb repo
zzz
thanks, on my list to chase down
eyedeekay
Let me look at the limiters too
zzz
hi obscuratus
zzz
updated #406 with a big comment for you
zzz
just entered #410 with more headscratchers, but still just throwing darts, don't fully have the big picture yet
eyedeekay
I'll follow up on those issues with you with my reasoning and some commit hashes/merge references if it helps
zzz
ok, but I think javadocs would best help clarify intent and make me smarter
zzz
smart move to push out the release, good job, I think you'll need that time
eyedeekay
Ack, I'll fix up the javadocs then
obscuratus
zzz: I'm the one that added the methods to lookup by Hash. I was under the impression that, while we had a consistent dbid naming convention, it was best to assume the dbid could be any string. But we seem to have pivoted to a strict dbid naming convention.
orignal
zzz, when are you ready to talk about SSU2?
obscuratus
eyedeekay: Added another MR with two fixes I ran across. Let me know if you want the MR to go against another branch or repo.
eyedeekay
For now just file them against master
obscuratus
OK,I filed it against master in i2p-hackers/i2p.i2p. Let me know if it's better somewhere else.
zzz
well, you need to have a strict naming convention for it all to work.
zzz
if the dbid is just the b32 then why not pass in the hash to begin with and skip the hash-to-string conversion
zzz
but that's just a detail.
zzz
subsessions another wrinkle
zzz
also, client-side lookups can be "out of session"
zzz
orignal, can you give me a hint, what about SSU2 is the topic?
orignal
zzz, there is a weakness in sesssion handshake
orignal
that Bob's hash is never verified by Alice
orignal
it means that Alice thing that she is connected to one Bob but avtually connected to another on the same endpoint
orignal
and that what the last attack was about
orignal
an advesary started producing fake floodfill with IPs of real floodfills
orignal
simply speaking we need to pass additinal block with Bob's ident during handshake
zzz
sounds familiar, didn't we talk about it back in Feb. or March?
zzz
I also think I have some emails with idk about it
zzz
have you written up a proposal?
orignal
no, it was completely new
orignal
from start of May
orignal
I don't have a proposal because I want to discuss with you first
orignal
not even sure if my idea is good
orignal
that's why I need your opinion
zzz
ok. give me a couple days to look, I know I talked about it with idk
zzz
speaking of, did you two ever update the streaming proposal and streaming specs? or is that still on my ToDO list? ((
zzz
I don't see any changes but perhaps one of you is working on it?
eyedeekay
I've got a branch for it that I'll pick back up
eyedeekay
Got distracted from it for a little while but I'm already started
zzz
ok, it's kinda grunt work, so if you want to give it to me to finish I can, up to you
zzz
would be good to get it done before we start talking about new flavors for ssu2 or datagrams
orignal
couple day is fine. let me know
obscuratus
eyedeekay: Let me know if you want me to take a swing at going over the places in FNDS where we iterate of all the netdbs.
obscuratus
With the one I addressed in my last MR, I don't see the others popping up in my logs. They're not called regularly.
eyedeekay
Yeah ideally we want to use them as little as possible or not have them at all, it's better to know what db we want to put any given ID in instead of trying to make the segmentor figure it out
obscuratus
For most of those, it makes sense to constrain them to main. We already have companion calls that allow explicit identification of the client DBID for those places where it was needed.
eyedeekay
Sometimes we can get the DBID out of the DatabaseEntry in the form of a hash, though, should we (ever)guess based on that? I think probably
obscuratus
I've sort-of conceptualized the client netdb as being bundled with a client facade. Is there ever a case where there's not a one-to-one pairing?
zzz
obscuratus, you can have a client before you have a "session", and you can have a client with multiple "subsessions" (hashes)
anonymousmaybe
oh wow zzz alive, yo good to see you back
zzz
thanks
zzz
obscuratus, so those are some decisions to make
zzz
note that all those FNDS loop-de-loops may be masking other bugs so I suggest you test the heck out of any changes you make there
anonymousmaybe
btw your website still down
eyedeekay
There's an argument to be made that isolating them above a certain level has diminishing returns, we briefly considered a global "clients" DBID because of how difficult it is to hide that clients share a host, but it was basically the same to isolate by key as it was to isolate by client
orignal
both eepsites
zzz
eyedeekay, yeah, just pointing out you should make an affirmative decision on what to do with subsessions and out-of-session lookups and document it,
zzz
which is just another way of saying 'what is a dbid'
obscuratus
What's an example of a client/service that employees subsessions? Maybe I can get it going on my testing network.
eyedeekay
IIRC BiglyBT
zzz
dont think so
zzz
create a DSA-SHA1 server tunnel, and add an alternate Ed25519 private key file path
obscuratus
Hhhmmm, my ZZZOT still has a DSA-SHA1 key. It might be easy. :)
eyedeekay
zzz re: what is a dbid, it is a key used to define the subDb that is to be used, either "main" which is defined as the one which we use when we are a floodfill, or one created for a specific use, i.e. a destination. I used the string representation of the destination because I knew that even though 99% of the time I would need to create a dbid which corresponded to a destination, I would also need at
eyedeekay
least one for the floodfill, I wasn't at the time sure if I would need one specifically for exploratory stuff, and because I had already had reproduced the issue I described to you in my last long email and why I didn't like the solution I slapped on(neither did you)
eyedeekay
Not attempting to emulate the netDb's behavior and instead just maintaining a separate netDb just for them seemed like a better way
eyedeekay
I'll explain on the issue what I mean, working on the javadoc now
zzz
yeah ok, confession, the long email from a week ago was tldr, I could try again, more brainpower now
zzz
obscuratus, you'd want to set it up in i2ptunnel gui, I doubt you want to research the config settings manually
zzz
obscuratus, with subsessions, all dests share tunnels and a SKM, so my first guess is that they should also share a subnetdb, you just need to make a decision and then validate it does what you want
zzz
eyedeekay, yeah, some alternatives to a dbid string you may or may not have considered: null dbid = main, or FAKE_HASH (AAAA...) = main, or "" = main, or separate methods (no dbid arg) for main
zzz
I think the 'what is a dbid' isn't the biggest issue, it's more of a sign (together with the hash lookup methods) of things not quite being tight
zzz
so I am a little poking at it with a stick, to be honest
zzz
obscuratus hit it on the head. a subnetdb (== dbid) maps 1:1 to... what?