I2P 开发者会议 - 2016年3月4日

15:00:05 <zzz> 0) 嗨 15:00:23 <zzz> 1) 本次会议的结构 15:00:32 <zzz> 2) 讨论路线图 15:00:37 <zzz> 0) 嗨 15:00:41 <zzz> 嗨 15:00:54 <str4d> 嗨 15:01:02 <xcps_> 嗨！ 15:01:27 <orignal_> 怎么样？ 15:02:18 <zzz> 请查看 http://zzz.i2p/topics/2021 里的帖子，以及 http://i2p-projekt.i2p/en/get-involved/roadmap 上的当前路线图 15:02:27 <zzz> 1) 本次会议的结构 15:03:22 <zzz> 我们直接进入路线图，还是先讨论高层优先级？ 15:03:53 <str4d> 我倾向于先讨论后者 15:04:41 <zzz> 好的，在帖子里我提出了两个优先事项——扩展网络，提升安全性 15:04:55 <zzz> 把它们作为高层原则听起来如何？ 15:05:25 <zzz> 我们先确定什么重要 15:05:32 <EinMByte> 听起来符合预期，我觉得 15:05:48 <EinMByte> 不过“扩展网络”应该按广义来理解 15:05:57 <str4d> 我觉得作为总体主题很好 15:06:03 <zzz> anonimal 在帖子里又提了很多，但这不是我想要的方向 15:06:13 <xcps_> 在我看来（IMHO），提升安全性应始终最重要 15:06:28 <zzz> 我们在审查路线图时还应考虑其他什么原则？ 15:06:28 <str4d> 我认为我们需要弄清这些在可交付成果上的具体含义 15:06:40 <EinMByte> 所以“扩展网络”也应包含“吸引更多研究关注” 15:07:00 <zzz> 扩展网络涵盖很多内容——参见帖子 15:07:09 <str4d> EinMByte，嗯，我好像也在帖子里提过 15:07:36 <zzz> 我们很快会明确这些的含义。现在先就重要事项达成一致。 15:07:58 <str4d> 对我而言，可用性非常重要，而且我认为它会反哺上述两方面 15:07:58 <zzz> 只要持续增长，一切皆有可能；一旦停止增长，就等于死亡 15:08:05 <zzz> 同意 str4d 15:08:41 <str4d> 短期看可扩大用户群，长期看可提升公众曝光度、研究人员易用性等 15:09:11 <EinMByte> 还要注意，增长是吸引研究人员的唯一途径 15:09:25 <zzz> 更多用户会带来更多开发者、研究人员、内容，等等 15:09:37 <EinMByte> 大型网络通常更值得研究 15:10:05 <EinMByte> 所以我认为我们都同意这两项优先级 15:10:16 <zzz> 我们去年增长的大部分来自 vuze。这很好，但我也希望有更多“原生”的增长 15:10:43 <zzz> 不过，也许在嵌入式应用上的增长，或总体上聚焦应用，是最容易的增长路径 15:10:48 <str4d> 对 15:11:04 <EinMByte> zzz：对很多人来说，使用一个在后台运行 I2P 并替他们处理配置的应用更容易 15:11:12 <sadie> 嗨——来晚了 15:11:20 <zzz> 嗨 sadie，很高兴你来了 15:11:23 <str4d> 在我看来这会来自 UI 和 API 两方面的可用性改进 15:11:42 <str4d> 后者我们已经在多个讨论中着手了 15:11:48 <zzz> 在某种意义上，应用才是 UI 专家，让他们按最佳方式捆绑 i2p 并决定如何呈现（或隐藏）它 15:11:58 <str4d> 嗯 15:12:08 <EinMByte> str4d：这确实是解决同一问题的不同方案。我更喜欢它，因为在我看来把 I2P 和所有东西都捆绑在一起无法扩展 15:12:30 <str4d> 这有点像我在 Android 上采取的做法 15:13:04 <EinMByte> 需要一种办法确保人们不会每个应用都启一个 I2P 实例 15:13:12 <zzz> 好的，关于第 1 项还有别的吗，还是我们转去看路线图本身？ 15:14:00 <str4d> 我觉得大家大体达成了一致 15:14:08 <str4d> （至少没有反对意见 :P） 15:14:14 <zzz> 我把帖子里的几行粘过来。不是定论，仅供参考 15:14:25 <zzz> 扩展网络 15:14:25 <zzz> 包括：营销、联合项目、捆绑更多东西、帮助他人捆绑 i2p、可用性、网站改进、更多翻译、演讲与展示、文章与故事、UI、Android、Android 应用、更好的 GFW 规避、orchid、为客户端开发者提供更多库与工具、更好地支持大型网站、支持替代 router 开发、联盟、提速与效率、容量、提升限制、进入 15:14:25 <zzz> Debian，…… 15:14:25 <zzz> 提升安全性 15:14:25 <zzz> 包括：加密迁移、订阅协议、新的传输协议、可插拔传输、LS2、NTCP2、新的 DH、密钥吊销、密钥存储、代码审计、Sybil、漏洞修复、命名、SSL，…… 15:14:46 <zzz> 好，我们继续 2) 路线图本身 15:15:10 <zzz> 网址是 http://i2p-projekt.i2p/en/get-involved/roadmap 15:15:50 <zzz> .25 基本完成，约 10 天后发布，所以我们看下今年接下来四个版本 26–29 15:16:00 <zzz> 这应该能支撑到 ccc 15:16:15 <EinMByte> 如果某项在 2017 下面，比如，那是意味着我们要到那时才开始看，还是意味着那时开始实现？ 15:16:41 <str4d> 从我们需要做的事情来说，我会把加密迁移和 Sybil 工作排在很靠前 15:16:42 <zzz> 1mb，我们当然希望现在就开始 2017 年的大项目，比如新的加密/DH、NTCP2 等等 15:17:04 <EinMByte> 另外，在我看来，现在 Eclipse 攻击是个问题 15:17:05 <zzz> 所以路线图可以包含这些的前期准备工作 15:17:23 <str4d> EinMByte，嗯，我把那归在 Sybil 之下了 15:17:36 <EinMByte> “午夜轮换”的想法行不通，我想应该有更好的替代方案 15:17:52 <zzz> 同意 15:18:05 <EinMByte> str4d：可以，把它们归为同类攻击是合理的 15:18:44 <str4d> EinMByte，我在 RWC 和几个人讨论过 15:18:48 <str4d> 有些想法，但在这里不太好展开 15:18:51 <EinMByte> zzz：所以如果我们想在 2017 年前开始 NTCP2/...，需要规划前期工作 15:18:58 <zzz> 对，1mb 15:19:02 <str4d> 对 15:19:20 <str4d> 我希望在路线图里包含规划和研究 :) 15:19:28 <zzz> 问题在于：我现在应该开始做 26，但我还不知道里面有什么 15:19:39 <orignal_> 能否给现有 NTCP 加随机填充？ 15:20:01 <str4d> orignal_，我不记得可以，不过看看 NTCP2 的帖子 15:20:02 <zzz> 先花 10 分钟规划一下 26，然后我们再看长期事项 15:20:13 <str4d> 好 15:20:14 <zzz> 告诉我今天该做什么 15:20:30 <EinMByte> 对，先专注这个 15:20:34 <zzz> 好，看看 25 的清单里哪些没做 15:20:50 <zzz> wrapper 没做，kytv 失踪了（AWOL） 15:20:54 <EinMByte> “加密增强”范围太广了 15:21:12 <zzz> 实际做的“加密增强”是一些 25519 的加速 15:21:34 <zzz> .25 的清单除了 wrapper 都已经进了 15:22:00 <zzz> 但 Sybil 方面还有很多要做的，所以把它留在 26 的清单里 15:22:08 <str4d> 好 15:22:25 <str4d> 我们把 GMP 6 推到 .26 了，因为需要更多测试 15:22:35 <zzz> 26 清单上还有什么该保留或调整的？ 15:23:05 <EinMByte> 最终要防 Sybil 可能工作量很大，所以在我看来是长期项 15:23:10 <EinMByte> （也就是说我们需要先做好文献综述） 15:23:15 <zzz> orignal，是的，有填充的 ntcp 就是 ntcp2 15:23:21 <str4d> EinMByte，Sybil 检测工具目前还没用于任何事情，这就需要更多规划 :) 15:23:49 <zzz> hottuna4 有一个月不在，不确定何时结束，所以 gmp6 可能赶不上 26 15:24:02 <str4d> 好的 15:24:37 <str4d> 地址簿的订阅协议改进：这应该尽快加入，这样旧的 Dest 所有者可以迁移到 Ed25519 15:24:37 <EinMByte> 我认为 CRL 不需要加问号 15:24:47 <str4d> 但实际要花多长时间？ 15:25:14 <zzz> 很快需要 tuna 的状态更新。我预计 26 上大块内容的“立项”截止期是 3 月下旬/4 月第一周 15:26:10 * str4d 还是不太明白 CRL 的事情，zzz 能详细说说吗？ 15:26:14 <zzz> 25 将具备从磁盘读取 CRL 的能力，所以我们可以把它包含在更新里 15:26:35 <zzz> 但这没太大用，因为在更新里我们直接删掉证书就能达到同样效果 15:26:56 <zzz> 所以如果想在不发布更新的情况下把 CRL 发给大家，我们会把它们放进订阅源 15:26:57 <str4d> 我只是想弄清用例 15:27:09 <zzz> 用例是某人被攻陷了 15:27:20 <str4d> 我们现在还不做证书固定（pinning）吗？ 15:27:30 <zzz> 不做 15:27:56 <zzz> 我已经完成了 90%，还需要把 CRL 塞进命名空间 15:28:46 <zzz> pinning 很棘手也很危险 15:29:05 <zzz> CryptoCat 干过“pinning 自杀” 15:29:17 <zzz> 他们做了 pinning，但中间证书变了 15:30:49 <zzz> 我不认为 pinning 能替代 cls 15:30:51 <zzz> crls 15:31:21 <zzz> CRL 不只是给 SSL，用在 reseed 和更新密钥上也需要 15:31:58 <zzz> 那我们把 CRL 继续留在 26 的清单里可以吗？它快完成了 15:32:20 <str4d> 我对 pinning 的担心在于，有人可以做类似 Quantum Insert 的事情把 reseed 域名劫持到别处，然后放一个满足域名要求的任意有效 SSL 证书，routers 就会接受 15:33:05 <str4d> 另外关于 CRL，如果我们用它禁用某个证书，那这个证书会被什么替换？ 15:33:25 <zzz> 不会替换。在下一个发布里大概才会有替代品 15:33:45 <str4d> 这个话题有点陷进细节了 15:34:07 <str4d> 我的意思是我们需要再多想想 15:34:24 <zzz> 好，那 CRL 留在 26，但细节我们接下来一两周再讨论 15:34:30 <zzz> 因为还不够清晰 15:34:38 <zzz> 继续 15:34:42 <zzz> 26 清单上还有什么 15:34:43 <str4d> 嗯嗯 15:34:50 <EinMByte> 好 15:35:08 <zzz> 订阅协议 15:35:28 <zzz> 这是站点加密迁移的关键 15:35:40 <EinMByte> 替代 hosts.txt 还是你指什么？ 15:36:22 <zzz> 是的，就是把 hosts.txt 做成订阅源的东西，比如 foo.i2p=b64#sig=b64#cmd=alt ... 15:36:26 <str4d> EinMByte，在地址簿订阅协议中加入签名的键值元数据 15:36:49 <zzz> 提案基本定了，但搁置了大约 18 个月 15:37:07 <EinMByte> 可以，不过 hosts 文件的体积会不会变得过大 15:38:02 <EinMByte> 也许可以加一个 since 参数，把某个时间点之前的所有主机名排除掉 15:38:07 <EinMByte> （避免在不需要时下载整个列表） 15:38:22 <zzz> 这最初是加密迁移计划的一部分，但很难做，也不是最重要的部分 15:38:49 <zzz> 但就签名的加密迁移而言，它是主要的遗留事项 15:39:26 <str4d> 我们其实已经有 etag 来做这个了 15:39:28 <zzz> 这又是那种细节很多但尚未完全达成一致、因此还没开工的事情 15:39:42 <EinMByte> 不过现在有在用吗？ 15:39:46 <str4d> 有 15:40:00 <EinMByte> 哦，没事，那就好 15:40:03 <str4d> 这和现在的设定没什么不同 15:40:20 <zzz> 所以我们把它放进 26 的清单，并尽快开工。不确定 26 能推进到什么程度，但我会尽力。我们需要回顾 zzz.i2p 上的帖子 15:40:22 <str4d> 但域名条目不再是一次性，而是会在“流”里重复出现 15:40:42 <EinMByte> 不过我们有什么特别理由要保留这种奇怪的格式吗？ 15:41:05 <EinMByte> 用某种标准格式似乎更容易 15:41:06 <zzz> 也许是为了兼容旧客户端。但我们需要回顾一下，确定这是否真的重要 15:41:20 <zzz> 我们可能有一年都没看过这个了 15:41:28 <zzz> 那我们把它翻出来看看 15:41:32 <EinMByte> zzz：兼容性可以通过在一段时间内同时提供旧的 hosts.txt 来处理 15:41:41 <str4d> 还有一个更广泛的问题，比如如何处理那些“丢失”的名字 15:41:53 <str4d> 但这超出当前讨论范围 15:41:57 <zzz> 对。我们还需要让其他实现参与进来 15:42:18 <EinMByte> str4d：我觉得那得等我们有了新的命名系统（如果我们真的会做的话）再决定 15:42:26 <str4d> 目前，我希望有种方式让当前活跃的域名更新它们的 dests 15:42:26 <zzz> 好，那它暂时留在 26 的清单里。下一个——Sybil 相关 15:42:45 <zzz> 我们能让 Sybil 变成自动的吗？希望你们都读了 Philip Winter 的论文？？？？ 15:42:50 <str4d> 越早把核心代码合进去，大概一年后我们就能越早开启 15:43:50 <EinMByte> zzz：哪篇论文？我明显错过了什么 15:44:27 <zzz> 去 Twitter 上找 @__phw 的链接 15:45:02 <zzz> 多亏了 sadie 在 ccc 的引荐，我们正和他合作 15:45:03 <EinMByte> zzz：这篇：http://arxiv.org/pdf/1602.07787v1.pdf? 15:45:27 <zzz> 如果是最近几周发布的，那就是它 15:45:59 <EinMByte> 这是今年二月份的 eprint 15:46:09 <zzz> 我觉得我们还没准备好自动化。他们其实也没有 15:46:22 <zzz> 他们不过是每天给目录权威发一封邮件 15:46:36 <zzz> 双方都是启发式和“黑魔法” 15:46:49 <EinMByte> 那他大概是在正式发布后把 eprint 放上去了 15:46:57 <zzz> 所以我想把自动化的东西推到今年晚些时候 15:47:07 <str4d> EinMByte，我这边是 2 月 25 日的版本 15:47:14 <EinMByte> zzz：那在去中心化环境下这究竟该怎么运作？ 15:47:44 <str4d> 我们需要自下而上地做，而不是自上而下 15:48:06 <str4d> 也就是说，每个 router 都需要在对等体画像里包含“可能的 Sybil 候选” 15:48:13 <zzz> EinMByte，我不知道。这很难 15:48:20 <str4d> 比如基于在线时长等 15:48:30 <EinMByte> 我觉得检测 Sybil 攻击是可行的，但在去中心化网络里基于检测来防御非常难 15:48:30 <EinMByte> 不过我喜欢这个挑战 15:48:34 <zzz> 我们还需要 gravy，他正在把他的方案改成中心化版 15:48:43 <str4d> 也可以考虑某种更中心化的设置 15:48:45 <str4d> 嗯，就是那个 15:48:45 <EinMByte> str4d：那样的话你就需要开始给每个 router 指派信任 15:48:52 <EinMByte> 而这本身又是一个完整的反 Sybil 体系 15:49:07 <str4d> 并让 routers 订阅一份潜在 Sybil 的列表 15:49:07 <zzz> 有点像 dagon 的提案 15:49:09 <str4d> EinMByte，但这基本上就是我们现在的对等体画像 15:49:31 <str4d> 其中“信任”目前被定义为“过去对我路由表现稳定良好” 15:49:42 <EinMByte> str4d：是的，而且它们到目前为止也引发过一些攻击 :) 15:50:15 <str4d> 对 15:50:23 <EinMByte> 另外，对等体画像并不真的允许你把某个对等体从网络里排除 15:50:31 <EinMByte> 而防 Sybil 在某种程度上会允许那样做 15:50:35 <str4d> 对等体画像和选择是我认为需要优先处理的另一个方面 15:50:46 <str4d> 它们可以的 15:51:01 <zzz> 所以我提议把 26 的 Sybil 项改成“持续改进”，把“自动化”部分往后推 15:51:01 <str4d> 不是现在 15:51:11 <str4d> 我只是说那就是我们会放它的地方 15:51:34 <EinMByte> str4d：是的，可以。 15:51:37 <str4d> （指把 Sybil 检测和更高级的技术纳入 I2P 的术语和架构） 15:51:53 <EinMByte> 无论如何，我不会放弃去中心化。在我看来（IMHO），那是 I2P 最好的一部分 15:52:14 <str4d> 对 15:52:27 <EinMByte> （而中心化也会带来各种现实中的攻击） 15:52:43 <zzz> 继续。streaming 改进？不太确定具体是什么，也许就是那个常年的“把它做得更好” 15:52:49 <str4d> zzz，对，我们可以继续做那个 routerconsole 页面，一旦决定策略，再把它接入对等体画像和选择 15:53:00 <zzz> 我想不到 streaming 还有哪些具体要做的。有人吗？ 15:53:01 <EinMByte> 有时加一个中心权威会让你的安全证明更容易，但在实践中导致安全失败 15:53:20 <str4d> 做些研究和优化会很好 15:53:28 <EinMByte> zzz：那里有什么显而易见的改进可以做吗？ 15:53:30 <str4d> 那是一个适合外部研究的好候选 15:53:46 <zzz> 我们确实需要更好的测试环境 15:53:51 <EinMByte> 同意。 15:53:55 <zzz> 加入延迟/丢包、乱序等 15:54:04 <EinMByte> 我们也许应该把这个和其他内容加到我们的“开放研究问题”页面里 15:54:40 <zzz> 我在 streaming 的清单里没有多少“天马行空”的点子，它需要由测试结果来驱动 15:54:50 <EinMByte> 在 tunnels 的分配上也许还有改进空间？ 15:55:05 <str4d> zzz，据我记得，有个 GH 项目用容器模拟“互联网”，可以做到这些 15:55:08 <zzz> 那我们把这一项定成“streaming 测试工具链”如何 15:55:17 <str4d> 不过不确定有多容易，我们每个容器都需要一个新的 JVM :P 15:55:25 <str4d> EinMByte，嗯 15:55:48 <EinMByte> str4d：我觉得可以用 Shadow。不确定能否与 Java 集成，但它在 kovri 的 TODO 清单里 15:55:52 <str4d> 不过那并不是 streaming，而是在数据报层面 15:56:22 <zzz> tunnel 分配这事是 psi 的主意——让 client 来选 tunnels 15:56:34 <EinMByte> str4d：是的，我怀疑这里还有不少可优化的 15:56:46 <EinMByte> zzz：我不太认为用户是最好的优化算法，不过也许吧 15:57:10 <zzz> 这会严重破坏我们的分层，我也看不到怎么做。但这就是 psi 提出的 15:57:19 <EinMByte> ……或者“client”大概不是指用户 15:57:32 <zzz> client == I2CP 的客户端一侧 15:57:44 <str4d> 关键在于 15:57:54 <str4d> Tor 确实通过它的 Control Socket 提供了这种能力 15:57:58 <EinMByte> 好的，所以确实是那个意思 15:57:59 <str4d> 这对研究人员很有用 15:58:10 <str4d> 但他们的架构也扁平得多 15:58:19 <str4d> 而我们通过 I2CP 把不同 client 隔离开 15:58:31 <EinMByte> zzz：我预期 router 有更多相关信息。client 可以传递额外的需求 15:58:41 <zzz> 我们还有 psi 为研究人员做的 Lua 钩子，既没合到 Java 也没合到 kovri，但仍是一个选项 15:59:14 <zzz> 要知道现在客户端一侧甚至不知道 tunnels 的存在，所以当然没有能力去选择它们 15:59:16 <str4d> 我在 RWC 和 nickm 聊过，他说对 Tor 来说维护一个 Control Socket 接口比维护插件系统容易得多 15:59:17 <EinMByte> 我知道 Shadow 在实践中被研究人员使用 15:59:22 <EinMByte> Lua，我就不清楚了 15:59:55 <EinMByte> zzz：那或许可以通过在 I2CP 上传递相关信息来实现同样的事情？ 16:00:17 <zzz> 1mb，可以，但会非常丑陋 16:00:44 <str4d> 我们总可以用一个 -research 标志之类的来限制 16:00:54 <str4d> （在 router.config 里） 16:01:06 <str4d> 这样大多数用户就不会接触到那些丑陋的东西 16:01:13 <zzz> kovri/i2pd 在 client/router 之间还没有那些刚性的 API 边界，对 16:01:20 <zzz> *them 16:01:28 <str4d> 而且我们可以从一开始就规定“.research”的含义为“我们保留更改这些 API 的权利” 16:01:44 <str4d> 也就是说，研究人员需要在特定版本中使用 .research 标志 16:01:57 <str4d> 回到正题： 16:01:59 <EinMByte> zzz：关于 tunnels，这要看情况。我觉得传递有关该 tunnel 预期用途的信息是有意义的。 16:02:20 <zzz> （FYI，此次会议最多再开 25 分钟，周日继续） 16:02:33 <EinMByte> zzz：主要对我们更容易，是因为 Shadow 用 C 写的，我想 16:02:42 <str4d> 我觉得这个应该归入“需要更多研究”类别 16:02:44 <zzz> 问题在于，不仅需要选你的 tunnels，还需要选对端的 tunnels 16:02:48 <EinMByte> 好。那继续吧。 16:03:08 <zzz> 好，这就是目前 26 清单上的全部。还需要加什么？ 16:03:11 <EinMByte> zzz：这不是由对端处理吗 16:03:36 <zzz> 不，我们是源路由（即为对方的入站从它的 leaseset 里选择远端 lease） 16:04:08 <zzz> 看看 27–29 的清单。有什么需要拉到 26 里的吗？ 16:04:44 <str4d> 我想开始为新的 LS 以及 netdb 做准备工作 16:04:46 <zzz> 这里有所有“2017 年 xxx 的前期工作”，也有很多 2016 的东西 16:05:23 <EinMByte> zzz：我误解了你说的对端是什么意思，没事 16:05:31 <str4d> 越早稳定下来并进入代码库，网络就能越早广泛支持它 16:06:42 <EinMByte> 请注意我们（kovri）需要规范文档 16:06:52 <EinMByte> 否则就很难跟上实现 16:07:31 <zzz> 当然。凡是新的规范，我们都需要一起协作完成 16:07:36 <EinMByte> str4d：先列出 LS2 实际应该支持什么 16:07:53 <EinMByte> （如果还没做的话） 16:09:40 <zzz> 基本上 LS2 就几件事 16:09:59 <zzz> 增加一些 flags 的空间 16:10:09 <zzz> 并为将来的加密算法做好支持 16:10:52 <zzz> 不过我还提了关于更好的多宿主，以及类似 Grothoff 的服务查找等一堆提案 16:11:00 <zzz> anycast 16:11:01 <EinMByte> 我们有具体清单可供参考吗？ 16:11:11 <zzz> 都汇总在 zzz 上，等下 16:11:23 <str4d> EinMByte，我正在慢慢把这些都整理到网站上 16:11:41 <zzz> 能快点吗 str4d？比如下周或再下周？ 16:11:47 <str4d> 这应该进 .26 的清单 16:11:50 <str4d> 嗯 16:11:53 <str4d> 可能可以 16:11:59 <str4d> 我需要更多人看看 16:11:59 <zzz> 如果没有把提案列成简单清单，这事就太难了 16:12:08 <EinMByte> str4d：太好了。其实对其中一些内容，wiki 功能会很有用 16:12:24 <EinMByte> （意思是这样会更快） 16:12:48 <zzz> 首先我们需要一份清单 16:12:50 <str4d> 没错 16:12:56 <zzz> 先别把海水都烧开了（不要把事情搞太大） 16:13:11 <str4d> 我正试图把后端所需的格式从 HTML 转向（目前是）rST 16:13:31 <str4d> 我需要大家过目，检查 a) 是否可用，b) 是否没有丢失我们目前已有的内容 16:13:39 <str4d> 目前只应用在规范文档上 16:13:40 <zzz> 把“提案这件事”放进 26 的清单，具体含义之后再谈。但我们需要尽快推动它前进。 16:13:55 <str4d> 一旦那部分稳定下来，扩展到提案就很容易了 16:13:56 <zzz> 我就想把它们放到网站上，形式无所谓。 16:14:46 <EinMByte> 我愿意审阅提案，但有时我就是找不到任何文本 16:15:10 <EinMByte> （我觉得网站上有些东西有点“藏”） 16:15:37 <zzz> 对 16:16:05 <zzz> 我们需要把 zzz.i2p 上的内容按某种组织方式迁到网站 16:16:13 <EinMByte> str4d：从 HTML 转向某种可以轻松转换为多种格式的东西是好事 16:16:28 <EinMByte> 是的，绝对如此 16:16:35 <str4d> EinMByte，我需要审查的内容在 i2p.www.str4d 里 16:16:36 <EinMByte> 也许应该为所有提案制定一个固定流程 16:16:57 <zzz> 好。它已经在 26 的清单上了。细节随后。str4d 开工吧。我不指望有太多反馈。你先搞出一套新系统，我们都会跟上 16:17:02 <str4d> 以及 http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/ 16:17:04 <str4d> EinMByte，如果你愿意和我一起把它敲定，我也许能在 .25 前完成 16:17:23 <zzz> 26 还有什么？我们得收尾了 16:17:36 <str4d> （EinMByte，具体是 http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/spec） 16:18:14 <zzz> 这些都是非常短期的事。我需要知道周一该做什么 16:18:27 <zzz> 关于 26 的最后征集 16:18:41 <str4d> 我觉得订阅那块会花点时间 16:18:49 <str4d> 所以我愿意把它作为主要内容 16:18:52 <zzz> 同意。 16:19:54 <zzz> 好。周日同一时间开会。我们先从 vrp/h1 开始。请提前查看工单 1119。之后如果时间允许，再讨论 27–29。 16:20:06 <EinMByte> str4d：你认为哪些最需要关注？ 16:20:27 <zzz> 如果需要，周日我们也可以简要回到 26 16:20:43 <str4d> 主要是决定提案撰写的格式是否可用，以及它是否会限制最终在网站上呈现的内容（无论是 HTML 还是 TXT） 16:20:45 <zzz> 所以周日的议程是 1) vrp/h1/1119；2) 26；3) 27–29 16:20:57 <zzz> 谢谢大家 16:21:25 * zzz *bafs* 会议结束了 16:27:50 <EinMByte> str4d：只要它能转换成大多数其他格式，应该就没问题 :)