👮 major
✅ irc2p
#i2p-dev #i2pd-dev #ls2 #saltr
✅ ilita
#4rum #acetonevideo #dev #retroshare #torrent #video2p
IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2023/09/04
@eyedeekay
+R4SAS
+RN
+T3s|4
+Xeha
+acetone
+orignal
+weko
Irc2PGuest67564
Onn4l7h
T3s|4_
anon2
eyedeekay_bnc
goose2
goose2_
j6
not_bob_afk
profetikla
qend-irc2p
shiver_
u5657
unwr
x74a6
eyedeekay Hi everyone welcome to the dev meeting
eyedeekay 1. Hi
eyedeekay 2. Release Date
orignal hi
orignal 3. SAM 3.3 protocol descripancy
RN :)
eyedeekay Any other topics for this meeting? Please keep it essential
eyedeekay Thanks orignal
orignal 4. what the next meeting with zzz?
orignal *when
obscuratus hi
orignal hi
eyedeekay 4. Not a topic because it can't be answered without him in attendance, ask him on your own time
eyedeekay Consider 3 on the agenda though
orignal 4. we should schedule the next meeting with him when he is ready
eyedeekay sure. When he is ready
eyedeekay Let's get started
eyedeekay 2. Release date
orignal release is 18-th. right?
eyedeekay We're going on the 18th, that's 2 weeks from now
orignal yes, fine for us
eyedeekay Ok that's settled
eyedeekay 3. SAMv3.3 protocol discrepancy
orignal 3.
orignal we have two version of SAM 3.3
orignal and both of them are 3.3
orignal maybe we should use different names like 3.3.1 or 3.3.BLM?
orignal brb in 5 minutes
RN 3.3.og
eyedeekay If this is about the primary/master thing added the note to the SAMv3.3 specification you asked for
orignal yes, but the problem is
orignal that both implementation return 3.3 in response
orignal we should add some attribute to differentiate them
orignal that's my point for the meeting
eyedeekay Sure that's not a bad idea all told
eyedeekay It could be also be useful for SAM to be able to return the implementation/version of the host router for that matter so libraries could respond to it
dr|z3d not sure that's necessary.
dr|z3d we just document the fact that the client should check for PRIMARY and if no response, try MASTER. job done.
orignal yes, so what do you think? should we introduce version like x.y.z ?
eyedeekay From a lib developer standpoint it would be pretty handy
orignal dr|z3d I diasgree because we have two SAM 3.3 with the same name
eyedeekay Let me think about it and write a proper change to the spec
dr|z3d orignal: then the plan should be to harmonize the implementations so they're feature equivalent.
orignal the idea is
orignal if we have two different protocols they must have different names
dr|z3d sure, if whatever this new protocol is, isn't following the official spec, then don't call it SAM at all.
eyedeekay I mean, regardless of the primary/master thing i2pd sometimes lags a little bit on SAMv3 features, I stand by my 'from a lib developer's standpoint' statement
dr|z3d is that what we're quibbling over? PRIMARY/MASTER, or are there more significant differences?
orignal it's not about SAM 3.3 it should be in general
orignal I propose to add "revision"
orignal like 3.3 = 3.3.0 and then 3.3.1, 3.3.2 etc.
eyedeekay dr|zed Datagram support was one for a while, not sure anymore
eyedeekay There are a few more on the spec page
dr|z3d so the i2pd implementation is lagging, or it's completely diverged from the protocol? the way orignal tells it, they've invented something entirely new.
orignal i2pd implementation of 3.3 is not complete ))
orignal being honest
eyedeekay More like just a little incomplete
eyedeekay That's why I suggested implementation/version
dr|z3d if that's the case, then i2pd should downgrade its version until it is. I don't see what revisions brings to the party.
dr|z3d if you're incomplete, then claiming you support 3.3 shouldn't be happning. 3.29 perhaps.
orignal that's fine
orignal up to you guys
orignal I can call 3.3.wlm if you wish ))
dr|z3d keep the trolling in #saltr, this is serious business time :)
eyedeekay I'll give it the serious parts of the proposal some thought
eyedeekay Anything else for the meeting?
dr|z3d yeah, one more thing.
dr|z3d router spoofing.. how you getting on with that provisional proposal orignal?
orignal dr|z3d I would like to discuss it with zzz
orignal and it's not router spoofing, it's address spoofing
dr|z3d you know how zzz operates, he really does like a proposal to look at so he comes prepared to the ensuing discussion.
orignal I would like to discuss the issue with him first
orignal since he was the one who designaed SSU2
obscuratus So, probably nothing on this before the release. I guess we can talk amongst ourselves on the Java-I2P side, but do we need to implement something before the release on this?
dr|z3d no time, too late in the cycle to start.
dr|z3d big changes deadline has passed.
eyedeekay Yeah let's wait until next time
dr|z3d and by the time we've all had this discussion, it'll be post release.
obscuratus OK.
eyedeekay Thanks everybody for coming, next meeting in 2 weeks?
dr|z3d baff it, eyedeekay. we're done here. :)
dr|z3d 2 weeks should be good, maybe zzz will be with us by then.
eyedeekay ok thanks everybody for coming
dr|z3d while both of you are here, eyedeekay, obscuratus, can either of you confirm we've got a client leaseset display dupe issue?
eyedeekay I'll set the topic in a few minutes
dr|z3d I'm currently addressed that with css, but that's just a short term fix so I don't go nuts trying to identify where the issue is.
obscuratus The 18th will be release day. Busy day for the next meeting.
obscuratus Doesn't the LS display show all LS for all clients? If so, that may be where the dups are coming in.
dr|z3d it's a dupe that occurs multiple times, including the summary table. so no. it's definitely a bug.
obscuratus dr|z3d: So, if you have three clients, you get three sections, one for each client, but every LS listed under each?
obscuratus So they're all repeated.
eyedeekay Which checkin are you merging? I fixed this a couple days ago
dr|z3d I've fixed the nav menu so it behaves more or less as it did pre-segmentation. Way too busy otherwise.
eyedeekay obscuratus I'd rather wait 3 weeks that's why I asked
eyedeekay 3 weeks better or 2? Show of hands lol
obscuratus eyedeekay: 3 weeks would be fine for me.
eyedeekay dr|zed orignal, 2, 3, don't care?
dr|z3d I merged the huge bundle of commits.
obscuratus eyedeekay: Re: dr|z3d's issue, I think I'm still seeing what he is describing. I think I'm current, but I was just about to update with the last four commits.
orignal what?
orignal next meeting?
dr|z3d 3 weeks sounds about right.
dr|z3d if 2 weeks coincides with release.
orignal 3 weeks is fine
eyedeekay Yes orignal
eyedeekay The 3's have it then, next meeting will be the 25th
eyedeekay It was IIRC the first checkin after the big merge
dr|z3d got it: git.idk.i2p/i2p-hackers/i2p.i2p/-/commit/d3ad082a82f4cbc60c4e350bc038d461f7ef42af
dr|z3d thanks
eyedeekay d3ad082a82f4cbc60c4e350bc038d461f7ef42af
obscuratus OK, I don't have this in yet.
dr|z3d can I just globally search and replace floodfillNetDb() with mainNetDb() ?
dr|z3d nevermind, I see there's a couple of other strings that need replacing.
dr|z3d eyedeekay: looks like you missed one in FNDF -> protected void createHandlers() {
dr|z3d // Only initialize the handlers for the flooodfill netDb.
dr|z3d if (super._dbid.equals("floodfill")) {
eyedeekay Oh thanks good catch I'll fix it in a minute
dr|z3d another couple of possibles, not sure if you squashed 'em:
dr|z3d router/java/src/net/i2p/router/networkdb/kademlia/FloodfillNetworkDatabaseSegmentor.java: _subDBs.put("floodfill", subdb);
dr|z3d router/java/src/net/i2p/router/networkdb/kademlia/FloodfillVerifyStoreJob.java: ds = getContext().netDb().lookupLocally(_key, "floodfill");
dr|z3d not 100% sure about the second one there.
dr|z3d or indeed the first, looking at the code.
dr|z3d we also have this code in the ff segmentor which looks like it should probably be removed, or at least not forgetten about :)
dr|z3d // DELETE THIS FUNCTION WHEN YOU'RE DONE!
dr|z3d private void alsoStoreFloodfill(Hash key, LeaseSet leaseSet) {
dr|z3d FloodfillNetworkDatabaseFacade fndb = _context.mainNetDb();
dr|z3d if (_log.shouldLog(Log.DEBUG)) {
dr|z3d // change these comments depending on whether you store or not. For testing
dr|z3d // purposes.
dr|z3d _log.debug("don't store " + key.toBase32() + " to floodfill");
dr|z3d // _log.debug("also store " + key.toBase32() + " to floodfill");
dr|z3d }
dr|z3d // fndb.store(key, leaseSet);
dr|z3d }
dr|z3d is that safe to comment out?
eyedeekay Yes it is
eyedeekay It's still there but the reason it needed to be deleted is not, now all it does is log a message
not_bob I don't need anything, just checking in.
dr|z3d ok, thanks, eyedeekay
dr|z3d obviously the call above needs commenting out too.
dr|z3d not sure you squashed this one, eyedeekay, in RouterContext: public FloodfillNetworkDatabaseFacade mainNetDb() { return _netDb.mainNetDB(); }