I2P 开发者会议 - 2005年12月20日

15:20 <jrandom> 0) 嗨 15:20 <jrandom> 1) 网络状态 15:20 <jrandom> 2) I2PSnark 更新 15:20 <jrandom> 3) Syndie 博客界面 15:20 <jrandom> 4) ??? 15:20 <jrandom> 0) 嗨 15:20 * jrandom 挥手 15:20 <jrandom> 每周状态说明已发布在 http://dev.i2p.net/pipermail/i2p/2005-December/001240.html 15:22 <jrandom> 好的，跳到 1) 网络状态 15:22 <jrandom> 除了状态说明里的内容，我没什么可补充的。 15:22 <+Complication> 要不是偶发的 OOM（内存耗尽），我都敢说状态不错了 15:22 <jrandom> 负载测试结果相当乐观，说明我们在性能上还有很大提升空间 15:23 <+Complication> 会增加不稳定性，当 i2p-bt、i2psnark 或 i2p-rufus 实例在……的时候。 15:23 <jrandom> 呵，和 i2psnark 有关的 OOM？ 还是之前就有？ 15:23 <+Complication> 会导致不稳定，当 i2p-bt、i2psnark，或 i2p-rufus 的实例做……事时。 15:24 <zzz> 我的看法是，种子流量的增加在一定程度上影响了 IRC 的可靠性 15:24 <+Complication> （也许我不该把 SAM 的怪异问题称为 OOM，因为我没细看，但它确实是因素之一） 15:24 <jrandom> 嗯，我不确定，因为 IRC 的状态和最新的 snark 更新前差不多 15:25 <+Complication> 带宽一直很稳，尤其是 tunnel 也很稳……就是偶尔会崩一下 15:26 <zzz> 无论如何我很乐观，0.6.1.8 中即将推出的 tunnel 构建修复应该会改善大家的 IRC 体验 15:26 <+Complication> 出于已知原因，希望到了时候它们会自行消失 :) 15:26 <jrandom> 嗯，我也这么想 zzz，所以我们可能在接下来一两天发一个版本 15:26 <+legion> 嗯，IRC 可能太敏感了，也许用 jabber 之类的会更好？ 15:26 <zzz> 尤其是机器和/或网络较慢的用户 15:27 <jrandom> 换成 jabber 并不会改变什么 15:27 <+Complication> 尤其是在 tunnel 冗余为 2 的情况下 15:28 <+bar> 我会说，IRC 是判断网络“天气”的绝佳“屎表” 15:28 <+legion> 是啊，风一吹 IRC 就挂了 15:28 <+bar> 正是 :) 15:28 <+Complication> 我注意到在修复拉黑（shitlisting）之后，“Recent” 往往总是超过 “Known” 15:29 <+Complication> 这是不是因为 “Known” 不包含被拉黑的节点，而 “Recent” 包含？ 15:29 <jrandom> 是的，IRC 能很好地反映情况，因为不同用户的体验差异很大（比如 dreamtheaterfan 总是有问题，等等） 15:30 <jrandom> 嗯，这说得通，Complication 15:30 <+Complication> （我不确定，只是猜测） 15:30 <jrandom> （因为被拉黑的节点会从 netDb 中剔除，但它们的配置文件不会被移除） 15:32 <+Complication> 那这些指标看起来就正常了（只是确认一下以防不然） 15:33 <jrandom> 好，关于 1) 网络状态 还有别的的吗？ 15:33 <jrandom> 如果没有，我们继续到 2) I2PSnark 更新 15:33 <tealc_> 有哪些更新？ 15:34 <jrandom> 参见 http://dev.i2p.net/pipermail/i2p/2005-December/001240.html 获取简要列表 ;) 15:34 <jrandom> 基本上，I2PSnark 现在可以通过单个 I2P 目标同时处理多个种子，带有 Web 界面，并集成到 router 控制台中 15:35 <tealc_> 我在跑最新的 CVS 构建，而 i2psnark 造成了很多内存堆错误之类的 15:35 <+Complication> ……而且它还能处理由 Azureus 创建、包含奇怪元标签的种子。 15:35 <+Complication> 之前它会卡在这些上。 15:35 <jrandom> 啊，对的，那里面我还在调一些问题，tealc_ 15:35 <jrandom> （就像每周状态说明里提到的 ;)） 15:35 <jrandom> 啊对，Complication 15:36 <jrandom> 哦，还有，Azureus 的人修了他们 tracker 里的一个 bug，之前它会导致 I2PSnark 无法使用它 15:36 <jrandom> （所以运行 B16 之前版本 Azureus tracker 的人应尽快升级） 15:37 <+bar> 我希望能方便地禁用 i2psnark 的自动启动（用于低带宽场景等） 15:38 <jrandom> 这个加起来应该很容易 15:38 <+bar> 太好了 15:39 <jrandom> 好，关于 2) I2PSnark 更新还有别的吗？ 15:40 <jrandom> 如果没有，我们继续到 3) Syndie 博客界面 15:40 <zzz> 给新版 i2psnark 点两个赞——干得好 15:41 <jrandom> 多谢，mjw 做了许多艰苦工作，让 snark 如此容易扩展 15:41 <jrandom> 正如状态说明所述，syndie 现在有了一个新的博客界面 15:42 <jrandom> 我认为它会在白名单和黑名单之间取得平衡，帮助人们应对不同的垃圾信息问题 15:43 <jrandom> 我们会在下个版本发布它，这样大家一两天内就能深入试用 15:43 <+legion> 垃圾信息近期真会成为大问题吗？ 15:44 <+Complication> legion：正如有人“热心”示范的那样，有可能 15:44 <jrandom> 不，黑名单可以应对灌水的作者，白名单可以应对制造大量作者的垃圾发送者 15:44 <dust> （匿名会让某些人表现出最糟糕的一面） 15:44 <jrandom> （所以垃圾信息不是问题） 15:45 <+Complication> （不过我觉得那家伙在重新生成密钥以躲避永久拉黑，这确实会带来一定的减速。） 15:45 <+Complication> 不过减速不算大，因此我完全赞同白名单也很好。 :) 15:46 <+bar> 也许将来如有必要，可以采用某种 Hashcash 方案 15:46 <jrandom> 如果有必要吧，但我看不出为什么会需要 15:46 <+bar> 同意，目前我也不觉得需要 15:46 <+Complication> bar：比如“除非他们肯花算力算点儿东西，否则不显示”？ 15:47 <+bar> 是的，大概这个思路 15:47 <+Complication> 听起来可行，尽管大概没必要。 15:47 <+bar> 大概是。 15:47 <jrandom> 如果一些垃圾发送者不停用大量新作者来灌水，人们仍然可以在自己的博客里发布书签和博客引用来告知他人新作者 15:47 <+Complication> 或者说，希望是没必要的。 15:48 <+Complication> 也许可以考虑 Syndie 是否能容纳这样的功能，以备不时之需。 15:49 <jrandom> 可以的，通过在博文的头部或博客自身的 metainfo 中实现 15:49 <jrandom> 呃，metadata（元数据）（该死的 bt！） 15:51 <jrandom> 好，如果 3) Syndie 没别的了，我们跳到 4) ??? 15:51 <jrandom> 还有谁有别的要在会上提出的？ 15:51 <+legion> 有，几件事 15:52 <+legion> 先说 clunk 15:52 <jrandom> 不错，clunk 听起来很有意思 15:52 <+legion> 正如我今天早些时候在 i2p-chat 里提到的，我一直在努力让它能用 Cygwin 和/或 MinGW 编译。 15:53 <+legion> 目前只有客户端有问题，其余包括服务器都能编译并且看起来能跑 15:53 <jrandom> 不错 15:54 <tealc_> i2p 可能会成为乔治·布什无限监控计划的一个真正麻烦。到时候在死亡营见，记得带上扑克牌啊 15:54 <+legion> 我一直在尝试不仅找出客户端出问题的原因，还要解决它。眼下我卡住了。 15:56 <+legion> 我还想讨论另一件事：能否在下次更新中加入一个到我 jabber 服务器的默认 tunnel？只是为了让想尝试 jabber 的人更方便。 15:57 <tethra> 20:34:37 <jrandom> if a set of spammers were flooding with lots of new authors all the time, people could still tell other people about new authors by posting their bookmarks and blog references in their own blog <--- 或许可借鉴 polecat 的信任合并方法在这里发挥作用？（也就是既能屏蔽垃圾发送者，又能提升受欢迎的作者。） 15:57 <tethra> </$0.02> 15:58 <+polecat> 那算是我信任网络想法的一个原始示例，采用 100% 信任传递的启发式，是的。 15:58 <jrandom> legion：为新用户添加一个默认禁用的配置很容易，但我犹豫的是协议过滤（以及哪些客户端会泄露哪些信息）。 你对不同客户端的经验如何？ 15:59 <jrandom> 是的，把信任度量整合进 syndie 的空间很大 16:01 <+legion> 据我所知，jeti 不会泄露，除了它的文件传输，不过我在服务器设置里已经禁用了。可能下个 jeti 版本会修好。除此之外我不清楚其他客户端。 16:02 <+legion> 我可以确定群聊是稳的，不论用什么客户端。只是群聊之外的联系人通信，有些客户端可能会泄露，尽管我不确定。 16:03 <jrandom> 嗯，是否泄露并不是一个布尔问题，关键在于客户端泄露了什么信息，而不是是否泄露任何信息 16:04 <+legion> 对，我当然是指诸如 IP 地址之类的关键信息，不过好的客户端即便泄露这种信息，也应该只报告为 127.0.0.1 或 localhost 16:06 <+legion> 所以我建议只用已知不泄露的客户端，比如 jeti。 16:07 <zzz> 你能在你的客户端图表里加一列“已验证不泄露”吗？ 16:07 <jrandom> 如果你能把 jeti 会和不会泄露的内容文档化就很有用（类似 postman 为 SMTP 和 POP 代理整理的那样） 16:08 <+legion> 据 jeti 的开发者说，它不会泄露任何会危及匿名性的东西。这一点毫无疑问。我也看过它的源代码，没发现能让我认为相反的东西。 16:09 <jrandom> 开发者这么说也许没错，但开发者对匿名性的理解又是另一个问题 ;) 16:09 <+legion> 好的 zzz，我可以加这么一列 16:09 <jrandom> 我不怀疑 jeti 可能表现良好，但我们需要知道这意味着什么 16:10 <zzz> 看起来“不泄露”只能通过协议跟踪来验证 16:10 <zzz> 而不是靠看源码或问开发者 16:12 <jrandom> 好，会议还有别的吗？ 16:12 <+bar> 只是提醒别忘了 amd64 jbigi 16:13 <+bar> （不过我打赌它在你的待办里） 16:13 <jrandom> 嗯 :) 16:13 <jrandom> （指的是 Windows amd64，Linux amd64 已经在工作了） 16:13 <jrandom> 不过，如果没别的了…… 16:14 * jrandom 收尾 16:14 <+bar> 是的，Windows amd64。 16:14 * jrandom 用 *baf* 结束会议