IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2022/02/08
@eyedeekay
&eche|on
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+acetone
+dr|z3d
+hk
+orignal
+postman
+weko
+wodencafe
An0nm0n
Arch
Danny
DeltaOreo
FreefallHeavens
Irc2PGuest21357
Irc2PGuest21881
Irc2PGuest89954
Leopold_
Nausicaa
Onn4l7h
Onn4|7h
Over
Sisyphus
Sleepy
Soni
T3s|4_
aargh2
anon2
b3t4f4c3
bak83
boonst
cancername
cumlord
dr4wd3
eyedeekay_bnc
hagen_
khb
not_bob_afk
plap
poriori
profetikla
r3med1tz
rapidash
shiver_
solidx66
tr
u5657
uop23ip
w8rabbit
x74a6
eyedeekay Hi everyone welcome to the Feburary 8th dev meeting
eyedeekay Sorry about last week, hopefully the message dropping issues will not recur
eyedeekay Topics:
eyedeekay 2. Outproxy Requirements(ongoing)
eyedeekay 3. 1.7.0/0.9.53 status / release schedule
eyedeekay hi everybody
eyedeekay Let's start right in 2) Outproxy requirements
eyedeekay zzz found us a bunch of old lists of requirements, which we should either A) choose one or B) collate into a new list
eyedeekay I've been trying to do some research into which requirements are feasible and get some guidance from what Tor does
eyedeekay At the same time, some groups and some individuals have emerged to volunteer to help with outproxies, one of which is also a multiple Tor exit node operator operating a non-profit, so hopefully we can benefit from their experience
eyedeekay In some cases I find the rules a little murky: - Optional allowlist/blocklist of hosts/IPs? for instance, seems straightforward at once but what we suggest blocking/allowing on a host/IP basis might open operators up to request to block things they don't want to block?
eyedeekay Seems like the advice may have been that it's safe to block "ports" but maybe not hostnames?
zzz I think there's two categories of requirements
zzz 1) Things that we as a project would want to see (header requirements, small error page, link to additional info)
zzz 2) Things that any rational outproxy operator would want, especially admin tools, but we don't have the expertise to offer much guidance
zzz we should focus on 1)
eyedeekay OK that's easier, approaching it from the other direction was like cramming for a test
zzz and we should not attempt to offer a turnkey packaged solution for 2), only perhaps suggest some best practices
eyedeekay But I think it implies we'll need to be flexible, i.e. things we want will need to be subordinate to the things they'll be able to offer
eyedeekay That's probably a given though
zzz I'm thinking everything in 1) is pretty basic
zzz 1a) filter out any X-I2P headers outbound. Do or don't add an X-forwarded headers in either direction?
zzz 1b) have a small error page with a link to more info
zzz 1c) have a privacy policy on the more info page
zzz stuff like that
eyedeekay Yeah I agree, that shouldn't be difficult
eyedeekay So I'll avoid trying to figure out what people "should" do re: category 2) for the time being and focus on 1)
eyedeekay Anything else for topic 2)?
zzz The other thing in 1) is http vs. standard tunnel. I _think_ http is the right choice, and the choice affects the header issues
zzz eot for 2)
eyedeekay The standard tunnel doesn't add the X-I2P-* headers at all does it?
zzz no, it doesn't know about header
zzz *headers
zzz so the choice affects what the external proxy software "sees"
eyedeekay So why http? Wouldn't it be better if the server software didn't have to strip/re-add/keep track of the X-I2P headers to keep them from leaking?
zzz any proxy needs to deal with headers
zzz the proxy standard specifies that some headers are "hop-by-hop" and need to be stripped/added
zzz and of course there's both the HTTP and HTTPS (CONNECT) cases to deal with
eyedeekay So in the HTTP tunnel case we would be actually using the X-I2P headers
zzz they could be used e.g. for rate limiting by a competent outproxy admin
eyedeekay Makes sense
eyedeekay Anything else on 2)?
eyedeekay 3. 1.7.0/0.9.53 status / release schedule
eyedeekay We're exactly 13 days from release on the 21st
eyedeekay Tags are freezing tomorrow
zzz yup, checkin deadline Fri. Feb. 18
zzz i2pd will be releasing on the 19th or 20th with a fix for the nasty SSU bug that's been causing network reliability issues the last couple of months
zzz our release will also have some related workarounds and improvements
eyedeekay Good to hear, that's been a rough ride for a lot of folks especially on mobile
zzz I'm hopeful that conditions will improve pretty rapidly once people start upgrading
zzz other than that, the cycle has been pretty smooth, things are quieting down
zzz we're at 14,000 lines of diff, pretty good size
zzz eot for 3)
eyedeekay I don't have much to add, I'll still be making tiny CSS changes for the next week or so to deal with some quirks on extra-small or extra-wide screens and some contrast issues in the dark theme, but other than that my time will be spent trying to review and test
zlatinb I would like to run some tests in the testnet after both i2p and i2pd freeze the code for the release. I've documented them on the gitlab wiki.
zlatinb eyedeekay: what about end-to-end test for the windows aio?
eyedeekay I got one working yesterday, I had a couple issues to deal, one on the build-config side and one on the router.config side but they should both be gone now as long as I'm extra-careful with my release build
eyedeekay Turns out I had built the package without incrementing the router version number so even if a download happened(which would not have happened because the URL in router.config was wrong) it would not trigger an update
eyedeekay Both those issues are fixed now and I've set up to test the package after I get it built
eyedeekay So my updates were badly broken, but now they should be fixed, EOT
eyedeekay Anything else for the meeting? Questions, comments, concerns?
zzz aio == "bundle" or "easy install bundle". Let's not use "aio" as the name for it anywhere
zzz I always think async i/o
zzz nothing else for me
eyedeekay OK yeah AIO is ambiguous means different things to different people
eyedeekay I'll stick to Bundle or Easy-Install Bundle
eyedeekay All right thanks everybody for coming to the meeting, see you next month on the 5th, looks like
zzz eyedeekay, note that our d/l page branding is still inconsistent, Windows is a "easy-install bundle" but Mac is just a "bundle"
zzz buttons: Windows: "I2P Easy Install Bundle (Beta)" vs Mac: "Mac OS DMG I2P Bundle"
zzz Header: "I2P for Mac OSX" vs button: "Mac OS DMG I2P Bundle"
zzz other header "I2P for Mac DMG Bundle"
eyedeekay Lost in the shuffle, I'll do the Mac page now
eyedeekay but the reason(at least, IMO) that the titles are different is because the Windows installer is trying to "more" in the sense that it's configuring your browser and everything, the idea is to not leave the user with any "Steps" to complete per the postinstall/redirect page
eyedeekay What if I change it to "I2P+Profile Bundle?"
zzz I think we settled on "Easy Install Bundle" or "Easy-Install Bundle". I'm talking about our main d/l page, not the mac page. haven't looked at that in a while
zzz I2P+Profile doesn't sound or look good
eyedeekay Yeah you're right
zzz eyedeekay, you didn't mention it in your CSS item in the meeting, but don't forget about the jump error pages, still need some tweaks
eyedeekay Yup it's on my mind, that and the welcome wizard on the dark theme
zzz super, thanks