Встреча разработчиков I2P - 18 октября 2005 года

16:10 <jrandom> 0) привет 16:10 <jrandom> 1) 0.6.1.3 16:10 <jrandom> 2) Freenet, I2P и даркнеты (о боже) 16:10 <jrandom> 3) Атаки на начальную фазу создания tunnel 16:10 <jrandom> 4) I2Phex 16:10 <jrandom> 5) Syndie/Sucker 16:10 <jrandom> 6) ??? 16:10 <jrandom> 0) привет 16:10 * jrandom машет рукой 16:10 <jrandom> еженедельные заметки о статусе опубликованы по адресу http://dev.i2p.net/pipermail/i2p/2005-October/001017.html 16:10 <dust> ура, теперь работает. спасибо, Gregor 16:10 <cervantes> привет 16:11 <+fox> <blx> привет 16:11 <jrandom> ок, переходим к 1) 0.6.1.3 16:11 <jrandom> вы все обновились довольно быстро, спасибо! 16:12 <jrandom> всё выглядит в приличном состоянии, но мне особо нечего добавить сверх того, что в заметках о статусе 16:12 <jrandom> есть вопросы/комментарии/опасения по поводу 0.6.1.3? 16:13 <jrandom> ок, если нет, давайте перейдём к 2) Freenet, I2P и даркнеты (о боже) 16:13 <cervantes> 609 известных пиров! 16:14 <cervantes> (w00t) 16:14 <jrandom> ага, сеть растёт 16:14 <+fox> <blx> о боже! 16:14 * cervantes устроил тотализатор — через сколько мы доберёмся до большой 1000 16:14 <jrandom> хех 16:14 <tethra> хехех 16:15 <tethra> ставим в digital cash? ;) 16:15 <cervantes> неа... jrandom уже неведая пожертвовал все свои деньги на пиво на этот год 16:16 <jrandom> хехе 16:16 <jrandom> ок, по 2) не уверен, что есть что добавить (кажется, мы уже загнали эту лошадь). есть вопросы/комментарии/опасения? 16:18 <cervantes> как ты сказал, как минимум это стимулировало интересные полусвязанные обсуждения безопасности, то есть 3) 16:18 <jrandom> если нет, можем быстро перейти к 3) Атаки на начальную фазу создания tunnel 16:18 <jrandom> ага, так и есть 16:19 <jrandom> вопрос, который поднял Michael, количественно подтверждает моё общее представление, и приятно это явно сформулировать 16:20 <jrandom> будет дальнейшее обсуждение новой атаки позже сегодня вечером (как только я смогу написать ответ), но первая, похоже, не слишком проблемна 16:21 <jrandom> всё ли понятно, есть ли вопросы или опасения по этому поводу? 16:22 <cervantes> хех... это либо значит, что всем всё ок, либо никто не может понять, что к чему 16:23 <cervantes> запишу себя в категорию «неведение — благо» 16:23 <jrandom> хех по сути это атака, при которой злые ребята оказываются исходящей конечной точкой каждого tunnel, который вы когда‑либо строили 16:23 <jrandom> когда вы только запускаетесь, «каждый tunnel, который вы когда‑либо строили» — это очень маленькое число (напр. 0, 1, 2) 16:24 <jrandom> но через несколько секунд это число становится достаточно большим, чтобы превратить (c/n)^t в очень-очень маленькую величину 16:25 <tethra> (c/n)^t это... 16:25 <jrandom> (это одна из причин, почему мы не запускаем i2cp listener — и, соответственно, i2ptunnel/и т. п. — какое‑то время после старта) 16:25 <jrandom> c == число сговаривающихся пиров (злодеев), n == число пиров в сети, t == число созданных вами tunnels. 16:25 <cervantes> понятно... 16:25 <tethra> ах 16:26 <jrandom> по мере роста t вероятность успешной атаки становится очень маленькой 16:26 <cervantes> то есть, чтобы это вообще было жизнеспособно, нужно начать использовать свой router для чувствительных задач в течение пары минут после запуска? 16:26 <jrandom> (или, во всяком случае, меньше, чем вероятность захвата всех хопов в tunnel) 16:26 <tethra> ага, вижу 16:27 <jrandom> cervantes: сразу, до построения 3‑го tunnel 16:27 <jrandom> (предполагая, что вы используете tunnels из 3 хопов) 16:27 <cervantes> это довольно маловероятно 16:28 <cervantes> просто с точки зрения сценариев использования 16:28 <jrandom> именно. 16:28 <jrandom> и поскольку при старте мы строим больше 3 tunnels прежде чем запускать какие‑либо клиенты, это не только вопрос вероятности 16:28 <jrandom> но всё равно полезно количественно оценить атаку 16:29 <cervantes> стоит ли дать router поработать подольше, чтобы защититься от какой‑либо вероятности? 16:30 <cervantes> или поактивнее покрутиться... 16:30 <jrandom> возможно. если игнорировать время установления соединений, а также неслучайность выбора пиров, вероятность равна нулю 16:31 <tethra> это повод сказать «woot!», так? 16:32 <jrandom> ага, хотя с инженерной точки зрения не стоит игнорировать эти особенности ;) 16:32 <jrandom> так что для 0.6.2 стоит посмотреть на это в ходе переработки реализации выбора/упорядочивания пиров для tunnel, чтобы убедиться, что всё ведёт себя разумно 16:34 <jrandom> ок, если по 3) больше ничего, перейдём к 4) I2Phex 16:34 <jrandom> sirup не здесь, и я не видел striker в irc — redzara, ты здесь? 16:36 <+redzara> да 16:36 <+redzara> Первый проход почти завершён: порт модификации Sirup на последний Phex CVS. 16:36 <jrandom> круто! 16:36 <+redzara> далее: второй проход: diff между кодом Sirup и базовым кодом Phex, использованным в первоначальном релизе, чтобы ничего не забыть :) 16:37 <+redzara> возможно, закончено к этим выходным 16:37 <jrandom> вау, было бы здорово 16:37 <+redzara> Третий проход: рефакторинг слоя коммуникаций вместе с GregorK 16:37 <+fox> <GregorK> надеюсь, вы в курсе, что в последнем Phex CVS код загрузки нестабилен, а файл загрузки несовместим с предыдущими релизами 16:38 <jrandom> это I2P, мы привыкли к нестабильности :) 16:38 <+fox> <GregorK> :) 16:38 <+redzara> Для последнего прохода, так как у меня сейчас нет контакта с GregorK, это будет довольно трудно :( 16:38 <jrandom> GregorK: что бы вы рекомендовали для интеграции? 16:39 <+fox> <GregorK> ну вот теперь у тебя есть контакт со мной ;) 16:39 <jrandom> а, ок, redzara, первых двух в любом случае хватит :) 16:39 <+redzara> GregorK : привет, дружище 16:40 <+redzara> GregorK : Я внимательно прочитал весь код 16:40 <+fox> <GregorK> у меня есть идея, как построить слой... Могу постараться подготовить его как можно лучше, а там посмотрим, насколько хорошо он ляжет и что потребуется изменить 16:40 <+fox> <GregorK> весь?? вау... 16:40 <+redzara> Gregork : да, весь!! 16:41 <cervantes> он даже знает размер твоего нижнего белья 16:41 <Rawn> :D 16:41 <+fox> <GregorK> отлично... в следующий раз, когда буду за покупками, просто спрошу тебя... 16:43 <+fox> <GregorK> было бы здорово, если бы кто‑то из команды I2Phex был и в команде Phex тоже.. 16:43 <jrandom> redzara: как думаешь, у нас будет релиз I2Phex 0.1.2 с результатами твоего второго прохода до того, как мы всё сольём в плагинный слой в основной ветке Phex? или всё за один раз? 16:43 <+redzara> Извините, но я недостаточно хорошо понимаю/говорю/читаю/пишу по‑английски, чтобы смеяться над тем, что вы написали 16:43 <+fox> <GregorK> это также помогло бы исправлять баги, присутствующие с обеих сторон 16:44 <jrandom> GregorK: надеюсь, мы найдём способ, чтобы сторона I2P была лишь тонким плагином в Phex, верно? 16:44 <jrandom> или, по‑твоему, их стоит держать раздельно? 16:44 <+redzara> jrandom : думаю, мы можем получить Phex 2.6.4 поверх I2P, для меня I2Phex закрыт 16:45 <jrandom> закрыт? 16:45 <+fox> <GregorK> не уверен, что мы сможем сделать так сразу, но думаю, большую часть можно выделить в плагин. 16:45 <jrandom> круто, да, работы много, уверен 16:46 <jrandom> особенно если посмотреть на вещи вроде java.net.URL (которая при создании «течёт» DNS‑запросами и т. п.) 16:46 <+redzara> jrandom : закрыт, завершён 16:46 <+Ragnarok> ррр 16:47 <jrandom> ок, верно, redzara, как только мы всё заработает в Phex 2.6.4 поверх I2P, согласен, нужда в I2Phex вряд ли останется 16:47 <+fox> <GregorK> верно... думаю, Phex в некоторых местах использует Apache URI class, чтобы обойти это... но только при необходимости 16:48 <jrandom> да, помню, баловался с той библиотекой, выглядит неплохо 16:49 <jrandom> мы точно поможем немного проаудировать вещи на тему анонимности/безопасности, прежде чем отдавать это конечным пользователям поверх I2P 16:49 <jrandom> (не к тому, что в Phex есть проблемы, просто они есть в любом приложении, и, надеюсь, мы поможем их разрулить) 16:50 <+fox> <GregorK> по некоторым вещам, как использование Socket и подобное, у меня есть идея, как интегрировать это плавно... но в других местах, таких как разные возможности на UDP и т. п., я пока не уверен, как лучше решить их 16:50 <+fox> <GregorK> о, уверен, в Phex много проблем. :) 16:50 <jrandom> ага, с сокетами будет легко, но, возможно, придётся отключить другие вещи. для чего используется UDP — быстрые запросы? 16:51 <+fox> <GregorK> сейчас только для bootstrapping 16:51 <+fox> <GregorK> UDP Host Cache.. замена для GWebCache 16:52 <jrandom> ааа, ок. 16:52 <+redzara> Значит, это не нужно, если у нас приличный GWebCache? 16:53 <+fox> <GregorK> да... но у стандартного GWebCache тоже есть свои проблемы с безопасностью... 16:53 <+redzara> GregorK : не внутри I2P, думаю 16:54 <jrandom> о, это можно преодолеть — I2PSocket аутентифицирован — вы знаете «destination» пира на другой стороне, так что он не сможет сказать: «Я, э... whitehouse.gov... ага!» 16:54 <jrandom> но ты прав, это нужно проверить 16:54 <+fox> <GregorK> ещё передача firewall‑to‑firewall была бы темой для UDP, которую мы хотели бы реализовать, как только найдём добровольца :) 16:54 <jrandom> а, ну, I2P не нужны firewall‑to‑firewall передачи — I2P предоставляет полностью открытое end‑to‑end адресное пространство :) 16:55 <jrandom> но... о, это может быть полезно 16:55 <jrandom> если у пользователей Phex были бы «0 hop tunnels», они получили бы бесплатный обход NAT/передачи firewall‑to‑firewall с вполне приличной скоростью 16:55 <+fox> <GregorK> ещё — LAN‑широковещательные рассылки запросов и т. п.... для упрощения шаринга контента в частных сетях 16:56 <jrandom> (0 hop tunnels обеспечивают некоторый уровень правдоподобного отрицания без необходимости, чтобы промежуточные пиры несли трафик) 16:57 <jrandom> хм, LAN‑широковещание — это хорошо, хотя не уверен, что I2P это действительно нужно (ведь знать, где другой пир, — риск для анонимности :), так что, возможно, эту функцию стоит отключать при использовании плагина I2P? 16:58 <cervantes> *по умолчанию отключена 16:58 <+fox> <GregorK> ну, этого ещё нет... но в таком случае пользователи обычно и так знают друг друга, чтобы построить эту частную сеть.. 16:58 <jrandom> о, верно, cervantes 16:58 <jrandom> да‑да, GregorK 16:59 <+fox> <GregorK> есть ли какие‑то изменения в пользовательском интерфейсе?? 17:00 <+bar> ну, нам не понадобятся флажки :) 17:00 <jrandom> как минимум, полезна возможность иметь несколько опций конфигурации, связанных с I2P. 17:01 <jrandom> думаю, sirup смог переключить часть отображения на использование I2P «destinations» вместо показа IP + номера порта, так что, как по мне, всё было ок 17:01 <+redzara> А как насчёт bitzyNot? Пока нет, но флаги и страны не используются 17:01 <jrandom> bitzy? 17:01 <+redzara> сорри, неверный copy/paste :( 17:02 <+fox> <GregorK> можете предоставить список опций конфигурации и дополнительных функций, которые вам нужны? 17:03 <jrandom> уверен, мы сможем это дать. host+port, на котором запущен I2P, и пара выпадающих списков с настройками производительности/анонимности — должно хватить 17:03 <jrandom> но мы пришлём детали 17:02 <cervantes> [x] Режим суперскорости передачи 17:02 <+fox> <GregorK> ну, bitzi используется для идентификации файлов... это проблема для анонимности? 17:03 <vulpine> <redzara> GregorK : готовлю, но в основном изменений нет 17:03 <+fox> <GregorK> :) спроси у своего провайдера, cervantes... 17:03 <redzara> GregorK : возможно, я над этим работаю 17:04 <cervantes> GregorK: хех, живу в UK... никаких шансов ;-) 17:04 <+fox> <GregorK> если передавать файлы между 2 экземплярами Phex на одном ПК... передачи молниеносные ;) 17:05 <cervantes> круто... у меня много классных фильмов, которыми я могу делиться сам с собой :) 17:05 <cervantes> * вычеркнуть это из протокола встречи * 17:06 <bar> jrandom уже поднимал тему, но вот снова безумная идея: 17:06 <+bar> как насчёт интегрировать I2P в Phex, чтобы у обычных пользователей были 0‑hop tunnels? 17:07 <+fox> <GregorK> думаю, показ флажков и IP+port идёт из объекта HostAddress... который будет скрыт новым слоем... так что можно отображать что‑то другое 17:07 <+bar> (для правдоподобного отрицания и UDP‑пробивки firewall) 17:08 <+fox> <GregorK> не уверен, что я правильно понимаю, что это значит ;) 17:08 <+bar> возможно, я тоже ;) 17:09 <jrandom> GregorK: по сути это значит, что пользователи Phex общались бы напрямую, но получали бы правдоподобное отрицание, поскольку они могли бы говорить и косвенно 17:09 <+bar> jrandom, уверен, ты понимаешь, к чему я клоню, можешь пояснить? 17:09 <jrandom> они также «бесплатно» получали бы обход NAT от I2P, а также защиту данных и защиту от сниффинга со стороны ISP и т. п. 17:09 <+redzara> GregorK : значит, нужно выкинуть весь код, связанный с host+port + IsLocalIP + IsPrivateIP + ... 17:10 <jrandom> с другой стороны (и это БОЛЬШАЯ сторона), он не смог бы общаться с клиентами gnutella, которые не работают поверх I2P 17:10 <jrandom> (хотя в итоге все будут ;) 17:10 <+fox> <GregorK> Думаю, первый шаг — и он уже достаточно большой — сблизить I2P и Phex. 17:10 <jrandom> согласен 17:10 <+bar> (чёрт, не подумал об этом) 17:11 <+bar> да, точно 17:11 <jrandom> это разговор о летающих пони. давайте сначала займёмся практическими вещами 17:11 <+fox> <GregorK> а потом, посмотрев, как это работает, решим, как двигаться дальше.. 17:11 <jrandom> именно 17:12 <+fox> <GregorK> redzara: мне бы хотелось иметь две реализации HostAddress: одну для I2P и одну как текущая. 17:14 <+redzara> Gregork : без проблем, я прокомментировал весь код в своём моде, так что можно легко собрать две реализации. Только дайте закончить начальную работу, пожалуйста 17:14 <+fox> <GregorK> конечно.. без проблем.. 17:14 <jrandom> :) ок, так что, redzara, думаешь, мы сможем получить альфа‑тест новой версии на базе Phex‑2.4.2 когда‑нибудь на следующей неделе? 17:15 <jrandom> (для части второго этапа. твой третий этап потребует больше работы по интеграции в основную ветку) 17:15 <+redzara> jrandom : следующая неделя мне подходит 17:16 <jrandom> ок, отлично 17:16 <+redzara> s/next/next week/ 17:16 <jrandom> ок, это весьма захватывающе, будет прекрасно, если всё пойдёт гладко 17:17 <jrandom> есть ли ещё что обсудить по 4) I2Phex, или кратко перейдём к 5) Syndie/Sucker? 17:17 <cervantes> I2P определённо выиграет от таких killer apps 17:18 <+fox> <GregorK> кстати, есть рассылка Phex CVS для всех изменений в Phex... если это поможет 17:18 <jnymo> *кхм*.. ещё бы 17:18 <jrandom> ок, отлично, спасибо, GregorK 17:18 <jrandom> определённо, cervantes 17:19 <jrandom> по пункту 5) мне особо нечего добавить сверх того, что там есть 17:19 <jrandom> dust: ты здесь? 17:19 <+redzara> GregorK : Спасибо, но одной версии мне более чем достаточно :) 17:19 <jrandom> хехе, redzara 17:19 <dust> В последнее время у меня было мало свободного времени, но если появится, думаю, попробую разобраться с этой addresses.jsp, добавить 'RSS' в выпадающий список протоколов там, а затем проложить путь через Updater, Sucker к BlogManager. 17:20 <dust> если только ни у кого нет лучшей идеи 17:20 <jrandom> офигенно 17:20 <jrandom> звучит идеально. 17:21 <jrandom> хотя, хм, возможно, понадобится дополнительное поле («в какой блог публиковать» и «какой префикс тега»)... 17:21 <jrandom> возможно, имеет смысл отдельная форма/таблица, хотя может и нет 17:22 <dust> о, я думал, addresses.jsp предназначена только для одного блога (раз нужно логиниться, чтобы попасть туда?) 17:22 <jrandom> ах да, верно, хороший пойнт 17:23 <jrandom> часть с updater немного расплывчата, но ты прав 17:23 <dust> (разберёмся, когда дойдём) 17:23 <jrandom> ага 17:24 * jnymo думает, что www.i2p.net мог бы запустить что‑то вроде «магазинчика мерча» 17:24 <jnymo> с футболками eyetoopie с надписью «I am Jrandom» ;) 17:24 * mrflibble всё ещё дочитывает «флеймвар», который, похоже, раскручивается в настоящий флейм :) 17:24 <jrandom> хех, jnymo 17:25 <jrandom> да, в той ветке много контента 17:25 <jrandom> ок, пожалуй, это подводит нас к 6) ??? 17:25 <jrandom> есть ли ещё что‑нибудь для обсуждения на встрече? 17:25 <+bar> ага, короткая ремарка по вопросу symmetric NAT (немного покопался): 17:25 <+nickless_head> jrandom: я знаю правду! 17:25 <+fox> <blx> kaffe? 17:25 <mrflibble> упс, прости, jr 17:26 <jnymo> но серьёзно... у каждого open source проекта сколь‑нибудь заметного размера есть свой раздел с мерчем 17:26 <+nickless_head> jrandom: у меня есть доказательства, что ты взломал главную страницу last.fm! 17:26 <+nickless_head> (в разделе «что вы получите при регистрации» было указано «пони») 17:26 <jrandom> jnymo: думаю, ты прав, стоит исследовать это направление, это может быть хорошим методом фандрайзинга тоже 17:27 <jnymo> jrandom: именно 17:27 * mrflibble купил бы футболку 17:27 <+bar> итак, что касается symmetric NAT, 17:27 <+bar> как по мне, в отличие от уже поддерживаемых NAT, тут нет волшебного трюка. единственный корректный путь — изучать поведение каждого symmetric NAT и использовать вводящих (introducers) для проб. 17:28 <jrandom> blx: последний kaffe CVS полностью b0rked. криптопакеты отсутствуют в исходниках, prng не инициализируется, а обработчики url не умеют работать с file:// :( 17:28 <jnymo> наверное, не захочешь носить её на публике, пока у I2P не будет пару тысяч пользователей ;) 17:28 <+bar> (думаю, так, например, Hamachi и Skype делают UDP‑пробивку из‑за symmetric NAT) 17:28 <+nickless_head> jnymo: кружки были бы огонь :) 17:28 <+bar> судя по тому, что я пока прочитал в сети, алгоритмы предсказания symmetric NAT довольно паршивые. 17:28 <jrandom> хм, bar 17:28 <mrflibble> хехе, я бы не ставил свой ник. о, и я всё ещё жив/не арестован, хотя у меня есть футболка IIP 17:28 <jrandom> да, я тоже такое читал 17:29 <+bar> постараюсь собрать ещё хорошие, релевантные материалы по теме. 17:29 <+redzara> Небольшой вопрос: каков был обычный средний процент ретранслированных байтов в 0.6.1.3? 17:29 <jrandom> спасибо, bar 17:29 <+fox> <jme___> bar, получившиеся предсказания стабильны? 17:29 <+fox> <jme___> bar, позволь перефразировать :) 17:29 <+fox> <blx> jrandom, грустно слышать 17:30 <jrandom> redzara: к сожалению, я забыл положить это в netDb. однако прямо сейчас вижу 2.6 и 3.8 17:30 <jrandom> blx: мне тоже :( 17:30 <+fox> <jme___> bar, когда вы анализируете поведение NAT‑коробки и находите формулу для предсказания, это всегда работает для этой NAT‑коробки? или потом то работает, то нет? 17:30 <jrandom> blx: знаю, они сейчас что‑то мержат с classpath, так что, надеюсь, как только это разрулят 17:30 <+fox> <blx> вероятно, значит, я не присоединюсь к вечеринке 17:30 <jrandom> blx: ты привязан именно к kaffe или в целом к OSS/DFSG? 17:31 <+fox> <blx> свободное ПО 17:31 <+fox> <blx> можешь сказать DFSG 17:31 <jnymo> если пользователь I2P захочет использовать хостинговый сервер для I2P, какую недорогую, либеральную хостинговую компанию выбрать? 17:31 <+bar> jme___: сообщается, что Hamachi удаётся посредничать в 97% всех попыток соединения. полагаю, есть NAT, которые проявляют почти случайное поведение при назначении портов 17:32 <jrandom> ок, уверен, что‑нибудь придумаем, blx. kaffe раньше работала, и мы не зависим ни от чего специфичного для Sun 17:32 <jrandom> jnymo: я использую sagonet.net, но они подняли цены с 65/мес до 99/мес (зато быстрый канал с 1250GB/мес) 17:32 <jrandom> знаю, в Германии тоже есть дешёвые 17:33 <+fox> <jme___> bar, 97% было бы потрясающе 17:33 <jrandom> redzara: какую скорость ретрансляции ты видишь? 17:33 <+bar> jme___: да, значит, большинство symmetric NAT предсказуемы 17:33 <+fox> <blx> jrandom, очень надеюсь. меня это дерьмо очень интересует :) 17:33 <+fox> <jme___> bar, что бы ты сделал? relay, UDP‑пробивка, обратное соединение (cnx reversal)... есть другие техники? 17:33 <jnymo> 99 — это дорого, в среднем? 17:34 <+redzara> jrandom между 3,8 и 4,2 17:34 <jrandom> jme___: мы на UDP, обратное соединение не нужно :) 17:35 <+bar> jme___: я не эксперт, возможно, к следующей встрече у меня будет больше инфы (но это очень похоже на профилирование + UDP‑пробивку ;) 17:35 <jrandom> jnymo: для 1250GB — не особо. я видел 60–120 USD/мес за 50–100GB/мес 17:35 <jrandom> bar: возможно, UPnP — лучший путь? 17:35 <+fox> <jme___> jrandom, даже с UDP это полезно :) 17:35 <+redzara> jrandom : но только некоторые узлы дают серьёзное влияние, возможно, какие‑то старые 17:35 <+fox> <jme___> vulpine: ок 17:35 <jrandom> хотя это помогает только тем, кто может управлять своим NAT 17:36 <+fox> <jme___> UPnP нужно поддерживать, но он не исключает другие способы 17:36 <jrandom> ну, всё, что мы делаем сейчас, работает без какого‑либо UPnP 17:36 <+fox> <jme___> потому что UPnP поддерживается не всеми NAT, далеко не всеми 17:36 <jrandom> верно, например NAT провайдера 17:36 <+bar> jrandom: если у UPnP нет проблем с безопасностью, полагаю, не повредит. хотя Hamachi не использует UPnP 17:36 <+fox> <jme___> здесь под «нужно» = чтобы обеспечить максимальную связность 17:37 <+fox> <jme___> ок, возвращаюсь к своему C++ :) 17:38 <jrandom> верно, jme___, хотя если мы сможем делать symmetric hole punching в дополнение к cone/restricted hole punching, мы в отличной форме 17:38 <jrandom> пока, jme___ 17:38 <jrandom> да, идеально было бы обойтись без этого 17:39 <jrandom> ок, есть ли ещё что‑нибудь для обсуждения на встрече? 17:41 <jrandom> если нет... 17:41 * jrandom подводит итоги 17:41 * jrandom *baf* закрывает собрание