I2P dev meeting, September 6, 2016 @ 21:00 UTC

Quick recap

  • Present:

echelon, EinMByte, orignal, psi, str4d, z3r0fox, zzz

سجل IRC الكامل

21:00:01 <zzz> 0) Hi
21:00:01 <zzz> 1) 0.9.27 update (zzz)
21:00:01 <zzz> 2) Summer of X update (sadie/str4d)
21:00:01 <zzz> 3) 33C3 Budget http://zzz.i2p/topics/2150
21:00:01 <zzz> 4) SAM on by default (str4d)
21:00:06 <zzz> 0) Hi
21:00:12 <zzz> hi
21:00:13 <psi> hi
21:00:24 <eche|on> welcome
21:00:33 <z3r0fox_> Hi
21:00:40 <zzz> 1) 0.9.27 update (zzz)
21:01:01 <zzz> ok, not much to report. only 6K lines of diff since 26
21:01:13 <zzz> at this point I'd say .27 will be maybe mid-october?
21:01:41 <zzz> earlier in the summer I was doing summer of x stuff, lately I've been taking a break... but I don't see much activity from anybody else either
21:02:03 <zzz> anything else on 1) ?
21:02:19 <eche|on> not much on summer of X
21:03:25 <zzz> 2) Summer of X update (sadie/str4d)
21:03:30 <zzz> sadie / str4d go
21:06:07 <zzz> hearing nothing, I'll put it on the agenda for next month
21:06:15 <zzz> 3) 33C3 Budget http://zzz.i2p/topics/2150
21:06:28 <str4d> IHi!
21:06:33 <eche|on> Awake
21:06:33 <zzz> eche|on, could you please give us a brief update on our finances?
21:06:45 <str4d> Sorry, was distracted by work briefly. Can address 2) at end of meeting
21:07:34 <eche|on> finances, ok, current sums: 37k €, 510 BTC, 700 LTC and 1300 XMZ (round)
21:07:47 <eche|on> bts is around 540€ and LTC around 3.5€
21:08:00 <zzz> sounds like we are in pretty good shape
21:08:10 <eche|on> we spent roughly 4800€ this year already
21:08:56 <eche|on> and 10 BTC (which I converted into €), so we got roughly 5k € this year
21:09:20 <zzz> for 33C3, I propose to do about the same as we did last year... we pay for all conf tickets. And for full project members we'll reimburse up to $1000 (or euro), or $1500 if people really need it
21:09:41 <zzz> for people running a service or two, I propose we pay for their conf ticket and up to $500 in travel
21:10:01 <zzz> what do you all think about that?
21:10:23 <eche|on> currently we have 5 people requesting money
21:10:25 <str4d> I think that seems fair.
21:11:04 <str4d> eche|on, assuming the above figures, what's the expected total expenditure?
21:11:13 <zzz> so around $4000-$5000, plus about $500 in tickets, I'd guess?
21:11:32 <eche|on> with these rules, we got around 4k € max
21:11:39 <zzz> plus a couple hundred for a dinner
21:11:57 <zzz> oh, also, anybody who did NOT email echelon and wants funding, speak up now!
21:11:58 <eche|on> 2 people with services, 2 with usual and 1 with special circumstances
21:12:07 <eche|on> ticket will be around 100 each
21:12:12 <str4d> Mmm. That keeps us inside our rough 10% spending target
21:13:03 <eche|on> a bit above, but still ok
21:13:21 <zzz> sounds like about 5200 or so. Let's set a budget of 6000 euros?
21:13:46 <eche|on> last times some did receive their request in BTC, which made it quite easy for me^^
21:14:12 <zzz> yeah, anybody who agrees to get paid in BTC, thats better
21:14:21 <eche|on> sounds legit
21:14:48 <eche|on> dinner we may got to same place like last year or maybe a bit above, we will see
21:15:02 <zzz> I want to emphasize that we want to see everybody there. While we're trying to use our money wisely, we also would hate for anybody to not show up because they can't afford it.
21:15:09 <eche|on> some sweets and other stuff for the event itself, 6k is ok
21:15:10 <str4d> I'm certainly happy to be reimbursed in BTC
21:15:48 <zzz> anything else on 3) ?
21:16:15 <eche|on> not on my side, I will reply all emails tomorrow and will later on buy the tickets
21:16:18 <eche|on> oh, tickets:
21:16:36 <eche|on> if ANYbody in here from I2P did not request funding, but wants a ticket, send me a mail!
21:16:37 <str4d> Anyone looking to share accommodation, ping me :)
21:16:56 <str4d> eche|on, you're planning to buy the tickets for all team members?
21:17:03 <eche|on> yes
21:17:07 <zzz> yeah. Ech will buy the tickets. Do not buy your own
21:17:10 <eche|on> to get rid of the issues we had last year
21:17:12 <str4d> Thanks :)
21:17:34 <str4d> Also, am I correct that it generally starts about 11am local?
21:17:56 <zzz> oh, while we are on 3), I want to thank eche|on for all he does, including keeping the finances up to date. We'd be broke without you!
21:18:02 <str4d> I've been trying to figure out whether I can manage a flight that arrives on the 27th
21:18:02 <eche|on> oh, we did met mostly 11am/12am in place and styed until 1,2 am
21:18:05 <eche|on> but some talks ends at 3 am
21:18:10 <zzz> ok, lets not discuss logistics here
21:18:17 <zzz> anything else on 3) ?
21:18:19 <str4d> (otherwise I have to leave the evening of the 25th)
21:18:34 <str4d> eche|on, mmk, thanks. And yes, big thanks for keeping us floating! :D
21:18:55 <zzz> 4) SAM on by default (str4d)
21:18:59 <zzz> str4d go
21:19:08 <eche|on> thanks to all the donors (just got a donation with the line "do not spent all money on useless designers"
21:19:39 <str4d> Okay
21:20:29 <str4d> I'm thinking that with the rise of apps using the SAM API, we should consider whether we enable it by default, and if we do then how we should do so
21:20:51 <str4d> Similar to how Tor enables their control port by default, so apps can generally assume it is available
21:21:07 <eche|on> I think SAM ist quite stable and not a reason for a router to breakdown easy
21:21:19 <eche|on> I vote for yes, enable by default
21:21:25 <zzz> is there anybody complaining?
21:21:37 <EinMByte> Seems like a reasonable idea to me
21:21:55 <EinMByte> Only issue that I can see is conflicting ports
21:22:07 <str4d> Mmm
21:23:08 <eche|on> I do not see that issue on new installs
21:23:10 <zzz> the usual way to do it would be to change clients.config, which would only affect new installs. Anything else would be... harder
21:23:12 <eche|on> as it is all localhost
21:23:27 <str4d> I know Tor has been mulling over the security of having their control port open always
21:23:29 <eche|on> I would NOT enable it on old installs
21:23:36 <EinMByte> eche|on: I mean, there could be another service (non-I2P related) using the same port
21:23:43 <str4d> And they do encourage people to use the Unix socket mode instead
21:23:50 <str4d> (with local cookie authentication)
21:23:58 <zzz> I don't think apps can ever 'assume it is available', they will always need proper error handling and user messaging for it
21:24:01 <eche|on> EinMByte: sure, but thats localhost, and thats should be warned
21:24:08 <str4d> But that's not as much of a concern for us, because anything that can connect to SAM can only control its own tunnels
21:24:33 <str4d> (unless they can guess the session name of another clients' tunnels)
21:24:36 <EinMByte> eche|on: Ok, so if port taken don't enable SAM and warn?
21:24:41 <eche|on> EinMByte: thats the logical way of doing it^^
21:24:42 <str4d> zzz, sure, apps can't assume
21:24:48 <str4d> The reason for it is usability
21:24:58 <str4d> So the "simple option" is "start I2P; use app"
21:25:06 <zzz> so after years and years of it being disabled, enabling it now may not make much difference
21:25:16 <str4d> The current option is "start I2P; find page to enable SAM; enable SAM; use app"
21:25:33 <zzz> fyi I split up /configclients, that will be in .27
21:25:36 <eche|on> In my POV: most i2p routers do have SAM enabled yet already
21:25:39 <eche|on> if not >90%
21:25:41 <str4d> My main motivator is reduction of friction
21:25:48 <str4d> for new users
21:25:54 <str4d> so I agree this would only be for new installs
21:26:19 <EinMByte> That sounds OK.
21:26:27 <zzz> btw, I have yet to see evidence of your 'rise of apps using SAM'
21:26:30 <str4d> eche|on, yeah, Tor has a similar port-conflict issue with Orbot on some Samsung phones
21:26:46 <psi> sam should be default on so that people don't have to turn it on
21:26:50 <EinMByte> zzz: Maybe this is exactly what is needed ;)
21:26:51 <zzz> but I'm not opposed to the proposal either
21:26:53 <zzz> heh
21:27:05 <str4d> zzz, Tahoe-LAFS is about to launch with native I2P support
21:27:19 <EinMByte> Remind me what the default SAM port is?
21:27:21 <zzz> ok, sounds like we have a consensus?
21:27:32 <str4d> 7656
21:27:52 <zzz> anything else on 4) ?
21:28:36 <EinMByte> str4d: Ok, can't think of any common things using that
21:29:09 <zzz> 2) Summer of X update (sadie/str4d)
21:29:14 <zzz> sadie / str4d go
21:29:35 <str4d> Okay!
21:29:45 <str4d> I2P Summer Dev was IMHO a success
21:30:06 <str4d> We didn't get any new contributors (at least that I saw)
21:30:42 <str4d> (there were a few at one of the early meetings who we should have followed up on perhaps...)
21:30:45 <eche|on> we got a new buildbot
21:30:52 <zzz> I didn't see the promised August blog post... might we get a September one?
21:30:54 <str4d> But we made excellent progress on a number of user- and dev-facing fronts
21:30:56 <str4d> As I mentioned above, the next Tahoe-LAFS release will feature native I2P support via my txi2p library
21:31:13 <str4d> zzz, yeah, I didn't get time to do it. I'll be writing a roundup post this weekend
21:31:20 <zzz> great
21:31:47 <str4d> I have my Zeronet work locally that I wanted to feature in the August post, but unfortunately we couldn't get i2p.socket working with gevent properly...
21:32:05 <str4d> But I think I'll just make a PR with it this weekend, and we'll see how things go
21:32:33 <zzz> tahoe is what, 5 years at least since we entered the tickets on their site. zooko does not move quickly
21:33:05 <eche|on> at least it is now done
21:33:21 <str4d> So as far as dev usability goes, we've made good progress on i2p.socket and txi2p, and with the SAM API being enabled by default, there should be less friction for adding I2P to Python apps
21:33:25 <eche|on> now we need parallel up/downloads, or tahoe-lafs will crawl on
21:33:55 <eche|on> btw, a user asked me fe min ago about python dev work in I2P
21:34:04 <str4d> We did some outreach with potential new apps, but we need more work there
21:34:28 <str4d> (IPFS and OpenBazaar in particular are both keen but progress there isn't going forwards currently)
21:34:49 <EinMByte> BTW, apologies from me; I had said earlier I'd try to do something for summer of X, but it came to early for kovri
21:34:53 <zzz> the thing that's still in desperate shape after summer of x is Bote. No release in forever, and about 40 (!) trac tickets, including the classpath one I think is a blocker for .27 ... Do you have any intention on working on bote again or should we write it off?
21:35:30 <str4d> zzz, I do plan to, and I did work on it
21:35:38 <eche|on> someone should do bote. it is more important than syndie or i2phex
21:36:05 <zzz> I gotta know if we have to change the deb packaging to fix bote, or if it's something else that's wrong, or we don't care
21:36:32 <zzz> September of Bote?
21:37:22 <str4d> In August I spent some time migrating it to Gradle, meaning that I will be able to merge the android and plugin codebases
21:37:22 <str4d> This will remove a lot of the friction I have wrt developing on Bote
21:37:22 <str4d> All that's missing is integrating the existing plugin scripts
21:37:22 <str4d> (or rewriting them in Gradle)(
21:37:39 <str4d> Unfortunately work deadlines got in the way of that in August
21:37:54 <zzz> ok
21:37:59 <zzz> anything else on 2) ?
21:38:07 <str4d> I'll spend time on Bote this weekend
21:38:30 <zzz> anything else for the meeting?
21:39:02 <zzz> may I propose moving back to 8 PM UTC for October?
21:39:46 <str4d> and try to figure out a fix for the Debian issue
21:39:55 <zzz> any objections to 8 PM?
21:40:03 <str4d> But it's definitely Debian-only
21:40:24 <zzz> ok, I haven't even seen confirmation that it's deb-only, so that's progress
21:40:46 <str4d> Nothing else, other than good work everyone who worked on Summer Dev stuff!
21:40:46 <str4d> I look forward to next year ;)
21:40:49 <zzz> I've proposed a fix or at least a test in the ticket, but haven't heard anything
21:40:49 <eche|on> for me OK so far
21:41:22 <zzz> ok I got more ppl complaining about 9 than 8, so let's go back to 8. summer's over anyway
21:41:29 * zzz grabs the baffer
21:41:29 <str4d> I'm okay for 8PM in October, as I'll be in the US
21:41:31 <str4d> (And actually November too, since that would be the 1st(
21:42:37 <eche|on> ok, time to go to bed
21:42:41 <eche|on> cya
21:42:44 * zzz ***bafs*** the meeting closed