#ls2 (irc2p) | #ls2 I2P Protocol Development Discussion - Next Meeting Monday, October 9th 6:30 UTC

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(); }