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