#i2p-dev (irc2p) | 2.7.0-1 | 2.8.0 Release Discussion: http://i2pforum.i2p/viewtopic.php?t=1301

eyedeekay Which is why idk.i2p is more or less an exact copy of eyedeekay.github.io

eyedeekay I can be

eyedeekay I am sort of building a house

dr|z3d hmm, obscuratus isn't about, ok.

dr|z3d just wanted to talk about the user-facing stuff with the new segmented db.

dr|z3d the UI is appalling, but that's secondary. the first issue is the actual naming.

dr|z3d we've got per-client dbs, and a floodfill db, both for routers and destination leasesets it appears. The naming sheds no light on how they're meant to function.

eyedeekay Feel free, I have the one issue with the client subdb displays showing everybody's leaseSets identified with a fix ready

dr|z3d I think we should move away from the floodfill db name as soon as possible. If it's confusing to me, it'll be confusing for most users.

dr|z3d I'm assuming that what we're currently calling the floodfill db is technically a "public" db where we're happy to serve lookup requests?

dr|z3d It's also not clear to me why we have a separate netdbs for routers.

dr|z3d The UI can be simplified by tagging public and per-client (private?) routers and leasesets visually, with a summary page for all routers and all leasets that breaks them down by type, using "LeaseSets" and "Routers" navigation. When on the summary page, the user can then be offered the option to view all routers/leasesets, or routers/leasesets by type (public/private). That would restore the relative sanity of

dr|z3d the previous navigation menu.

dr|z3d And if the user is in advanced mode and debugging options are available, they can also be displayed on the respective summary pages. No need to put those on the navigation, either.

eyedeekay I see how that could work

eyedeekay Any interest in throwing a patch our way?

dr|z3d A patch might be somewhat difficult, given the extensive pre-segmented db work I've already done, unless you want to pull all of that first.

dr|z3d I'm still not clear what the All Routers for Client NetDbs is meant to offer. Why would we have separate NetDbs for routers?

dr|z3d And can you clarify that you're in agreement in principle with the proposal to change the naming from client/floodfill to private/public, and if that actually makes sense?

eyedeekay We shouldn't need to and tbh it probably needs to be hidden behind debug because that's what it is for

eyedeekay I would be more open to router/client on a descriptive basis

eyedeekay With floodfill being changed to router

eyedeekay client subdb's are for clients though and I don't see why that should need changed

dr|z3d ok, that's moving in the right direction. I just don't think floodfill is helpful, because it confuses our role as a floodfill or not with the storage of leasesets which is independent of that.

eyedeekay Ack, probably a good change

dr|z3d ok, great. and we can remove the client router netdb page entirely you're suggesting?

eyedeekay For now I am going to hide it behind debug

dr|z3d is there a context where it actually displays anything?

eyedeekay Not that I know of yet, I want a cycle to satisfy my curiosity

dr|z3d Regarding stats for routers, I already display that as an option on the routers page, not on the nav bar. If we're in adv. mode, then the routers page opens with stats enabled, with an option to switch to compact mode at the top of that page.

dr|z3d OK, so it's a theoretical thing, the possibility that routerinfos arrive outside of the router netdb. I'd suggest you do a count in that case and only display a link/nav button if count > 0. But that's your call.

eyedeekay Good idea, maybe I'll do that instead of debug

eyedeekay Yeah basically the whole idea of this class of attack is to confuse the router about where something came from to affect where it will go

eyedeekay So if we see somebody sending RI's where they don't belong, that means something

eyedeekay It shouldn't matter anymore, it gains them nothing with subdbs, but it would be interesting to see them try

dr|z3d ok

dr|z3d I'm tending towards local / public for leasesets in lieu of client / floodfill.

dr|z3d or local / remote

eyedeekay local/shared?

dr|z3d not a fan of shared, not obvious where the sharing's occurring.

dr|z3d remote seems to make sense, since those leasesets are for non-local services.

dr|z3d and local / remote sets up a clear distinction/delineation.

dr|z3d local / remote, or private / public .. you've got a ying/yang thing going on there which is easy enough to grasp, that's the general idea.

dr|z3d if we're a ff, presumably any requests for ls for our own services get served from the public / remote db, and if we're not a ff, then we don't serve any leasesets.

dr|z3d either way, local / private dbs are only used for flooding to other ffs, not for lookups. I think that's the general idea, no?

eyedeekay No we use the locals for lookups too

orignal bad idea

orignal an advesary can publish specialy baked leaseset to your floodfill

orignal and then ask your destination to connect to it

eyedeekay In our case the destination shouldn't be able to know about it because it's not able to get the leaseSet out of the main router netDb, it has to get it out of the client db now

orignal then what do you mean about locals?

eyedeekay I want to call the clients

eyedeekay *them

eyedeekay 'Sub-NetDbs used for Client operations, belonging to a single destination'

dr|z3d I'm trying to arrive at a naming scheme that informs the user of the scope of each db, how it can be accessed, and its function.

eyedeekay That's why I like client, but floodfill/router could be main or trunk or participating or anything else for all I care

eyedeekay I picked floodfill when I was prototyping it because I needed to keep track of the one that might be a floodfill

eyedeekay Whether it was or was not, any potential floodfill was to be tagged with the floodfill dbid

eyedeekay It came out to just needing the one

eyedeekay And it's really just the main netDb

eyedeekay The one used the way the old netDb was

dr|z3d so floodfills will respond to lookup requests for a local client leaseset from the client netdb, not from the main/public/floodfill db?

obscuratus clients flood their LS out their tunnel. It may get flooded back, maybe not.

dr|z3d for some reason I thought part of the attack mitigation strategy was to respond to all requests for a local leaseset from the public netdb.

eyedeekay If it comes in or goes out a client tunnel, it goes into or comes out of a client netDb, if it goes direct, then it comes from the floodfill netDb

dr|z3d ok

obscuratus We may need to change this in the future, but, as it stands now, the client will never select it's own router for a FF. But if it get's flooded back, the floodfill neDb will keep it's own, separate copy of the LS, and respond to searches freely.

dr|z3d we were discussing the naming of the dbs before you arrived, obscuratus. we're agreed that floodfill netdb is poorly named, so we're working on with main / public / remote right now.

dr|z3d I'd like to have a naming scheme that gives the user a good idea of the scope of the main / client dbs, and adequately differentiates between the two, but main / client might just be sufficient given the somewhat blurred lines.

obscuratus Something like "mainNetDb" would probably be more clear.

obscuratus Changing the floodfill name shouldn't be too hard. Updating the client naming scheme will take more work.

eyedeekay I am OK with client/main

dr|z3d ok, let's settle on that.

eyedeekay Ack, I'll push that with my other fix in a few mins

dr|z3d eyedeekay: this looks wrong: if (clientsOnly) {

dr|z3d netdb = _context.floodfillNetDb();

dr|z3d I suspect we want netdb = _context.clientNetDb(client); if (clientsOnly) no?

dr|z3d except we want clientNetDb(all clients) however that's specified, a for loop or whatever.

obscuratus clientsOnly sounds like a dating app.

dr|z3d !!

dr|z3d wresting with the UI as we speak. :|

RN clientsOnly, a most exclusive dating app.

RN ;)

dr|z3d yeah, I was wrong anyways, it appears to be functioning correctly, even if the UI is somewhat jank.

zzz ping eyedeekay

dr|z3d eyedeekay is currently in the middle of building a house to live in, zzz, so don't expect a quick response :)

eyedeekay Ping zzz

eyedeekay Pong, rather

zzz ha

zzz git 502, gitssh down

eyedeekay Dammit not again, ok just a sec

zzz also, netdb code comments go to you? you prefer here or a git issue?

eyedeekay Git issue would be easier to keep track of for me

zzz ok

zzz just to be clear:

zzz I'm not planning or prepared to deeply review the last 6 months of changes, now or soon.

zzz If there's something you want me to look at in depth you'll have to ask and I'll give you a timetable, and it won't be fast

eyedeekay Sure. If something stands out to you then feel free to call it out but don't break your back or bore yourself on it

eyedeekay There gitlab's back now

zzz I just don't want you to rely on me for any significant quality-assurance role for the next release

eyedeekay Sure, acknowledged

zzz eyedeekay, the next release is 2.what? and when?

eyedeekay 2.4.0 and right now it's scheduled for the week of the 18th, but could be pushed back

zzz so tag freeze in two days?

eyedeekay 4, I have it scheduled for the 8th

eyedeekay Here's the forum post: i2pforum.i2p/viewtopic.php?p=2832&sid=a40c3ba2de14e80e6772c5e11ac597d8#p2832

zzz thanks

zzz did you fix whatever your problem was from months ago pulling translations?

eyedeekay Yes I did

zzz super

eyedeekay And we're updated to the new Transifex API now, workflow is basically identical but we can use the new application

zzz does the old tx CLI still work?

zzz I'd guess not?

eyedeekay No it broke that's why I updated it

eyedeekay The new one they want you to use is: github.com/transifex/cli

zzz ok so they finally turned it off, months later than they said they would

zzz another thing I'll have to catch up on

eyedeekay Yeah they turned it off like exactly the day I needed it, but the interface to the Go application is almost exactly the same and the config files are only a little different

zzz FYI I still have my WIP/TODO list from February, and the tx stuff was probably on there. I think the list is where I'll start, discovering what got done and what remains

eyedeekay OK, take your time

zzz yeah lmk if the schedule changes but for now assume I won't be doing anything before the release

eyedeekay Sounds right to me, only 2 weeks away anyway not much time for anything new

zzz here ya go eyedeekay git.idk.i2p/i2p-hackers/i2p.i2p/-/issues/401

eyedeekay Thanks

orignal zzz are you going to attend today's meeting?

obscuratus Oh, damn! Thanks for the reminder. :)

orignal we need to discuss some important problem

zzz orignal, sorry, no time and I wouldn't be any help anyway, have to refill my brain first

orignal believe me you can

orignal it's about SSU2

orignal and only you can help

dr|z3d help him, ob1 kenobzzz, you're his only pope :)

orignal because nobody else is qualified enough to sort it out

dr|z3d you need to give him a little time to reconnect with the i2p-o-sphere, orignal. :)

orignal I'm pretty sure he was not suffered by amnesia ))

dr|z3d don't call him, he'll call you. :)

obscuratus He's probably exhausted from having to hike out through the mud from Burning Man.

dr|z3d he has a date with his uzi. needs a good polish.

zzz maybe I can soon but not today, sorry

orignal no rush

zzz don'[t put me to work on Labor Day :)

orignal it can wait