diff --git a/i2p2www/meetings/logs/263.log b/i2p2www/meetings/logs/263.log
new file mode 100644
index 0000000000000000000000000000000000000000..f9b580ef3a71d6ae17e0960ca783bcb9ad9a5688
--- /dev/null
+++ b/i2p2www/meetings/logs/263.log
@@ -0,0 +1,89 @@
+20:00:00 <zzz> 0) Hi
+20:00:00 <zzz> 1) 0.9.32 update (zzz)
+20:00:00 <zzz> 2) 34C3 funding email reminder (zzz/echelon)
+20:00:03 <zzz> 0) Hi
+20:00:05 <zzz> Hi
+20:00:44 <zzz> 1) 0.9.32 update (zzz)
+20:00:58 <R4SAS> Hi
+20:01:09 <zzz> ok, str4d has done some UI updates, and I've started on the prop 141 implementation but haven't checked anything in yet
+20:01:37 <zzz> we're on track for an early october release
+20:01:49 <i2pr> [Slack/str4d] Hi
+20:02:03 <zzz> I think str4d wants to prop his benchmark branch, he should do that soon? I've commented in his ticket
+20:02:20 <psi_> ay
+20:02:36 <i2pr> [Slack/str4d] I've only pushed a minor UI tweak thus far; I have more sitting locally that addresses a bunch more issues, but I need to go through my git -> mtn process
+20:03:09 <i2pr> [Slack/str4d] I'll look at the benchmark comments and finish / push that end of this week
+20:03:57 <zzz> ok I need to talk to you at some point about our release process. We had blocker tickets for .31 that weren't closed, probably want to insist that those are closed before a release
+20:04:08 <zzz> or else what does blocker even mean
+20:04:23 <i2pr> [Slack/str4d] Correct
+20:04:36 <zzz> anything elase on 1) ?
+20:06:01 <zzz> 2) 34C3 funding email reminder (zzz/echelon)
+20:06:11 <psi> does this release require removal of hostnames?
+20:06:15 <psi> in RI
+20:06:25 <psi> gah lag
+20:06:33 <zzz> see the proposal text for migration discussion
+20:06:45 <psi> kk
+20:07:07 <i2pr> [Slack/str4d] -1 on it being in this release without discussion of zombie mitigations
+20:07:08 <zzz> ok re: 34C3, if you want funding or free ticket you MUST email echelon by Sept. 30
+20:07:43 <zzz> in addition, echelon did have some server issues, so if you didn't get an ACK from him that he got your email, send it again
+20:08:46 <zzz> we have plenty of funds available for people but you must ask. We won't be funding people who ask after the end of the month
+20:09:48 <zzz> so again make sure that echelon has acknowledged receipt of your request
+20:10:03 <zzz> we will set the budget at next month's meeting
+20:10:19 <zzz> anything else on 2) ?
+20:10:36 <i2pr> [Slack/str4d] Not from me.
+20:11:26 <zzz> anything else for the meeting?
+20:11:54 <psi> i have something
+20:12:02 <zzz> psi go
+20:12:03 <psi> but it's long and teedious
+20:12:09 <psi> it's that aligned outbound tunnels idea
+20:12:36 <psi> originally i sold it to you as a OBEP load reduction technique
+20:12:45 <psi> that is a nice side effect
+20:12:53 <psi> but that is not the original intent
+20:13:10 <psi> the original intent was to reduce packet drop
+20:13:59 <zzz> ok, so what would you like to discuss about it?
+20:14:08 <psi> my question is: would java i2p implement aligned outbound tunels ?
+20:14:22 <psi> or is it too experimental for you?
+20:14:53 <psi> i am not as familiar with java i2p's code as i am i2pd's
+20:14:57 <zzz> can't answer now because I forgot the details. If you write it up and post it somewhere I'll be happy to give you an answer
+20:15:09 <psi> okay
+20:15:15 <psi> i guess you can close meet
+20:15:26 <psi> the idea is OBEP == IBGW
+20:15:35 <psi> with an extra hop on the OB tunnel
+20:15:38 <eche|offf> nothing from me so far
+20:15:43 <psi> such that OBEP == IBGW
+20:16:14 <psi> to reduce packet drop and OBEP pressure
+20:16:30 <psi> (at the expense of more tunnels)
+20:16:51 <zzz> ok, since you've already implemented it, any data on the benefits would be very helpful
+20:17:10 <zzz> anything else on aligned outbound tunnels?
+20:17:31 <psi> my initial observations of it is the initial RTT is the same as after
+20:17:44 <psi> rather, there is no initial RTT spike
+20:17:57 <psi> possibly because of the release of pressure on OBEP
+20:18:03 <psi> but that is just an assumption
+20:18:15 <psi> i want to test this on a testnet, of which we have with docker.
+20:18:25 <i2pr> [Slack/str4d] If there's something we can turn into a performance benchmark, LMK
+20:18:25 <psi> to collect hard numbers etc
+20:19:01 <psi> yeah same here, i am at a loss for a good perf benchmark
+20:19:18 <psi> i have been using icmp ping over openvpn
+20:19:23 <i2pr> [Slack/str4d] Actually this would be more like a metric, since it would depend also on network performance, and would likely differ depending on endpoint locations
+20:19:27 <psi> probably not the best way
+20:19:48 <i2pr> [Slack/str4d] But if we *can* make a repeatable benchmark, I'd want to add it to the suite I plan to start collecting
+20:20:18 <psi> what i use right now is, time to connect via dtls and then the following latency measurement via ping
+20:20:31 <psi> that isn't porable for java i2p i think
+20:20:45 <psi> unless socks5 udp works
+20:20:49 <psi> or i do some SAM stuff
+20:21:23 <zzz> anything else on aligned outbound tunnels?
+20:21:31 <psi> aligned outbound tunnels is still experimental and idk if the increased tunnel count is worth it or not yet
+20:21:49 <psi> so more research needed and it's getting scienced rn over at i2pd
+20:21:56 <psi> i'll let you know
+20:22:12 <i2pr> [Slack/str4d] Great, keep me appraised of the science in #i2p-science :slightly_smiling_face:
+20:22:20 <psi> kk
+20:22:21 <zzz> great, thanks for the update psi
+20:22:25 <zzz> anything else on aligned outbound tunnels?
+20:22:53 <psi> one final thing: it may be worth it to do something in addition to aligning tunnels, i.e. something like tor's rend spec
+20:23:17 <psi> as for what that is idk and will think about it outloud in #i2p-science
+20:23:20 <psi> (please join)
+20:23:29 <psi> that's it
+20:23:41 <i2pr> [Slack/str4d] All from me
+20:23:49 <zzz> anything else for the meeting?
+20:24:28 <psi> i am good
+20:25:15 <zzz> thanks everybody, see you in 4 weeks, which will be .32 release time
+20:26:10 * zzz ***bafffs*** the meeting done
diff --git a/i2p2www/meetings/logs/263.rst b/i2p2www/meetings/logs/263.rst
new file mode 100644
index 0000000000000000000000000000000000000000..3c5933ff5c9e97c61040f5e7558ab09ddc9558bd
--- /dev/null
+++ b/i2p2www/meetings/logs/263.rst
@@ -0,0 +1,13 @@
+I2P dev meeting, September 5, 2017 @ 20:00 UTC
+==============================================
+
+Quick recap
+-----------
+
+* **Present:**
+
+echelon,
+psi,
+R4SAS,
+str4d,
+zzz