Краткое резюме
Присутствовали: ant, aum, bla, cervantes, detonate, duck, fedo, frosk, jrandom, legion, maestro^, mancom, named, postman, Ragnarok, septu_ssh
Протокол встречи
13:06 <@jrandom> 0) привет 13:06 <@jrandom> 1) 0.5.0.2 13:06 <@jrandom> 2) обновления mail.i2p 13:06 <@jrandom> 3) обновления i2p-bt 13:06 <legion> то есть это связано с irc-серверами? 13:06 <@jrandom> 4) ??? 13:06 <@jrandom> 0) привет 13:06 <@jrandom> еженедельные заметки о статусе выложены @ http://dev.i2p.net/pipermail/i2p/2005-March/000633.html 13:07 <fedo> привет 13:07 <+postman> привет 13:07 <frosk> добрый день 13:07 <@jrandom> legion: нет, связано с багами i2p, над ними работаем 13:07 <bla> привет 13:07 <legion> ок 13:07 <@jrandom> раз уж о багах, над которыми мы работаем, давайте перейдем к 1) 0.5.0.2 :) 13:07 <cervantes> здарова 13:07 <cervantes> -- Отключился 13:08 <@jrandom> хех 13:08 <ant> <mihi> всем привет 13:08 <@jrandom> 0.5.0.2 вышла, и хотя ваше irc-соединение временами может лагать, оно восстановится ;) 13:08 <@jrandom> ого, привет, mihi 13:09 <cervantes> привет, mihi 13:09 <@jrandom> в заметках дан общий обзор текущего состояния и первоочередных задач 13:10 <@jrandom> пугающая штука, которую я пытаюсь отследить, видна на http://localhost:7657/oldstats.jsp#router.invalidMessageTime 13:10 <bla> Со своей стороны могу сказать, что 0.5.0.2 уже _очень сильно_ повысила надежность по сравнению с 0.5.0.1: ошибки, когда нельзя связаться с destinations, почти не встречаются 13:10 <@jrandom> эти значения должны быть очень-очень маленькими, но, увы, нет 13:10 <@jrandom> клево, bla 13:11 <@jrandom> да, 0.5.0.2 определенно лучше, и всем стоит обновиться как можно скорее 13:11 <bla> 375,932.22 за последние 10 минут у меня.... 13:11 <@jrandom> ну, конкретное значение само по себе не проблема, проблема в их частоте 13:11 <@jrandom> (событий за период) 13:12 <@jrandom> эти сообщения, вероятно, приходятся на router'ы 0.5, и частично на 0.5.0.1, поэтому я и хочу, чтобы все обновились как можно скорее 13:12 <@jrandom> хотя может оказаться, что дело в другом, но я хочу это исключить 13:12 <bla> jrandom: у меня выходит около 200 в час 13:13 <@jrandom> bla: у меня сейчас 93 за этот час, но пик был намного выше (тысячи) 13:13 <@jrandom> в любом случае эта конкретная статистика публикуется в netDb 13:13 <bla> jrandom: Как насчет программно исключить 0.5-0 из сети при выпуске 0.5.0.3? 13:14 <@jrandom> так что мы все можем оглядеться и посмотреть, какие значения у других ;) 13:14 <@duck> 309,854.24 пик 5,473,314.59 13:15 <@duck> вставил не то, а? 13:15 <@jrandom> bla: определенно. Я добавил немного кода в ревизию 0.5.0.2 для некоторой forward compatibility, которой нет в 0.5.0.1 и 0.5 13:16 <@jrandom> duck: сложно иметь нецелое число событий ;) 13:16 <bla> jrandom: Хорошо. По крайней мере это позволит в контролируемых условиях проверить гипотезу «невалидные сообщения из‑за 0.5-0» 13:16 <@jrandom> bla: ага, хотя было бы отлично, если бы люди обновились до того ;) 13:17 <@jrandom> (а для читающих дома: http://www.i2p.net/download — ваш друг ;) 13:17 <maestro^> jr: эти числа для отклонений router.invalidMessageTime в мс? 13:17 <@jrandom> maestro^: да 13:18 <@jrandom> (то есть какие-то безумно искаженные значения) 13:18 <legion> Вот небольшой отчет по сети [версия|Число узлов][0.5|6][0.5.0.1|39][0.5.0.2|107] 13:18 <@jrandom> да, вы все молодцы, быстро обновляетесь 13:18 <legion> То есть есть еще несколько людей на 0.5 и многие на 0.5.0.1 13:18 <maestro^> есть идеи, где у них может лагать? 13:18 <bla> jrandom: У Freenet в каждом релизе есть флаг, который задает минимальную версию узла, с которой он будет общаться. Новый код forward-compat. — что-то подобное? 13:19 <@jrandom> maestro^: идей много — почему пользователи 0.5 и 0.5.0.1 лагают. 13:19 <@jrandom> bla: похоже 13:19 <maestro^> или это дрейф часов на узлах? 13:20 <@jrandom> maestro^: рассинхрон часов, баги сериализации, баг с 100% загрузкой CPU 13:20 <@jrandom> ок, это в целом мой фокус сейчас — пытаюсь поднять надежность доставки сообщений 13:21 <@jrandom> у кого-то есть вопросы/комментарии/опасения по 0.5.0.2? 13:21 <ant> * mihi тут есть router 0.4.2.5 на диске, не запускался с 22 декабря... но он думает, что лучше его удалить... 13:21 <@jrandom> хех 13:21 <@jrandom> да, он будет говорить не со многими routers ;) 13:21 * postman сделал резервную копию последней установки 0.4 :) 13:21 <ant> <mihi> для меня вопрос: обновить или удалить. 13:22 <@jrandom> удалить 13:22 <@jrandom> (сделав бэкап любых destination keys) 13:22 <@jrandom> больше нет процедуры обновления с версий до 0.5 13:22 <legion> Возможно, выпустить еще одно обновление, скажем, 0.5.0.2-1, которое позволит соединения только с 0.5.0.2 или новее, было бы неплохо? 13:22 <@jrandom> legion: это сегментирует сеть 13:22 <@jrandom> людям просто надо обновиться. 13:23 <@jrandom> (и нам стоит обходить тех, кто не обновляется) 13:24 <legion> ага, пока люди с устаревшими узлами не обновятся ;) 13:24 <@jrandom> сегментация сети вредит всем нам, а не только им 13:25 <legion> Может, сделать уведомление об обновлении в консоли router'а или что-то такое, чтобы они знали, что у них устаревшие версии? 13:25 <@jrandom> да, это было бы здорово 13:25 <@jrandom> надеюсь, это можно будет увязать и с обновлятором 13:26 <legion> да, знаю, сегментация — это плохо... 13:26 <@jrandom> smeghead работает над некоторыми ключевыми компонентами этого, хотя не уверен, включает ли это уведомление/загрузку 13:26 <@jrandom> (если кто-то хочет помочь с этим — свяжитесь!) 13:27 <@jrandom> ок, переходим к 2) обновления mail.i2p 13:27 <@jrandom> postman: ping 13:27 <+postman> да 13:27 <bla> jrandom: smeghead делал что-то связанное с подписыванием, насколько помню (IIRC) (чтобы когда приходит уведомление об обновлении, было понятно, что оно настоящее, а не фишинг/шпионское ПО/ерунда) 13:28 * postman берет микрофон 13:28 <legion> хм, может, если бы была встроенная функция автообновления, где обновления загружались бы через i2p, и узлы просто скачивали бы обновление, а потом делали бы мягкую перезагрузку. 13:28 <@jrandom> верно, bla 13:28 <ant> <Gatak> Кстати. Будет ли I2P работать за NAT, даже если нельзя открыть порт? 13:28 <@jrandom> Gatak: пока нет. некоторые смогут на 0.6, другие — на 2.0 13:29 <@jrandom> legion: патчи приветствуются 13:29 <ant> <Gatak> 2.0 — ух, это далеко в будущем =) 13:29 <@jrandom> (http://www.i2p.net/roadmap#2.0 ;) 13:29 <+postman> эм, мне начинать? 13:29 <aum> всем утро 13:30 <@jrandom> микрофон твой, postman (сорри ;) 13:30 <@jrandom> привет, aum, успел на встречу 13:30 <@jrandom> (d'oh! /me shuts up again) 13:30 <cervantes> Gatek: http://www.i2p.net/roadmap 13:30 <+postman> сначала хотел сказать, что мы уже достигли 300 зарегистрированных аккаунтов на postman.i2p 13:30 <@jrandom> w00t 13:30 <+postman> число писем из/в интернет растет стабильно и еще раз доказывает, что нам надо двигаться дальше 13:31 <cervantes> *вииии* 13:31 <+postman> после разговора с jr несколько недель назад мы договорились выпустить v2mail вместе с I2P 1.0 13:31 <+postman> текущий статус: основанный на Java SMTP-прокси, рассчитанный на запуск на каждом узле, готов 13:31 <@jrandom> отлично! 13:32 <+postman> основанный на Java POP3-прокси готов на 80%, не хватает только движка maildir 13:32 <+postman> будет веб-менеджер, которому еще нужно много твиков (готово на 15%) 13:32 <+postman> межузловое взаимодействие готово на 40% — мы тестировали обмен записями данных через HTTP/XML 13:33 <+postman> кажется, работает довольно хорошо и даже быстро 13:33 <+postman> даже если relay-узел упал/был выключен на несколько дней, он синхронизируется в течение нескольких минут после возвращения онлайн 13:33 <@jrandom> клево 13:33 <+postman> думаю, мы идем по плану 13:34 <+postman> одно стоит отметить 13:34 <bla> postman: Отличная работа! Один вопрос: многие узлы не могут принимать/посылать данные на порту 25 (по крайней мере, напрямую). Владельцы узлов смогут это указать (или это будет автоопределяться)? 13:34 <cervantes> круто 13:34 <+postman> bla: позже 13:34 <+postman> в v2mail будет локально работающий веб-приложение 13:34 <+postman> с его помощью можно управлять локальными прокси И подать заявку на "relayaccount" 13:35 <+postman> этот relayaccount будет использоваться для привязки вашего адреса/домена к relay'ам 13:35 <+postman> relay'и будут синхронизировать информацию автоматически 13:35 <@jrandom> круто 13:35 <+postman> даже такие функции, как addressbook / публичные ключи и прочее, будут работать через LOCAL интерфейс 13:36 <+postman> идея в том, чтобы иметь один централизованный менеджер, где можно заниматься всей своей почтой 13:36 <+postman> релевантные данные передаются на ОДИН из relay'ев, а затем синхронизируются между ними 13:36 <+postman> и этот веб-менеджер будет работать прямо на вашем узле 13:37 <+postman> когда ваш узел онлайн, relay'и доставят письма, стоящие в очереди для вашего destination/domain/address 13:37 <+postman> они будут доставлены в ваш локальный smtp-прокси 13:37 <+postman> вы даже можете триггерить это ETRN :) 13:37 <aum> снова привет 13:37 <aum> я хотел бы поднять вопрос на этой встрече, если можно 13:37 <+postman> на будущее все, пожалуй, :) 13:37 <+postman> . 13:38 <@jrandom> звучит круто, postman 13:38 * postman передает микрофон обратно 13:38 <@jrandom> aum: отлично, будет время в 4) 13:38 <+postman> да, я в восторге :) 13:38 <@jrandom> postman: то есть для обычного пользователя smtp-прокси будет иметь локальный maildir, а pop3-прокси будет читать/и т. п., верно? 13:39 <+postman> да, у smtp-прокси есть MDA 13:39 <+postman> и он будет доставлять почту в локальные maildir'ы 13:39 <+postman> можно даже создавать несколько аккаунтов/пользователей локально 13:39 <cervantes> postman: будут ли relay'и отслеживать ваши квоты и распространять такую информацию между собой? 13:39 <+postman> и маппить на аккаунты вашего домена 13:39 <+postman> cervantes: да, будут 13:39 <septu_ssh> извините, можно вопрос к postman про механизмы оплаты/антиспама в новой модели? 13:40 <+postman> septu_ssh: вы читали какие-либо документы на веб-странице? 13:40 <+postman> cervantes: это не идеально в реальном времени 13:40 <+postman> cervantes: но меня устраивает обмен информацией о квотах раз в несколько минут 13:40 <septu_ssh> postman: в очереди на чтение :/ 13:40 <septu_ssh> но если это задокументировано, то ок 13:40 <cervantes> postman: да, я так и думал 13:41 <+postman> septu_ssh: www.postman.i2p/inout.html 13:41 <+postman> septu_ssh: www.postman.i2p/mailv2.html 13:41 <+postman> cervantes: это не проблема — квота — разумное ограничение 13:41 <cervantes> postman: даже если кто-то сможет отправить nrelays * quota получателей — не страшно 13:41 * septu_ssh — это bungle 13:41 <+postman> cervantes: ага 13:42 <+postman> цель — лишь предотвратить реальное злоупотребление сервисом 13:42 <+postman> в тестах 3 relay'я были очень быстры 13:42 <@jrandom> postman: забыл, будет ли поддержка, чтобы локальный smtp relay говорил напрямую с чужим smtp relay, а не прыгал через ваши узлы? 13:42 <+postman> cervantes: за 10 секунд они синхронизировались :) 13:43 <@jrandom> (или это уже потом) 13:43 <+postman> jrandom: i2p mail relay'и будут управляться несколькими людьми и являются предпочтительными направлениями для маршрутизации почты 13:43 <cervantes> postman: можно ввести экспоненциальную задержку в очереди отправки 13:43 <cervantes> если это станет проблемой 13:43 <+postman> jrandom: так что отправка на другие destinations может быть полезна при определенных обстоятельствах 13:44 <@jrandom> ага, хотя в других — опасна 13:44 <cervantes> то есть чем больше почты ты отправляешь, тем больше время, на которое письмо ставится в очередь... это даст relay'ям время синхронизироваться 13:44 <+postman> jrandom: но если владелец узла раскроет свой IMIO destination, его могут заспамить без контроля :) 13:44 <@jrandom> именно 13:44 <@jrandom> с другой стороны, то же самое, если i2p mail relay'и враждебны 13:45 <+postman> jrandom: верно, это конструкция в стиле WOT (web of trust) 13:45 <@jrandom> </tinFoil> 13:45 <+postman> jrandom: я не могу помешать оператору relay'а выставить квоту 0 для вашего адреса 13:45 <@jrandom> ок, отлично. да, пока не о чем переживать 13:45 <+postman> :) 13:46 <+postman> ок 13:46 <+postman> . 13:46 <@jrandom> ок, спасибо за апдейт. очень интересные штуки 13:46 <@jrandom> ок, переходим к 3) обновления i2p-bt 13:46 <@jrandom> duck: ping 13:46 <@duck> привет 13:47 <@duck> Вчера вышел BitTorrent 4.0.0 13:47 <ant> <dm> звучит по-немецки 13:47 <@duck> мы более-менее ждали его, прежде чем начинать 0.2 13:47 <@duck> написал список задач / todo: http://pastebin.ca/raw/7037 13:47 <@duck> (сорри, мой www сейчас лежит) 13:48 <@jrandom> круто 13:48 <legion> о каких сроках идет речь для 0.2? 13:48 <@duck> цель — 4 недели 13:49 <legion> круто 13:49 <@duck> как видите, RawServer (часть, которая общается с i2p) — самая большая задача 13:50 <@duck> . 13:50 <@duck> небольшой опрос: 13:50 <legion> да, мне это хорошо известно :) 13:50 <@duck> кто планирует создать форк i2p-bt? 13:50 <@jrandom> круто, можно чем-то помочь? 13:50 <@jrandom> хех 13:51 <ant> <dm> я 13:51 * jrandom берет ложку 13:51 <ant> <dm> готов помогать 13:51 <legion> я 13:51 <ant> <dm> я гей 13:51 <legion> Я работаю над форком 13:52 <@duck> хорошо, тогда я знаю, кого не воспринимать всерьез. 13:52 <@duck> правда, это глупо; объединение усилий может продвинуть гораздо дальше 13:53 <@jrandom> или если есть лучшие подходы, вы можете убедить duck'а работать так? 13:53 <named> Я собираюсь написать форк на qbasic, пожалуйста, отнеситесь ко мне серьезно. 13:53 <@duck> Постараюсь сделать процесс более открытым, чтобы другие могли видеть, что планируется и т. п. 13:53 <ant> <dm> твоя открытость нас не убеждает. FORK! FORK! FORK! FORK! 13:53 <@duck> если есть другие предложения 13:54 <ant> * dm поднимает legion на плечи. 13:54 <legion> хм, возможно, это верно, хотя с тем, что я делаю, сомневаюсь, что вы захотите, чтобы я засорял основной процесс разработки i2p-bt ;) 13:54 <ant> <dm> FORK! FORK! FORK! FORK! 13:54 <@jrandom> legion: что ты делаешь такого, что duck не захочет поддерживать? 13:55 <@duck> legion: поздравляю, если загуглить 'i2p bittorrent', то объявление "Windows I2P Bittorrent Version 1.0" — #1 13:55 <@jrandom> блин 13:56 <bla> jrandom: Да? 13:56 <+postman> jrandom: да, они скоро разорвут эту сеть на части :) 13:56 <bla> ;) 13:56 <named> 1.0? Черт, я использую 0.1.8! 13:56 <Ragnarok> ой 13:57 <legion> о боже, правда?! Не могу поверить... это безумие. 13:57 <@duck> в любом случае, думаю, тут больше особо нечего добавить 13:57 <legion> мой релиз 1.0 основан на 0.1.8, если вы на 0.1.8 — вы в порядке. 13:58 <@jrandom> (и релиз 1.0 — это .exe, который никто не проверял, YMMV) 13:58 <legion> Я плохо назвал и пронумеровал его, извините, снова. 13:58 <ant> <dm> 1.0>> 0.1.8 13:58 <ant> <dm> в любой день недели 13:59 <@duck> слегка по теме: 13:59 <@jrandom> ок, что-нибудь еще по 3) i2p-bt, или перейдем к 4) ??? 13:59 <+postman> legion: когда можно будет скачать исходники? 13:59 <frosk> "I2P-BT 0.1.8 работает довольно хорошо и стабильно. Лично я не вижу причин обновляться до I2P-BT 1.0" (увидел на форуме) 13:59 * jrandom вздыхает 13:59 <@duck> в прошлом месяце Bram Cohen читал лекцию о bittorrent в одном университете 14:00 <@duck> довольно интересно: http://netnews.nctu.edu.tw/~gslin/tmp/050216-ee380-100.wmv.torrent 14:00 <@duck> (уроки для больших p2p-программ, плюс объяснение некоторых деталей bittorrent) 14:00 <@duck> . 14:01 <@jrandom> ок 14:01 <@duck> postman: legion выложил немного исходников 14:01 <ant> <dm> он изобретатель BT? 14:01 <@duck> но по словам smeghead это не то же самое, что .exe 14:01 <@jrandom> dm: да 14:01 <legion> Есть developer source, можно скачать с http://legion.i2p/archives/Itorrent_1_x_Developer_Source.zip.bz2 14:02 <+postman> ок, посмотрю 14:02 <ant> <dm> exe — это прямой компил того исходника? 14:03 <legion> хотя на самом деле исходники 1.0 — это просто 0.1.8 с патчем от smeghead, скомпилированные и аккуратно упакованные. 14:04 * cervantes шагает к 4)??? и ждет остальных 14:04 <ant> <dm> вопрос остался без ответа 14:04 <ant> <dm> Legion, приказывали вы или нет, объявить code red??? 14:04 <@jrandom> *кашляк* 14:04 <legion> Давайте вернемся к теме, обсуждение моего bt-клиента переехало в #itorrent 14:05 <@jrandom> ок, 4) ??? 14:05 <@jrandom> есть что еще, что хотите поднять? 14:05 <@jrandom> aum: у тебя было что-то? 14:06 <ant> <dm> stasher вернулся? 14:06 <legion> Я вижу странное поведение с 0.5.0.2 при периодах сильного трафика... 14:06 <aum> да 14:06 <aum> я хотел бы поднять вопрос автоматизированного создания/управления tunnel 14:07 <ant> <dm> продолжай 14:07 <+detonate> в systray-штучке под Windows только что заметил null pointer exception 14:07 <aum> круто, что веб-консоль теперь позволяет людям вручную создавать/удалять/управлять tunnels 14:07 <@jrandom> detonate: можешь кинуть это в bugzilla? 14:07 <aum> но я также убежден, что всегда должен быть надежный и удобный способ для программ тоже управлять tunnels 14:08 <@jrandom> aum: никто не возражает. это нужно, и это будет. только не сейчас. 14:08 <ant> <dm> разве это нельзя делать через SAM? 14:08 <aum> заметил по своему недавнему возвращению в i2p, что библиотека pysam больше не работает 14:08 <septu_ssh> у меня тоже быстрый вопрос после aum 14:08 <aum> что разочаровало 14:08 <@jrandom> протокол SAM работает, pysam — нет 14:08 <Ragnarok> он вообще когда-нибудь работал? 14:09 <aum> да 14:09 <aum> pysam раньше работал отлично 14:09 <legion> В такие периоды мой узел участвует в 1000+ tunnels, и задержки по несколько секунд. 14:09 <@jrandom> legion: ага, число tunnels из-за старых билдов 14:09 <cervantes> ah mymodesty 14:09 <cervantes> eerm pymodesty 14:09 <aum> сейчас пишу модуль 'i2ptunnel.py', в котором определены классы для простого управления tunnel 14:10 <legion> то есть если бы старые билды не подключались, сеть работала бы гораздо плавнее? 14:10 <@jrandom> ок, не знаю, правильное ли это долгосрочное решение, но если сейчас это закроет дыру для тебя — круто 14:10 <@jrandom> legion: эти tunnels — не проблема 14:11 <aum> ну, интерфейсы классов могут остаться, хотя механизм под капотом изменится 14:11 <@jrandom> ок 14:11 <legion> разве нет? 14:12 <legion> Когда tunnels немного, лагов и задержек почти нет... 14:12 <cervantes> legion: извини, aum пока поднимает вопросы, подожди минутку 14:12 <legion> просто кажется странным. 14:13 <legion> ок 14:13 <@jrandom> я лишь переживаю, что нужно учитывать, что раньше работало — веб-конфиг работает и поддерживается, потому что все им пользуются. возможно, лучше сначала заставить работать твое приложение с ручным созданием tunnel — так будет эффективнее? 14:13 <@jrandom> чтобы всегда было что-то, что использует i2ptunnel.py, и нагружает его 14:13 <aum> похоже, мы зациклились 14:13 <+detonate> jrandom: конечно 14:14 <ant> <dm> давайте тогда дальше 14:14 <aum> я не хочу тратить время на разработку приложения, пока у меня нет API управления tunnel, на который можно опираться 14:14 <septu_ssh> \o. - хочу поднять вопрос 14:14 <cervantes> реалистично, я не могу представить, что интерфейс управления tunnel будет переделан в ближайшие пару месяцев... 14:14 <@jrandom> но ты же понимаешь, что мы можем добавить его тривиально 14:14 <cervantes> так что временное решение уместно 14:15 <named_> Разве веб-конфиг не может иметь какой-то API, которым программа aum будет управлять? 14:15 <@jrandom> named_: да 14:16 <@jrandom> добавить что-то для безопасного контроля через URLs — тривиально, но это имеет смысл только если есть что-то, чему это нужно 14:16 <@jrandom> иначе оно просто будет простаивать 14:16 <aum> named_: это было бы неплохо и может сработать, если в конфиге будет захардкоженный пароль, который клиентские программы должны POST'ить вместе с полями управления tunnel 14:16 <cervantes> лично я бы хотел полностью переделать всю систему tunnel; если включить интерфейс управления tunnel с самого начала, не придется переживать о допзатратах на поддержку отдельного интерфейса 14:17 <@jrandom> ага, proxy действительно требуют кучи работы, от которой я уклоняюсь как могу :) 14:17 <aum> SAM хорош для одних ситуаций, плох для других 14:17 <cervantes> но это чуть позже... 14:17 <fedo> ( 14:18 <@jrandom> aum: но как временную меру, не мог бы ты использовать один из трех доступных методов? 14:18 <cervantes> то есть если сам веб-интерфейс использует API, то нет накладных расходов на поддержку 14:18 <@jrandom> верно. веб-интерфейс использует TunnelControllerGroup 14:19 <aum> использование SAM становится сложным, когда хочется использовать существующие либы, сильно завязанные на стандартные TCP sockets 14:19 <aum> jrandom: I2PTunnel CLI не работает для открытия server tunnels, поэтому я сейчас пишу код с использованием TunnelControllerGroup 14:19 <@jrandom> aum: существующие либы нужно тщательно аудитить. например, сам утилита gzip раскрывает чувствительные данные 14:19 <aum> пишу код прямо сейчас 14:21 <@jrandom> я уверен, что CLI работает для server tunnels, но использовать TunnelControllerGroup предпочтительнее, если тебе так нужно 14:21 <@jrandom> ок, у кого-нибудь есть еще что-то для обсуждения? 14:22 <septu_ssh> Мой вопрос касается распределенной версии hosts.txt: сейчас таблица DHT используется для routerInfo, нельзя ли расширить это до распределенной версии DNS? DHT для DNS могла бы содержать отображения от www.bla.i2p к eepsite SHA, а записи подписывались бы "I2P registrar"... комментарии? возражения? 14:22 <mancom> вопрос по дорожной карте: 0.6 все еще запланирован на апрель? 14:22 <@jrandom> septu_ssh: нероутинговые данные попадут в netDb только через мой труп ;) 14:23 <septu_ssh> jrandom: не та же БД 14:23 <septu_ssh> другая распределенная БД 14:23 <aum> jrandom: видел мой багрепорт? команда CLI 'server' /не работает/ 14:23 <maestro^> septu_ssh: нет никакого i2p registrar 14:23 <@jrandom> septu_ssh: у нейминга много опасных аспектов и несколько ключевых компромиссов. видел обсуждение нейминга на ugha.i2p? 14:24 <@jrandom> septu_ssh: ну, DHT поверх I2P вполне может использоваться для распространения записей, но такие имена не будут безопасны, если рассматривать их как глобальные записи 14:26 <@jrandom> aum: я пользовался этим ежедневно до пары недель назад, видел мой ответ? 14:26 <@jrandom> maestro^: это план 14:26 <@jrandom> эм, mancom: 14:26 <cervantes> aum: у меня есть ответ на то письмо в i2plist от jr, он до тебя не дошел или проблема сохраняется? 14:26 <septu_ssh> единственная причина, по которой я предлагаю "registrar", — иначе могут происходить коллизии 14:26 <@jrandom> septu_ssh: живите с коллизиями :) 14:26 <@jrandom> глобально уникальный, читаемый человеком, распределенный и безопасный нейминг не существует 14:27 <septu_ssh> это также может случиться в hosts.txt, если его править вручную, но проблема остается той же 14:27 <@jrandom> выбросьте первый параметр, и все ок 14:27 <aum> jrandom: видел твой ответ — и у меня /есть/ streaming.jar в моем cp 14:27 <septu_ssh> postman управляет центральным узлом для почты, так что в сети есть элемент доверия; неужели никто не будет доверять регистратору управлять namespace? 14:27 <@jrandom> ок, круто, и все равно возвращается тот stacktrace, aum? 14:28 <aum> да 14:28 <@jrandom> septu_ssh: postman действует как центральный элемент только для outproxy/inproxy postman'а 14:28 * Ragnarok действительно надо наконец написать документ по addressbook... 14:28 <aum> это когда я вручную запускаю cli, делаю genkeys, затем делаю 'server', используя privkeyfile, сгенерированный genkeys 14:28 <@jrandom> septu_ssh: никто не будет доверять кому-то управлять пространством имен. цензура == давление на этого регистратора. 14:28 <maestro^> каждый сам себе регистратор 14:29 <maestro^> вы доверяете друзьям, а они — вам 14:29 <aum> черт, я подцепил старый classpath 14:29 * aum тестирует снова 14:30 <ant> <dm> ок, я буду регистратором. 14:31 <ant> <dm> Я буду настолько беспристрастным, насколько смогу... идет? 14:31 <septu_ssh> хмм, ладно, возвращаюсь к чертежной доске... 14:31 <@jrandom> septu_ssh: хорошее место для чтения — http://zooko.com/distnames.html :) 14:32 <@jrandom> все этого хотят, но то, что они хотят, небезопасно. у нас есть решение, которое безопасно, но мы отказываемся от глобальной уникальности 14:33 <septu_ssh> хмм, ок 14:33 <@jrandom> ок, у кого-нибудь есть еще что-то для обсуждения на встрече? 14:33 <cervantes> septu_ssh: http://forum.i2p.net/viewtopic.php?t=134 14:33 <aum> jrandom — ок, cli 'server' теперь работает, но я так и не получил 'job number' для tunnel 14:34 <@jrandom> хм, да, он работает бесконечно 14:34 <aum> о, надо сделать 'list', чтобы получить номер задания 14:36 <@jrandom> ок, если больше ничего... 14:36 * jrandom заканчивает 14:36 * jrandom *baf* закрывает встречу