#ls2 (irc2p) | #ls2 Proposal 168 review here 8 PM UTC Tues. Dec. 3

eyedeekay Sorry I'm late, bouncer trouble

eyedeekay Welcome to the resumed LS2 meeting

eyedeekay Only 2 topics from me today, 1. 2.2.1 release, 2. R/U/H caps

orignal hi

eyedeekay Anybody here? orignal, obsucratus, dr|zed?

orignal also publishing SSU as SSU2

dr|z3d hi eyedeekay

eyedeekay OK that will be 3.

R4SAS hi

eyedeekay Hi dr|zed

obscuratus Hi

eyedeekay Hi R4SAS, orignal, obscuratus

eyedeekay Thanks for coming everyone

eyedeekay OK so 1. is 2.2.1 release, this is a point release for Java I2P 2.2.1, i2pd need not do anything for this release, I2P+ it's up to you if you want to sync up with this one

eyedeekay Key change is blocklist updates, key updates, and packaging fixes for Debian and Docker

eyedeekay Also translation updates

orignal when is the next major release?

eyedeekay I'd like us to return to a 3 months cycle after this, which would put the next major release in early-mid July

orignal nice

eyedeekay If that works for the i2pd team then tenatively, I'd like it to be July 15

dr|z3d I'm still not convinced we need a .1 release, but hey.

dr|z3d for debian, sure, but for java installer, not so much.

eyedeekay Your choice if you want to follow along with it, it's not going to contain anything you can't do without

eyedeekay in particular, since I2P+ has it's own translations it's not that important for you

dr|z3d yeah, nothing there that screams do a new release :)

eyedeekay Got disconnected, anything else related to 1?

orignal no

dr|z3d I think we covered 1.

orignal mid Jul is fine

eyedeekay good

eyedeekay 2. R/U/H caps

eyedeekay I did some homework on this one, trying to find where we use these caps with git grep as suggested by dr|zed

eyedeekay We do use the U cap in a way which seems significant, we mark routers who transmit the U cap as soon as we get a routerInfo from an unreachable router

dr|z3d we check for U to determine if we should use a router for tunnel builds, mostly we don't if U, except occasionally for exploratory tunnels. and other places.

eyedeekay It seems that it's used as an optimization of sorts when making the decision

orignal but my question is not this

orignal my question is even U is useful why do you have to send it?

orignal you can always figure out from addresses

eyedeekay I don't think strictly speaking we "have" to send it, same for R, if you want to know, just try and reach it obviously

dr|z3d orignal's suggesting we could just tag routers on the fly as R or U, and I think we do, but we rely in the first instance on what the router tells us.

orignal so my question is if I have to send it or if you can handle RI without it

eyedeekay Yeah we can handle RI without it as far as I can tell

obscuratus Our exploratory build success rate went up a lot when we started de-emphasizing U routers. It's handy to have a tool to quickly screen these out.

orignal also it's confusing for ipv4 and ipv6

orignal now tell me what's wrong with U routers?

orignal that you have to exclude thme from tunnels

dr|z3d I thought about U re ipv4/6.

dr|z3d If I'm R on ipv4 and U on ipv6, unless you're ipv6 only then R makes sense.

orignal what if you are R on ipv6 and U on ipv4?

orignal that's more realistic scenario and you confuse everybody

dr|z3d for ipv4 U and ipv6 R, then I don't know what you'd publish? R? what exactly are we publishing? the fact we have a reachable public address? if I'm not ipv6 and you're only R on ipv6, then perhaps locally I should be changing you to U.

orignal zzz said R

obscuratus I agree with the general principle that we can figure out reachability ourselves based on RI. U routers should be as viable for tunnels as R routers, but, historically, they're not.

orignal we explude U routers only for IBGW

dr|z3d I exclude U from everything.

R4SAS dr|z3d: currently I tendency to have ipv6 and not ipv4 on some VPS, and, sometimes, I see same for end-users on some ISP networks

R4SAS *I see

eyedeekay canon uses them for exploratory tunnels sometimes but for the most part doesn't like to touch them

orignal dr|z3d what you do without R or U?

dr|z3d assuming the router's reachable, then I don't think I do anything particularly.

dr|z3d I don't think I do anything different from canon, anyways. not as I recall.

eyedeekay Java marks routers reachable or unreachable locally after various operations

obscuratus eyedeekay: Do we store that anywhere? Or do have to figure that out every time.

orignal do you know what's published for U4 and R6?

eyedeekay git grep Unreachable and git grep Reachable will show you usages of markReachable, markUnreachable, wasReachable, wasMarkedReachable

eyedeekay IIRC these aren't stored persistently, it's part of the profile

orignal tell me what if an anvesary publishes R but no IP in any address

orignal *advesary

eyedeekay Those will become unreachable, but I don't know for sure when

eyedeekay I'll put finding out on my list

dr|z3d if a router has no transports reachable, it's tmep banned.

eyedeekay ^

eyedeekay Thanks dr|zed

orignal what if it has introducers but publishes R?

dr|z3d > No transports (hidden or starting up?):BXwk5hI2KCgFONODZMtpujGHf8YkfT7BpgLRWVMpa50=

dr|z3d aka temp ban.

orignal No transports means what?

orignal sec

dr|z3d no ssu/ntcp published. there's also:

R4SAS no ssu/ssu2/ntcp2 I think

dr|z3d > Unreachable on any transport:1qRe4VWwVWSb~tu1Jf5ml-CPOEgymhfVTzCVkZTE87w=

dr|z3d yeah, correct, R4SAS

obscuratus I thin 'No transports' really mean 'no reachable transports' in this context.

orignal dr|z3d someting wrong with you

eyedeekay Fair point

orignal BXwk has transports

orignal please check your code

dr|z3d that was a transient ban, orignal, not current. historical.

dr|z3d just randomly pulled from my collection of banned routers.

orignal SSU2 and NTCP2

eyedeekay What a coincidence

orignal No recahnble transort and no transports are diffeent things

dr|z3d indeed they are.

dr|z3d no reachable transports means they're published in the RI.

dr|z3d no transports means they're not published at all.

orignal No transports means fake

orignal no reachable transports is valid situation

eyedeekay My thesis at the moment is that R provides less useful information than U. If a router voluntarily says "U" that is immediately actionable, but an "R" router still needs to be tested if it's actually reachable.

orignal so please define what U means

orignal introducers or no published IP?

obscuratus In Java I2P the functions that determine Reachability have a slightly different meaning. Introducers might return from that function as reachable. And it does get to orignal's point.

obscuratus I can see Java I2P refactoring to determine reachability without 'R' and 'U'. But it might get more complex as we dive into it.

orignal I asked for clafirication of U ling time ago

orignal but still don't have na anwer

orignal my question is very simple

orignal if I have ygg only is it U or not?

eyedeekay IMO it's U

orignal dr|z3d btw how do you classify ygg-only routers?

orignal do you consider them as no transports?

orignal eyedeekay maybe we should write a proposal about R and U?

orignal but I don't know where

eyedeekay Yes I think we should, we have options, we can do it on my gitlab instance or on github in an issue/discussion

eyedeekay I'm also willing to join git.community.i2p if that's better for you

orignal will try

eyedeekay OK. Are we ready to move on to 3?

orignal yes

orignal 3 is simple

orignal Java still publises SSU

orignal should do the same as with NTCP2

eyedeekay To clarify, are you talking of disabling SSU1 and expressly publishing SS2

eyedeekay *SSU2?

orignal I'm talking about publishing SSU2 as SSU2

orignal I don't know how it's implemented for NTCP2

eyedeekay I don't see any good reason why not at this point

obscuratus It effectively bans routers older than, what? 0.9.50? But we've starting doing that anyways.

orignal I'm asking about your timeline

eyedeekay Tenatively, let's have the timeline be the mid-july release

dr|z3d ygg I suspect would be unreachable if they're publishing an address.

orignal fair enough

orignal dr|z3d so you consider ygg only router as invalid

orignal and it's wrong

dr|z3d not invalid, unreachable, but I'm not 100% certain of the dynamics there.

orignal the problem that you exclude them from netdb

orignal on floodfills

orignal it means if someone request you for one you decline

dr|z3d I never got deep into the whole ygg router thing. left that to zzz.

eyedeekay I'll put ygg interaction on my to-research list

eyedeekay Anything else on 3 and/or for the meeting?

orignal eyedeekay not iteraction

orignal just consider them as valid routers in ntedb

dr|z3d yeah, a brief discussion about congestion caps

orignal and let floodfill respond properly

dr|z3d for 3a.

orignal go ahead

dr|z3d what are you publishing now, orignal? just E and G?

orignal E for release and E and G for trunk

orignal never publish D and ignore it

dr|z3d ok. so why not D?

orignal I don't understand it's purpose

orignal what I should do with it

dr|z3d well, for lower powered routers, ie embedded, arm, whatever, D should always be published.

orignal and if I see D what I should do?

orignal also what is "lower powered routers"?

dr|z3d if you see D, be fairly conservative in your requests. perhaps exploratory only, or only use for transit if there are no non congestion cap routers available.

eyedeekay routers on slower systems or less-reliable connections, Android springs to ind

eyedeekay *mind

dr|z3d yup, android, arm, that sort of thing.

orignal slow connetuon is L

dr|z3d we're talking about capability, not b/w speed

orignal I don't see what's wrong with andorid on WiFi for example

dr|z3d ie the system's ability to host tunnels.

orignal yes I know

orignal that's why I don't understand D

dr|z3d avoid D routers for most things should speed up the network.

orignal for slow connection it's L

eyedeekay Maybe if you want some logic to determine what kind of resources and/or connection in your Android package?

orignal fine. will D

orignal explude D from client tunnels

orignal will do

eyedeekay Thanks

eyedeekay Anything else?

dr|z3d perfect.

dr|z3d nothing from me.

orignal we don't have any perormanc eproblem on andorid

orignal neither RPi

orignal no old PCs like pentiums

eyedeekay I'll defer to your judgment on specifics

dr|z3d you can be more fine-grained regarding publishing D if you want.

dr|z3d for android, D is probably mostly a good idea.

orignal you didn't tell me why

dr|z3d I mean, the assumption is Android routers are mosly phones.

eyedeekay Exactly

orignal ofc I'm talking about phones

dr|z3d so you'd want to avoid routing transit tunnels through them if possible.

orignal why?

dr|z3d what might be an idea is to allow the auto-D cap to be overriden.

orignal they can handle transit

eyedeekay Or detect if you're on Wifi, 5g, etc and set accordingly

orignal it only makes sense if they are on mobile netwrok

orignal e.g. D is "worse than L"

eyedeekay Yes

orignal 5g? how about 2G? ))

dr|z3d because performance on android phones is generally not the best, network connectivity isn't always great, and maybe the user doesn't expect to see a huge chunk of traffic on their phone heating it up and causing thermal throttling.

eyedeekay Also battery life

dr|z3d that too.

orignal but what about anonymity?

orignal no transit no anonymity

dr|z3d send some exploratory tunnels their direction.

weko i2pd works on my mobile perfect. battery life - another talk

orignal mobile netwrok might make sense

weko sure

orignal but really anonymity concern

weko so. let me add 4. current attack

weko why attacker start again?

weko 2 months of quite and again.

orignal retoric question

dr|z3d I don't think the attack's ever stopped, not entirely.

dr|z3d tunnel spam, sure, that died down for a while, but there are still plenty of shitty ffs out there.

eyedeekay Yeah I don't think it ever fully stopped

weko i didnt see any "external" activity very long

eyedeekay Traditionally the attacker has attacked around this meeting time

eyedeekay They like to blow the channel offline after we meet

eyedeekay Rather, IRC itself

eyedeekay Could be that we had an LS2 meeting

weko nice

orignal interesting coincidence

orignal but he started this morning in EST

eyedeekay Yeah

weko so, i want to ask set the time in UTC in channel's topic

eyedeekay Ack, can do

orignal but it is in utc

weko i even dont know what is UDT ))

eyedeekay It's a typo I didn't catch until you pointed it out to me

weko oh sorry then ))

dr|z3d Universal Degradation Time. obviously :)

weko :)

eyedeekay Should have been UTC this whole time

eyedeekay Will set it correctly when the topic changes

eyedeekay Anything else for the meeting?

orignal no

eyedeekay got disconnected again, that's what I get for taking meetings on a mobile

eyedeekay Anything else for the meeting?

orignal no

orignal don't use mobile ))

orignal anynomity and smartpohone

eyedeekay Hard to get cable when you're in a moving car

eyedeekay All right, next meeting will be the 24th

orignal you should use them togeher ))

eyedeekay Thanks everybody for coming, see you around the IRC