#i2p-dev (irc2p) | 2.7.0-2 | Proposal 168 review Tues. Dec. 3, 8 PM UTC #ls2

zzz ping eyedeekay re: jbigi

eyedeekay pong zzz

zzz ok

zzz so, while it would be nice to have the ability to build new jbigi binaries on windows...

zzz it's not a part of our release process and shouldn't be a part of yours

zzz the binaries are prebuilt in installer/lib/jbigi

eyedeekay OK I'll switch to those

zzz just take the jbigi.jar from the xxx-windows-only target and make sure it's in your build

zzz it's all done for you

zzz building all the binaries takes hours

zzz whatever your issue is, don't try to fix it by building your own out of core/c

zzz does that make sense eyedeekay ?

eyedeekay Yeah sure, although I'm just slightly confused about "hours" is that on a much older machine? For me it was more like 20 minutes.

eyedeekay Is hours what you experience on the laptop ~10 years old, the one that you own that I also own?

eyedeekay I'm curious because that big a discrepancy might mean something is not getting built, and that I need to examine to see if I inadvertently broke something

zzz take a peek at what zab did to force it into jpackage

zzz eyedeekay, the build.sh script only builds ONE binary.

zzz to generate binaries for all CPUs, you need mbuild-all.sh

eyedeekay Oh that makes sense

zzz we have 34 binaries :)

zzz eyedeekay, it's been 7 years since we last updated them, last done by hottuna3, if you now have the ability we could plan to do it sometime this year

zzz it's a big testing effort though and not any fun at all

zzz windows wrapper also 7 years behind... that's considerably easier

zzz actually 8 1/2 years, last done by kytv

eyedeekay I don't know how far I would get off the bat, I assume I don't have all the cross-compilers I would need configured to get all 34 binaries built successfully yet but I did manage to get everything I tried to build(Linux amd64, Linux ARM, Windows amd64) to complete successfully

eyedeekay The buildscript seems to run a suite of tests after completing

zzz but you were building on windows, right?

eyedeekay My changes from last night were to get it to work on Windows, but I built on Linux as well to make sure I didn't break other platforms fixing Windows

zzz if you can build 1 on windows you can build all 34, no addtional tools or x-compilers needed

eyedeekay OK then I guess I'm probably good to go

zzz just grab the jbigi.jar from the standard build, get it into and back out of the installer, check the /logs page, done and done

zzz also note that all our dll's in installer/lib/jbigi are signed by zab

zzz tl;dr do it the easy way :)

eyedeekay Can do, thanks for the help zzz

eyedeekay Where should I start reading to build the Windows wrapper?

zzz for another day, but installer/lib/wrapper/README.txt and installer/lib/wrapper/win64/README-x64-win.txt

zzz basically, tanuki doesn't provide win64 binaries with a permissive license, so we have to build are own, also we stick our toopie icon in there

zzz *our own

zzz eyedeekay, also FYI I asked the translators to work on android and gave them a deadline of Sunday (time unspecified)

zzz be sure to reserve some time this week to make sure android is happy

eyedeekay OK will do

zzz thanks, good luck with jbigi.jar

zzz eyedeekay, I'm updating the roadmap, and pushing everything of yours to 2.2.0, sound right?

zzz done

eyedeekay Yes please

eyedeekay Thank you

zzz and for some reason the roadmap said this release would be 1.11.0 and git blame blamed me

Opicaak zzz, may I get a description for i2cp.delayOpen and i2cp.newDestOnResume? Neither R4SAS or I could find anything about it in the docs.

zzz Opicaak, R4SAS, while labeled as "i2cp" options, these are actually implemented in i2ptunnel

zzz newdest is briefly mentioned in i2p-projekt.i2p/spec/configuration but delayopen is not, I'll fix that

zzz anyway

zzz delayOpen opens the local port as usual, but does not build tunnels until the first socket comes in

zzz newDestOnResume only applies if closeOnIdle=true, and creates a new Destination before building new tunnels when the next socket comes in

Opicaak I see, thank you

zzz hopefully that makes sense, and happy to answer any other questions

zzz as these two are implemented in i2ptunnel, they would not be available via SAM

zzz you caught me at a good time, I'm in the middle of some other doc updates

Opicaak Great timing, could you describe delayOpen? Not sure if I missed it when disconnected. Or should I just wait for updated docs?

zzz delayOpen opens the local port as usual, but does not build tunnels until the first socket comes in

zzz newDestOnResume only applies if closeOnIdle=true, and creates a new Destination before building new tunnels when the next socket comes in

zzz hopefully that makes sense, and happy to answer any other questions

Opicaak Thank you

Opicaak Would be cool if there was a way to refresh circuit. Sometimes I get Denied or Banned for "excessive requests" when it was the first request I made. Getting new identity is pain and can't imagine others doing it, it has to be simple, just like Tor Browser has new circuit button, similar feature should be on i2p.

zzz i2p-projekt.i2p/spec/configuration updated

zzz if you get denied on your first request, it's not a per-user throttle, and a new dest ("circuit") wouldn't help

zzz also commented on the GH ticket

Opicaak Well the user (or me in this case) would need new b32 address, right?

Opicaak That's what I did to access the website.

zzz not if it's a total-connections throttle

Opicaak Oh, right

Opicaak Thanks for the reply on github.

zzz np

zzz also, you're disconnecting here hella-lot, so you may wish to invesitgate why and tune things up further before your next release

zzz I also recommend grabbing and testing latest i2pd source now as a part of your release prep

Opicaak Could be i2pd 2.44.0 related? I've noticed those frequent disconnects and can't really figure out why it's happening.

zzz I thought you weren't on 2.44, your last release was before that

Opicaak Yes, last "release" is on 2.43.0, I'm on a pre-release, that is using 2.44.0

Opicaak But thanks to this issue, I just noticed another issue with macchanger not executing properly.

zzz well, I'm not a i2pd expert, and it's strange for me the one to be giving you all this i2pd advice, but they're doing an unscheduled release soon for a reason (as am I)

Opicaak Looking forward to that

Opicaak And thanks for all of the help.

zzz give latest source a try, and your place for i2pd help is ilita #dev

Opicaak Will do

zzz that's your job as a "downstream", to always test with the latest upstream, report bugs back asap, and release shortly after they do

zzz not just have somebody they've never heard of dump a huge wishlist on them

Opicaak And have I? It's mostly to make i2p more usable, easy to access and better for everyone else, not me.

zzz contribute and they might be more willing to give you what you ask for

Opicaak I do believe I'm contributing already a lot.

Opicaak I'm not exactly sure where you are coming from or why you made this 180, I'm really confused.

zzz I know you never talked to me before a couple days ago. If you already have a good relationship with the i2pd dev team, that's great, and I'm sure it will continue

Opicaak Not only have I spent a lot of time creating the OS, contributing knowledge and time, but it also costs me a lot of money. Servers, domain name and lost profits. I didn't have to create the OS at all, but seeing that noone made it in 20 years, I made it and haven't asked for anything - from anyone.

zzz all I'm saying is that if they've never heard of you or your project, it's a big ask of them out of the blue

zzz sorry didn't mean to come off 180

Opicaak Obviously I'm not forcing them to implement anything, I personally don't care if they add anything I suggested, it's really not for me, but everyone else.

zzz sure

zzz and ofc you are contributing to the network and your users

zzz just trying to get bitcoin and everybody on the same page so we can fix the network, not sure if there's other projects out there with 150 tunnels each

zzz happy to have you hear, apologies again

zzz *here

Opicaak I'm just "advocating" for current and new i2p users.

Opicaak like I said, I personally don't care if any of it gets added.

Opicaak Just throwing some ideas around

Opicaak For the new circuit feature, I could've made a browser addon, but there is no API in i2pd for it, so can't do that. Possibly in the future I might revisit it. But like you said, it's perhaps useless anyways.

T3s|4 Opicaak: for i2pd feature requests; please contact 'orignal' (not a misspelling) on #ls2, here. He is there now, as always :)

Opicaak If the OS did contribute to the higher network load, then I'm sorry about that, I had no idea or intention it would cause this.

zzz #ls2 is for joint discussions between java i2p and i2pd; for i2pd-specific stuff, please use ilita #dev

Opicaak And about frequent IRC disconnects, it seems like using single in/out tunnel isn't ideal.

zzz hmm

Opicaak But that means the Client Tunnels are about 40 now, instead of 30-ish.

Opicaak But still disconnects.

obscuratus Opicaak: I'm not sure whether you're using Java I2P, I2PD, or something else, but, yeah, two tunnels (2 in and 2 out) makes a big improvement. It's tunable in each.

obscuratus I thought two tunnels was the default in Java I2P, and three or more in I2PD.

Opicaak I lowered it from 5 to 1, it was using about 150 client tunnels, but seems like using just one makes it really unstable, not only IRC but everything else too.

Opicaak 5 is the default for i2pd

obscuratus 5 is a touch high IMHO, but 1 tends to be unreliable.

obscuratus Opicaak: 150 client tunnels just for IRC?

Opicaak No, the entire OS.

obscuratus OK.

Opicaak Monero wallet, web browser, IRC, SMTP/POP, etc.

dr|z3d Opicaak: check your irc client ping timeout value. for best results, you want it high, around 600s.

dr|z3d from the I2P+ faq:

dr|z3d Some IRC clients are configured to disconnect from the server if there's been no communication with the server for a period of time, which can sometimes be problematic for I2P IRC if the ping timeout value is set too low. Setting the ping timeout value in your client to a high value (e.g. 320 seconds) will often result in a more robust connection to the network. In hexchat you can configure the value by typing

dr|z3d /set net_ping_timeout 320. This will write the value to your hexchat.conf file.

Opicaak Thank you, it was at 60, this might have been the issue all along.

dr|z3d more than likely.

dr|z3d you'll probably still experience the occasional disconnect, but not as frequently.

Opicaak I might need to restart hexchat actually, I've edited it in the config file.

dr|z3d Regarding your OS, depending on how you have things configured, I2P or I2P+ might make more sense than i2pd, given the provision of included apps such as a bittorrent client (XD is crap), webmail client, basic webserver etc.

dr|z3d and of course you also get the features you're looking for such as delayconnect, new key on reopen etc.