Встреча разработчиков I2P - 17 января 2006

15:40 <jrandom> 0) привет 15:40 <jrandom> 1) Статус сети и 0.6.1.9 15:40 <jrandom> 2) Криптография создания tunnel 15:40 <jrandom> 3) Блоги Syndie 15:40 <jrandom> 4) ??? 15:40 <jrandom> 0) привет 15:40 * jrandom машет 15:40 <jrandom> еженедельные заметки о статусе опубликованы @ http://dev.i2p.net/pipermail/i2p/2006-January/001251.html 15:41 <@cervantes> пффф, хорошо, что i2p надёжнее, чем NASA 15:41 <jrandom> хех 15:41 <tethra> ха-ха 15:41 <jrandom> (хотя я опоздал на 20 минут... ;) 15:41 <jrandom> в любом случае, давайте перейдём к 1) Статус сети и 0.6.1.9 15:42 <wmpq> NSA или NASA, не так уж и отличаются, да? 15:42 <@cervantes> Я сказал I2P, а не jrandom ;-) 15:42 <jrandom> верно, cervantes ;) 15:42 <tethra> не глупи, jrandom и есть i2p! ;D 15:42 <@cervantes> о, я думал, это способ мышления 15:42 <wmpq> [redact] 15:43 <jrandom> хех, ну ладно, 0.6.1.9 уже вышел, 70% сети обновились (спасибо всем) 15:43 <Pseudonym> ммм, вкусный новый релиз 15:44 <+zzz> доля успешных построений client tunnel остаётся <30% 15:44 <jrandom> Я не слышал много сообщений о существенном росте сквозной пропускной способности, хотя некоторые routers более чем насыщают линии T1 15:44 <+zzz> снизилось с ~40% 15:44 <+Complication> Пропускная способность выглядит нормально, чуть выше, чем на последнем CVS перед релизом. Число пиров выглядит немного выше. 15:45 <jrandom> хмм, да, я не особо переживаю из‑за этого, zzz, так как всё это будет полностью переработано для 0.6.2 15:45 <+zzz> средняя скорость выросла с ~12K до ~20K 15:45 <jrandom> 0.6.1.9 не должен выбирать пиров, более склонных соглашаться (то есть с высокой ёмкостью), а должен вместо этого фокусироваться на тех, у кого выше пропускная способность 15:46 <+Complication> Процент ретрансляций (было отмечено 7% в ночь релиза) снизился до шести с чем‑то 15:46 <jrandom> ага, при routers, выдающих 1–300 КБ/с, будет перекос 15:46 <jrandom> хмм, это довольно бешеный показатель, Complication, я видел лишь 2–3% 15:46 <jrandom> (но я не сомневаюсь в твоих наблюдениях) 15:47 <+Complication> Я практически полностью упираюсь в исходящий канал 15:47 <+Complication> (то есть именно в предел пропускной способности линии) 15:47 <jrandom> ага, это бы объяснило 15:47 <+zzz> всё ещё получаю NULL перед GET, что приводит к 405 bad method, возможно, частота снижается, трудно сказать наверняка 15:48 <jrandom> да, zzz, в библиотеке потоковой передачи есть над чем поработать, но, вероятно, я займусь этим после переработки tunnel в 0.6.2 15:48 <jrandom> (но если кто‑то хочет покопаться раньше — это было бы круто, конечно) 15:49 <jrandom> Complication: если ты снизишь ограничитель ширины канала до примерно 70% пропускной способности линии, вернётся ли частота ошибок к разумному значению? 15:49 <+zzz> я всё ещё думаю, что это что‑то, попавшее в код прямо перед новым годом, так что лучше посмотреть до того, как эти недавние изменения забудутся :) 15:50 <+zzz> Впервые заметил 29 декабря 15:50 <jrandom> да, zzz, так и есть. скорее всего связано с тем, как мы теперь учитываем таймауты. 15:51 <+Complication> jrandom: я, собственно, сейчас это и пробую :) 15:51 <+Complication> Настроил за пару секунд до твоего вопроса, но, думаю, быстро не узнаю 15:51 <jrandom> но там нужно существенно прибраться, и важнее внедрить новый код создания tunnel (который заметно улучшит процент успешной постройки tunnel, а также добавит целый набор улучшений анонимности) 15:51 <jrandom> круто, Complication, да, дай 3–6 часов 15:51 <jrandom> (чтобы очистились старые значения/соединения) 15:52 <+zzz> ~ 1% – 3% GET'ов сейчас повреждены 15:54 <jrandom> так что ты предлагаешь откатить изменения в библиотеке потоковой передачи (чтобы i2psnark ушёл в OOM (исчерпание памяти) у всех пользователей за 12–48 часов) и отложить дальнейшую переработку библиотеки потоковой передачи до работ по tunnel в 0.6.2, или отложить работы по tunnel в 0.6.2 на неделю‑две, пока будем перебирать библиотеку потоковой передачи? 15:55 <+zzz> точно не откатывать 15:56 <+zzz> решать тебе 15:56 <+Complication> Это довольно коварный баг, могу лишь сказать 15:58 <jrandom> есть и другие баги в библиотеке потоковой передачи, так что если я уже закатаю рукава, мне хотелось бы разобраться со всеми сразу (так как оставшиеся баги неочевидны). 15:59 <jrandom> с другой стороны, если сперва заняться tunnel, получим существенное сокращение использования полосы, рост процента успешных построений, лучшую анонимность и улучшенную возможность мониторить балансировку нагрузки на живой сети 15:59 <Pseudonym> если при серфинге это всего 1–3% неудач, я бы сказал, что может подождать, но это лишь моё мнение. 16:00 <jrandom> я склоняюсь сначала сделать работу по tunnel, так как после развёртывания мы сможем пассивно мониторить сеть, активно перерабатывая библиотеку потоковой передачи 16:01 <jrandom> (я бы также хотел сделать GUI для редактирования/публикации в Syndie, но это может подождать до тех пор, пока оба эти пункта не будут решены ;) 16:01 <+Complication> Тут тоже примерно такая частота 16:02 <+Complication> (на моём eepsite) 16:04 <jrandom> Ок, было бы здорово, если б вы присматривали, не меняются ли эти показатели, а пока я продолжу с переработкой tunnel, после чего возьмусь за переработку библиотеки потоковой передачи (и то и другое будет готово до 0.6.2) 16:05 <jrandom> (или, если кто‑то хочет поковырять библиотеку потоковой передачи [или посмотреть, нет ли странного взаимодействия с i2ptunnel], дайте знать!) 16:06 <+Complication> jrandom: из любопытства, можно ли исключить i2ptunnel с тестовым приложением? 16:07 <+Complication> например, если что‑то вроде примера от jnymo *тоже* получало бы null, это сняло бы i2ptunnel со списка подозреваемых причин? 16:07 <jrandom> можно, конечно, прицепить тонкую (внутри одной VM) реализацию I2PSocket, чтобы это сделать 16:07 <+Complication> Поскольку, если правильно помню, тот пример использовал библиотеку потоковой передачи напрямую... 16:08 <+Complication> (или почти напрямую) 16:08 <jrandom> ага, конечно, если что‑то, использующее библиотеку потоковой передачи, может воспроизвести это, i2ptunnel будет оправдан 16:10 <+Complication> Хм, если никто не опередит (я попробую сперва закончить с этой штукой webcache), могу попробовать эмулировать HTTP чем‑то таким... 16:10 <jrandom> круть, спасибо, Complication 16:10 <jrandom> ок, что‑нибудь ещё по 1) Статус сети и 0.6.1.9? 16:11 <jrandom> если нет, давайте перейдём к 2) Криптография создания tunnel 16:11 <+Complication> Неа, это может ни к чему не привести или я застопорюсь на полпути... но возможность меня интригует 16:11 <jrandom> ага, определённо стоит исследовать, Complication 16:12 <jrandom> (и исследования ценны даже без положительных результатов :) 16:12 * cervantes замечает исключение «moo» в изменениях исходников, ведущих к новому году... может, дело в этом? :) 16:13 <jrandom> ок, есть новая спецификация криптографии создания tunnel, ссылка есть в письме, основана на обсуждении, которое toad, Michael и я вели в списке рассылки прошлым октябрём 16:14 <jrandom> гляньте и скажите своё мнение — на живой сети это ещё не скоро будет развернуто, так как сперва нужно внедрить другие вещи, но это грядёт 16:14 <+Complication> «moo» — зарезервированное слово в Java? ;P 16:14 <+zzz> по пункту 2) помогу просмотреть ссылки в статусном письме 16:14 <+Complication> По теме tunnel crypto, не возражаешь проверить, прилична ли такая переформулировка — хочу убедиться, что правильно понял... 16:14 <jrandom> спасибо, zzz 16:15 <+Complication> «Каждый переход шифрует все записи своим reply key, который он расшифровал из своей записи, используя свой закрытый ключ ElGamal, и, шифруя таким образом, убирает один слой дешифрования (или, скорее, шифрования), сделанного владельцем tunnel, в результате чего запись следующего участника становится читаемой закрытым ключом ElGamal следующего участника?» 16:15 <jrandom> Complication: да 16:15 <+Complication> Или моя переформулировка просто неверна? 16:16 <+fox> <jme___> и слишком сложная, если можно 16:16 <jrandom> кажется верно, но да, слишком много придаточных :) 16:16 <+Complication> Не придумал лучшего способа это визуализировать. И так было непросто. :P 16:16 <jrandom> (или, jme___, ты говоришь, что алгоритм слишком сложен?) 16:17 <+fox> <jme___> нет, я попытался быстро прочитать док и сдался — слишком много требует предварительных знаний 16:17 <+fox> <jme___> с другой стороны, я особо и не пытался :) дела 16:17 <jrandom> Complication: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/java/src/net/i2p/router/tunnel/BuildMessageProcessor.java?rev=HEAD 16:18 <+fox> <jme___> это peer review — формальность или ты действительно переживаешь/не уверен? 16:19 <+Complication> Всегда полезно знать, что делает нижележащий механизм... 16:19 <jrandom> Я уверен, что оно делает то, что я задумал, но искренне заинтересован, если кто‑то увидит проблему 16:19 <+fox> <jme___> если второе — могу выделить время, но мои знания устарели и не на кончиках пальцев 16:20 <+fox> <jme___> если нет — доверяю :) 16:20 <jrandom> в разделе примечаний есть некоторые вопросы — http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.notes 16:22 <jrandom> не спешим, вероятно, пройдёт неделя‑две, прежде чем эта новая криптография будет реально использоваться в router 16:22 <@cervantes> jrandom: по ним — будет ли большой удар по производительности при добавлении случайной задержки между переходами? 16:22 <@cervantes> кажется самым разумным вариантом против тайминговых атак 16:23 <jrandom> это создание tunnel, так что задержка не повредит, хотя при катастрофических сбоях может привести к преждевременному истечению lease set 16:25 <jrandom> ну, я не уверен, насколько эффективны будут эти задержки. возможно, они существенно помогут, а возможно, и нет. живые tunnel, однако, могут просто использовать blending для выявления сговаривающихся пиров в этом tunnel, так что, возможно, это не важно 16:25 <+fox> <jme___> ок, перечитываю 16:27 <jrandom> спасибо. ок, не спешим, но если/когда у кого‑то будут мысли, кидайте их мне (или в список, или в свой блог и т.п.) 16:27 <jrandom> ок, что‑нибудь ещё по пункту 2, или двинемся к 3) Блоги Syndie? 16:29 <jrandom> (считайте, что перешли) 16:29 <jrandom> ок, новые прикольные блоговые штуки в syndie, копайтесь ;) 16:29 <@cervantes> оч. круто 16:30 <jrandom> группы слева могут содержать ссылки на произвольные URL, а также ссылки на блоги, посты внутри блогов или вложения к постам внутри блогов 16:30 <jrandom> возможна целая куча улучшений, например добавление оформления постов по блогам или тегам, иконок и т.д. если кто‑то хочет в это вкопаться — было бы круто (и эффект будет очень заметен :) 16:31 <@cervantes> кстати, внешним ссылкам, заданным в комментариях, тоже стоит проставлять атрибут title на целевой URL (как у тебя в левом блоке) 16:31 <@cervantes> комментарии/посты 16:32 <jrandom> ага, хорошая идея 16:33 <jrandom> (net.i2p.syndie.sml.BlogPostInfoRenderer, метод renderLinks(...) :) 16:34 <@cervantes> *что-то записывает* 16:35 <jrandom> чего ещё не хватает блогам syndie, чтобы предлагать функциональную альтернативу информационным eepsites? очевидно, syndie — это статический контент, так что не всё возможно, но публиковать контент и давать людям комментировать можно 16:36 <jrandom> есть какие‑то конкретные кастомизации, которые вы хотите сделать? если да — дайте знать 16:37 <DoubtfulSalmon> jrandom: обновление существующего контента скриптом? 16:37 <@cervantes> архив по датам 16:37 <jrandom> DoubtfulSalmon: скриптом? 16:37 <jrandom> cervantes: ага, типа маленького виджета‑календаря вместо ссылок «ещё 5 старых записей»? 16:38 <@cervantes> угу 16:38 <DoubtfulSalmon> jrandom: скажем, я хочу, чтобы этот файл/текст заменил тот файл/текст. Как мне это сделать? 16:38 <jrandom> ок, круто, да, должно быть очень просто (если кто‑то набросает HTML :) 16:38 <@cervantes> или проще — «показать посты за прошлый месяц» 16:39 <@cervantes> jrandom: тебе нужна просто таблица 7x6 с цифрами ;-) 16:40 <jrandom> DoubtfulSalmon: изменение опубликованного контента — интересное направление. повсеместно это не всегда будет работать, так как придётся действовать как usenet control messages (отменяя старый пост и т.п.) 16:40 <jrandom> DoubtfulSalmon: с другой стороны, можно просто опубликовать новый файл/запись и поменять ссылки на левой панели так, чтобы они указывали на новый файл/запись 16:40 <jrandom> (таким образом старый контент остаётся, но людей направляет к новому) 16:41 <DoubtfulSalmon> jrandom: да, нормально, если старый контент останется, главное, чтобы у всех ссылки указывали на новый контент, без необходимости менять их контент. 16:41 <jrandom> построить из этого полноценную вики, по сути публикуя диффы, а syndie будет их рендерить — возможно, но может быть избыточно 16:41 <jrandom> хм, ок, понимаю тебя 16:42 <jrandom> то есть ты хочешь возможность иметь перенаправляемые ссылки, а не существующие ссылки на точные версии контента 16:43 <jrandom> возможно, это можно сделать, ссылаясь на закладку блога, а точную версию находить, загрузив текущие закладки этого блога и посмотрев, куда она указывает 16:44 <jrandom> с другой стороны, новую версию можно пометить как ответ на старый пост, чтобы при переходе по ссылке можно было перейти к ответу, который заменяет контент 16:44 <jrandom> (хотя это, наверное, не столь бесшовно) 16:44 <DoubtfulSalmon> да: скажем, я хочу иметь ссылку на текущий радарный снимок, или что‑то, что обновляется каждые 10 минут. Ок, если контент не разлетается по всей сети, но если кто‑то ссылается на мою страницу, пользователь должен видеть текущую картинку. 16:45 <jrandom> ну, это зависит от того, что они хотят — ссылаться на изображение таким, каким оно было на момент упоминания, или на сервис, который отрисовывает изображение при просмотре читателем 16:45 <+Complication> cervantes: странность дня :D Последний пост в: http://forum.i2p/viewtopic.php?t=1199&start=15 16:46 <+Complication> Похоже на очередного нашего роботизированного повелителя :P 16:46 <jrandom> но идея поддерживать обе концепции хорошая, и не думаю, что это будет сложно 16:46 <@cervantes> спс 16:46 <jrandom> хотя для этого нужен небольшой апдейт SML (напр. [blog bloghash="ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=" bookmark="radar.webp"]) 16:47 * cervantes усилит защиту форума, если их станет много 16:47 <@cervantes> (уже знаю, как остановить этого) 16:47 <DoubtfulSalmon> jrandom: они должны иметь возможность ссылаться как на статическую версию (если синдикатор не удалил контент), так и на общий URL, указывающий на самую свежую версию 16:47 <jrandom> (который посмотрит на текущий мета‑пост ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c= на предмет закладок и возьмёт точный URI из той, что называется «radar.webp») 16:48 <DoubtfulSalmon> jrandom: можно ли сейчас сделать это чем‑то вроде: «Показать самую последнюю запись с тегом <weird string>» 16:48 <jrandom> ах да, верно — можно 16:49 <jrandom> это даже можно ограничить до «View most recent post by $author with tag $tag» 16:49 <jrandom> (чтобы другие не могли подделать) 16:49 <DoubtfulSalmon> тогда, может, сделать какой‑то UI, чтобы пользователю не видеть странные теги и всё такое 16:50 <jrandom> там выше есть пример того, как это выглядит, хотя URI у меня под рукой нет... но да, это ссылка вокруг связанного текста 16:50 <DoubtfulSalmon> Полагаю, всю эту информацию можно передать в URL. 16:51 <jrandom> но исходный SML писать точно сложно, потому GUI для создания SML был бы полезен 16:51 <jrandom> это атрибуты на тегах SML, а не URL 16:52 <@cervantes> и GUI для SML без JavaScript будет непростым 16:52 <DoubtfulSalmon> но можно же добавить в закладки результат поиска, верно? 16:52 <jrandom> что такое результат поиска? 16:52 <jrandom> и что ты имеешь в виду под закладкой? 16:52 <@cervantes> (или расширение браузера ;-) 16:52 <jrandom> о, закладки на стороне браузера, да 16:52 <+Complication> Результат фильтра? 16:53 <jrandom> но этими закладками обычно нельзя делиться 16:53 <DoubtfulSalmon> ээ: «получить самую последнюю 1 запись от X с тегом Y» 16:53 <jrandom> (на самом деле большинством — можно, но это не универсально, поскольку это URL, а не URI)) 16:53 <DoubtfulSalmon> да, было бы хорошо, если бы другие блоги тоже могли на них ссылаться 16:54 <jrandom> DoubtfulSalmon: могут, через SML 16:54 <jrandom> [blog tag="Y" bloghash="X"] 16:54 <DoubtfulSalmon> о, здорово 16:55 <jrandom> cervantes: javascript, или xul, или java, или какое‑то другое клиентское приложение под ОС 16:57 <@cervantes> ага, то есть тебя не смущает зависимость от скриптов или плагинов 16:57 <jrandom> (когда наш сайт будет обновлён к 0.6.2, у syndie точно появится сайт, объясняющий, что это вообще за syndie и что она умеет почти всё, кроме мытья посуды ;) 16:57 <@cervantes> (если всё будет корректно деградировать) 16:57 <jrandom> cervantes: syndie должна работать с lynx, но места для «богатых» клиентов много 16:58 <jrandom> (s/function/functional/) 16:58 <@cervantes> верно... так что пользователи lynx получат памятку по SML, но не больше 16:58 <jrandom> ага, как сейчас 16:58 <jrandom> хотя, возможно, упрощённый sml, не знаю. 17:01 <+Complication> jrandom: как думаешь, хотя бы отдалённо возможно... что баг с null может быть связан с gzip‑сжатием? 17:01 <+Complication> Думал, как отключить gzipping для моего eepsite tunnel... 17:01 <+Complication> Или это совсем невероятно? 17:01 <@cervantes> прямо перед новым годом в i2ptunnel добавили кое‑что по http‑компрессору 17:03 <jrandom> ага, может — можно отключить на клиентской стороне через i2ptunnel.gzip=false (на /configadvanced.jsp). сейчас, думаю, в i2ptunnelhttpserver отключить нельзя 17:03 <+zzz> это на стороне запроса, где нет компрессии 17:03 <+zzz> сервер не будет сжимать, если у клиента выставлено false 17:03 <+Complication> zzz: о, точно, я забыл об этом 17:04 <jrandom> (но без особых усилий можно добавить это в I2PTunnelHTTPServer [строка 310 и т.д.]) 17:04 * Complication глуп и извиняется за это 17:04 <@cervantes> (или можно использовать обычный tunnel) 17:04 <+Complication> Ага, спасибо... 17:05 <jrandom> хмм, хотя к моменту, когда i2ptunnelhttpserver получает GET, null уже там 17:05 <+zzz> да, я перевёл orion обратно на HTTP tunnel, что сильно помогло со временем загрузки его страниц, так как теперь снова сжимается 17:05 <+Complication> Я как‑то совсем забыл, что gzipping начинается, когда клиент и сервер договорились это делать 17:05 <jrandom> значит, может быть на клиентской стороне, но точно не на серверной 17:05 <jrandom> да, zzz, сейчас нереально быстро :) 17:05 <+zzz> это на стороне _запроса_, а не _ответа_ — может быть как на стороне клиента, так и сервера 17:06 <jrandom> верно 17:09 <jrandom> ок, у кого‑нибудь ещё что‑то по 3) Блоги Syndie? 17:09 <jrandom> если нет, перейдём к 4) ??? 17:09 <jrandom> есть ли ещё что‑то для обсуждения на встрече? 17:10 <cat-a-puss> Complication: gzip‑поток Java + I2P tunnels. Не работает, и это баг sun 17:10 <jrandom> хмм, cat-a-puss? правда? 17:10 <+zzz> Обновление по HTTP persistent connections: клиентская сторона в основном готова, серверная сторона идёт хорошими темпами, много работы по «неубиваемости» и тестам, оценка завершения 2–4 недели 17:10 <jrandom> класс, zzz! 17:11 <cat-a-puss> jrandom: да, я говорил с тобой об этом давно, могу, наверное, найти длинное объяснение почему, но, вероятно, лучше просто где‑то задокументировать, так как нет смысла это делать. 17:12 <jrandom> хмм, я выпал из контекста, что именно не работает? в чём баг sun? 17:14 <dust> у меня странные логи вроде этого: 21:21:59.816 WARN [%d0%a2%d1%4f] net.i2p.util.EepGet : ERR: status <html> 17:14 <jrandom> хмм, интересно 17:15 <jrandom> какой трекер? 17:15 <cat-a-puss> jrandom: Насколько помню, sun использует zip без заголовка и какое‑то «магическое число», чтобы определить, что это zip‑поток. Но число, как оказалось, отрицательное, так что если ты по какой‑то причине создаёшь zip‑поток внутри zip‑потока, он читает данные из потока как последовательность беззнаковых байтов, и в итоге магическое число преобразуется в какое‑то другое положительное число. (Вероятно, я упускаю детали, но суть такая) 17:16 <dust> например, OSDevWithCVS_3E.pdf.torrent 17:17 <dust> d8:announce540:http://YRgrgTLGnbTq2aZOZDJQ... 17:17 <jrandom> хмм, я об этом ничего не знаю и не уверен, как это повлияло бы на gzip‑поток поверх i2ptunnel (если бы /повлияло/, всё бы падало, потому что мы всё gzip'им) 17:19 <jrandom> ок, понятно, dust, значит, трекер postman'а. хмм, ты на 0.6.1.9, dust? 17:20 <cat-a-puss> jrandom: да, с тех пор прошло почти год, как у меня была эта проблема, так что помню не очень, и не знаю, исправлено ли это в 1.5, но я изрядно намучился, пытаясь понять, почему все обычные типы потоков работали, а как только я оборачивал их в сжатый поток — всё падало. 17:20 <dust> да 17:20 <jrandom> cat-a-puss: мы сильно поменяли всё, что касается сжатия поверх i2p, за последний год ;) 17:21 <jrandom> (и лично я 1.5 не использую) 17:21 <jrandom> но мы делаем своё zip‑кодирование явно, вместо использования их потоков из пакета (но по причинам анонимности/эффективности, а не совместимости) 17:22 <@cervantes> zzz: в каком именно месте запроса возникает null? сразу после GET? 17:22 <+Complication> До него, если я помню 17:23 <+fox> <lordalbert> hi 17:23 <+Complication> К слову: Celeron 300 показывает вдвое меньший процент ретрансляций, чем Sempron 17:23 <jrandom> привет, lordalbert 17:23 <jrandom> круто, Complication, 2–3% — приемлемо (хотя я бы предпочёл ниже, конечно) 17:23 <@cervantes> было бы интересно настрелять кучу запросов HEAD или что‑то такое... 17:24 <jrandom> да, набор локальных тестов был бы отличен, хотя, если правильно помню, Complication уже пробовал это какое‑то время назад — без ошибок 17:24 <+fox> <lordalbert> can anyone make a anonymous tracker? I try it but i dont' understand how use the tunnel 17:24 <+Complication> cervantes: я как‑то пытался спровоцировать это, сделав рекурсивный wget между моими 2 узлами 16:24 <+Complication> Устал раньше, чем это проявилось 17:25 <@cervantes> хе 17:26 <+fox> <lordalbert> 'lo b0unc3 ;) 17:26 <+fox> <b0unc3> lordalbert, :D 17:26 <+Complication> lordalbert: по какой части тебе нужен совет? 17:27 <+Complication> По настройке трекеров, увы, не знаю. 17:27 <+Complication> По I2PTunnel — могу попробовать объяснить... 17:27 <+fox> <lordalbert> I have installed BTtracker, and it work perfectly 17:28 <+Complication> Также стоит отметить, что для того, чтобы трекер оставался анонимным, ему, скорее всего, нужна очень аккуратная конфигурация 17:28 <+fox> <lordalbert> now, i'd like anonimise it 17:28 <+fox> <lordalbert> so 17:28 <jrandom> Уверен, мы сможем помочь после встречи. не стоит использовать обычные трекеры, нужен тот, что сделан под анонимность 17:28 <+fox> <lordalbert> i have just made a i2ptunnel 17:29 <jrandom> (например, модификация bytemonsoon, которую можно найти на любом из i2p‑трекеров, или в cvs) 17:29 <+fox> <lordalbert> now, i'd like to know how use this tunnel. I have made a tunnel yet 17:29 <jrandom> ок, у кого‑нибудь ещё что‑то для встречи? 17:30 <jrandom> lordalbert: http://localhost:7657/i2ptunnel/ позволит создать «http server tunnel», указывающий на твой веб‑сервер/трекер, но твой трекер не будет работать, если он не модифицирован для анонимного использования 17:30 <+fox> <lordalbert> jrandom, what tracker i must use? 17:31 <+Complication> postman использует модифицированную версию ByteMonsoon, думаю 17:32 <jrandom> i2p-bytemonsoon был модифицирован под анонимное использование — есть zip @ http://i2p-bt.postman.i2p/, а ещё есть cvs на http://dev.i2p.net/cgi-bin/cvsweb.cgi/bytemonsoon/ но я сам особо в этом не разбираюсь 17:32 <+fox> <lordalbert> isn't bytemonsoon obsolete? 17:32 <jrandom> если работает — не устарел. работает 17:33 <+fox> <lordalbert> ок XD 17:33 <jrandom> трекеров много, и если какой‑нибудь разработчик хочет модифицировать свой, чтобы он работал безопасно и анонимно — это было бы отлично 17:33 <+Complication> Может и староват... но точно работает с destkeys вместо IP... 17:33 <+Complication> Про безопасность и отсутствие утечек сказать не могу 17:34 <jrandom> (его модифицировали duck и др. под анонимность и безопасность) 17:34 <+Complication> Но он уже давно работает и, похоже, справляется... 17:35 <jrandom> ок, если для встречи больше ничего нет... 17:36 * jrandom сворачивает 17:36 * jrandom *бах* закрывает встречу