IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2024/07/15
zzz last call for translations
orignal when do you satrt releasing?
zzz eyedeekay's schedule is on i2pforum.i2p, I believe Friday
orignal thanks
orignal whould be nice to anounce it on zzz.i2p
zzz I don't do the releases. Also, he told me he negotiated the date with you, so seems like you should know it ))
orignal I forgot ))
zzz eyedeekay, heads up, new java release tomorrow
zzz eyedeekay, translations are pulled/checked/pushed. I also did android
zzz eyedeekay, I don't see any newsxml entry yet, please get that going and let me know when I can push it to tx
zzz I also updated the tor blocklist
eyedeekay Thanks zzz I have a draft of newsxml local here I'll finish it up and push it today
eyedeekay Thanks everyone else as well, today is of course the checkin deadline, review period of ~4 days ending the 19th
zzz eyedeekay, ok, let me know so I can announce it over there
zzz eyedeekay, heads up, new java release tomorrow
eyedeekay Anyone who wants to review it change-by-change I find `git log --stat -p .` quite useful
eyedeekay Thanks zzz
dr|z3d about the tor blocklist.. given how frequently it changes, exit node churn, it might be worth considering an in-console mechanism to update it more frequently than once every 3 months.
zzz was thinking about that
dr|z3d I update it almost every time I push to git.
dr|z3d not a single day flies by without changes, it's that volatile.
zzz the right thing to do would be pull the list every day for two weeks before our release, then merge them all together
dr|z3d merge them all together?
dr|z3d not sure I understand.
zzz so if it was on the list any time in the last two weeks, we put it on our list
dr|z3d nah, that's not the right way to do it.
zzz e.g.:
zzz 185.220.101.128
zzz 185.220.101.130
zzz 185.220.101.132-185.220.101.139
zzz 185.220.101.141-185.220.101.147
zzz 185.220.101.149-185.220.101.150
zzz 185.220.101.152-185.220.101.159
zzz 185.220.101.161-185.220.101.164
dr|z3d whatever's current is current, adding the last two weeks worth of ips will get you a lot of crud.
zzz 185.220.101.166-185.220.101.171
zzz 185.220.101.174-185.220.101.183
zzz 185.220.101.185-185.220.101.191
zzz obviously we should be filling in the gaps 128-191
dr|z3d except quite often you'll see ips change in a range, not necessarily increased, just varied.
zzz it's not crud, it's noisy data, to smooth it out we need to do sampling/combining
dr|z3d if by noisy you mean stale, that's what I mean by crud :)
zzz I don't think the noise is real, I think that tor isn't doing the 'any time in last 24 hours' filtering right
dr|z3d possible, dunno.
dr|z3d I just figured there's a lot of churn, and ideally we don't want to be blocking ips that are no longer exits.
dr|z3d otoh, we *do* want to be blocking ips that are exits as much as we can, otherwise it's fairly easy to bypass Tor blocking by choosing exits not blocked.
zzz see example above. the gaps are obviously probable exits also
zzz you can't fix noisy data by trying to keep up with it
zzz and nobody's building plus from source and restarting every day, you're wasting your time
zzz you want to fetch the list once a day and save it
dr|z3d not at all. plenty of folk are pulling in-console dev updates.
dr|z3d so no time wasted :)
zzz then once a week, cat (last 14 days of saved lists) | sort | uniq | maketorblocklsit
zzz you want to _smooth_ the data, not keep up with it
dr|z3d not convinced that's worth the effort. I'm also not convinced the data needs smoothing, but I'm happy to be proven wrong.
zzz the noise/crud is your hypothesis
zzz if you want a daily update for your users, convert it to a feed; a button on the console is silly
dr|z3d sure, ideally you don't want manual intervention, but ideally you also don't want to be compiling the list daily yourself, you just want the console to automatically update from source.
dr|z3d (or a mirrored copy of the list that's hosted on the network, whatever)
zzz so if you want to add value for your users, set up your own feed for it, update it every day, and add that in the update subsystem
dr|z3d ok, might be the way to go. and subscription lists are added to the blocklist immediately, or after a restart?
zzz news feed blocklist is processed immediately
dr|z3d ok, thx
zzz but the feed blocklist doesn't handle ranges or subnets
zzz so it would take some work to add a 2nd blocklist to the feed, or implement a new feed type, or handle ranges
dr|z3d well, we've now got a script to consolidate ips into ranges, so support for ranges in the news feed might be worth thinking about.
zzz that's a security thing so nobody including me can accidentally or on purpose ban everything and destroy the network
zzz imho tor exits is a minor threat, the current solution that's probably 95% effective on day one and 80% 3 months later is good enough
zzz seems like you're more concerned about it which is fine, but just checking in a new list every day probably doesn't help your user base that much
dr|z3d like I said, for those regularly updating via dev builds, it helps, for those not, sure, nothing doing.
dr|z3d no real effort to update the list and push to git, anyways, I've got the updater as an ant task.
dr|z3d that'll be T3s|4 updating to the latest dev build ^ :)
zzz ok everybody, 10705 lines of diff, please review carefully, let's not have to do a 2.6.1 (((
zzz pretty typical diff size, but over half is SSU1 removal; the rest is pretty small, shouldn't be tough to review
zzz eyedeekay, please close gitlab #473 (wizard) if you fixed it, our process is fixer-closes
zzz also, probably, #411, #414, #405. maybe more
zzz eyedeekay, the snark rpc plugin should be easier than you described on reddit, just install the plugin, point the "arr" to port 7657, done and done
eyedeekay Ack can do, 473 is fixed, will check the others
zzz thx :)
zzz translation report MR #207 is up
zzz eyedeekay, I assume we'll be doing a couple of shorter 10-11 week cycles to get two more releases out before christmas?
zzz SVG graphs (aka puker) MR #208 is up
dr|z3d Remember that conversation we had where you said you weren't going to be drawn down the SVG rabbithole, zzz? You done good :)
dr|z3d and speaking of puker, I had a thought re qrcodes.
dr|z3d instead of attempting to render everything as svg, why not take the bitmap, embed it in an svg, and handle the optional text with svg - gives you more control of margins, text placement etc.
zzz yes I documented how I changed my mind in the plan in MR 206
dr|z3d not knocking your change of heart, it's a good call. users will appreciate the upgrade in image quality I'm sure.
dr|z3d also, puker, impressively compact. would be surprised if Mr rrd4j doesn't merge it tbh.
dr|z3d using it for qrcodes would give you an excuse to handle bitmap embedding.
dr|z3d excuse/motivation
zzz re: bitmap-in-svg, doable, but probably worst of both worlds
dr|z3d mostly yes, sometimes no. for qrcodes, would give us crisper text, optional css, and better qrcode placement. maybe it's worth the effort, maybe not?
zzz not by me, but knock yourself out
zzz eyedeekay, the CI (in particular the gradle build) has been broken since your checkin git.idk.i2p/i2p-hackers/i2p.i2p/-/commit/bd1f4c9f6a896d934378aad5216d8ba6bc1857f8 June 27; would you please investigate and fix