@eyedeekay
&eche|on
&zzz
+R4SAS
+RN
+acetone
+dr|z3d
+hottuna
+postman
+weko
An0nm0n_
Arch
FreefallHeavens
Gid_
Irc2PGuest19542
Irc2PGuest19856
Irc2PGuest2827392
Irc2PGuest71039
Irc2PGuest77041
Leopold
Minogami
Onn4l7h
Onn4|7h
ProRu
Sleepy
Soni
Teeed
aargh3
admin
anon3
b3t4f4c3__
eyedeekay_bnc
itsjustme
j6
limak
not_bob_afk
orignal_
profetikla
qend-irc2p
rapidash
tbqdrn
theglitch
user
w8rabbit
x74a6
zer0bitz
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
1. Hi
eyedeekay
2. Outproxy Requirements(ongoing)
eyedeekay
3. 1.7.0/0.9.53 status / release schedule
zzz
hi
zlatinb
hi
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)?
zzz
no
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