Reunião de Desenvolvimento do I2P - 11 de outubro de 2005

16:29 <jrandom> 0) oi 16:29 <jrandom> 1) 0.6.1.2 16:29 <jrandom> 2) I2PTunnelIRCClient 16:29 <jrandom> 3) Syndie 16:29 <jrandom> 4) I2Phex 16:29 <jrandom> 5) Stego e darknets (re: flamewar) 16:29 <jrandom> 5) ??? 16:29 <jrandom> 0) oi 16:29 <@cervantes> (6) 16:29 <+postman> você quer dizer 6)? 16:29 <jrandom> é, eu não sei contar ;) 16:30 * postman dá um high-five em cervantes 16:30 <jrandom> notas de status semanais publicadas @ http://dev.i2p.net/pipermail/i2p/2005-October/000990.html 16:30 <wiht> Perguntas deveriam ser o item 6. 16:30 <jrandom> como estou 30 minutos atrasado, vocês já leram aquelas notas, tenho certeza, então vamos começar ;) 16:31 <jrandom> 1) 0.6.1.2 16:31 <@cervantes> 6) Discutir o péssimo senso de timing do colega de quarto do jrandom 16:31 <jrandom> *cof* ;) 16:31 <jrandom> ok, como mencionado no e-mail, o release 0.6.1.2 parece estar indo muito bem 16:32 <jrandom> encontramos o bug que mantinha os servidores IRC presos a uma build mais antiga, e agora eles também estão atualizados (w00t!) 16:32 <+postman> :) 16:32 <wiht> Falando nisso, no netDB no console do router, seria possível listar a tabela com os routers e suas versões no topo da página? 16:33 <jrandom> o número de routers por versão, certo? claro, isso pode ser feito com facilidade, talvez integrar na tabela do peers.jsp (mostrando a versão por peer) e uma nova tabela no final? 16:34 <jrandom> é meio legal ver 9 versões funcionando bem juntas, embora as mais novas funcionem melhor 16:35 <jrandom> ok, mais alguém tem algo a levantar sobre 1) 0.6.1.2? 16:35 <+postman> um dos meus routers mostra 1080 conhecidos 16:35 <jrandom> caramba 16:35 <+postman> acho que isso está um pouco fora da curva? 16:35 <jrandom> isso é na 0.6.1.2? 16:35 <+postman> sim, acho que sim 16:36 <jrandom> hmm, é... um pouco alto. estou vendo cerca de metade disso agora 16:36 <+Complication> Estável em algo como 400 por aqui 16:37 <+bar> aqui também 16:37 <wiht> Vejo 260 routers conhecidos. 16:37 <jrandom> postman: talvez possamos investigar o que está acontecendo nesse router depois da reunião (poderia me enviar um tar.bz2 de netDb/routerInfo-*?) 16:38 <+postman> jrandom: sim, obrigado 16:38 <jrandom> gracias 16:38 <jrandom> sim, nem todos verão todas as referências no netDb, então é normal haver flutuação 16:40 <jrandom> ok, se não há mais nada sobre 1) 0.6.1.2, vamos passar para 2) I2PTunnelIRCClient 16:40 <@cervantes> boa, dust 16:40 <jrandom> como mencionado no e-mail, temos um novo filtro específico para o protocolo IRC disponível no CVS, e ele deve sair como padrão na próxima rev 16:41 <+postman> legal 16:41 <jrandom> sim, isso é muito legal, as pessoas pedem algo assim há séculos 16:41 <+Myo9> Jrandom, você ficou mais aberto recentemente, ficamos sabendo da sua ex e agora do seu colega de quarto, etc. Lembre-se: http://www.navysecurity.navy.mil/st031204.webp 16:41 <jrandom> *cof* 16:42 <dust> se você quiser ver o que seu cliente envia, você pode adicionar net.i2p.i2ptunnel.I2PTunnelIRCClient=INFO e então olhar os logs para ver tudo 16:43 <dust> testei alguns clientes, mas há muitos.. 16:43 <jrandom> sim, estive observando por um tempinho, mas o filtro parece sólido 16:44 <jrandom> há algumas coisas legais que talvez possamos fazer no futuro também - por exemplo, PING/PONG localmente, para reduzir a atividade na rede 16:44 <+Complication> dust: obrigado pela "info" :) 16:44 <+bar> incrível, dust, muito obrigado 16:44 <wiht> Isso significa que não precisamos configurar um tunnel IRC extra? 16:44 <jrandom> wiht: não, você vai precisar de um tunnel IRC, mas ele pode substituir o que você já usa 16:45 <+Complication> wiht: só se preocupe menos com nosso cliente IRC nos entregando 16:45 <jrandom> postman/cervantes: alguma opinião sobre aumentar ou remover os timeouts de ping/pong do servidor? 16:45 <wiht> Isso explica, obrigado. 16:46 <+postman> mmh, eu não os removeria, meu cliente pirou completamente quando mexi nisso 16:46 <jrandom> postman: bem, estou pensando se ele respondesse localmente, assim o cliente receberia um PING/PONG realmente, realmente rápido 16:46 <@cervantes> postman: o proxy poderia responder aos pings 16:46 <jrandom> (mas o ping/pong não precisaria ir pela rede) 16:47 <jrandom> não sei o impacto, mas pode valer a pena investigar. 16:47 <@cervantes> mas não sei como os servidores reagiriam, você pode acabar com um monte de clientes zumbis 16:47 <+postman> jrandom: bem 16:47 <jrandom> bem, o keepalive da biblioteca de streaming deve lidar com isso 16:47 * Complication ocasionalmente sofreu zumbificação 16:47 <jrandom> Complication: recentemente? 16:47 <+postman> jrandom: se o proxy fizer ping pelo cliente, o proxy deve fazer ping/pong para o cliente também 16:48 <+Complication> Uma semana atrás, acho. 16:48 <jrandom> postman: um PING do cliente para o proxy faria com que o proxy respondesse diretamente ao cliente com um PONG, sem enviar nada pelo i2p 16:48 <+Complication> Mas a minha "cópia" acabou sendo desconectada. 16:48 <@cervantes> jrandom: a conexão ficaria aberta... os servidores teriam que diminuir o limite para decidir em que ponto um cliente está estagnado e precisa ser ejetado 16:48 <jrandom> Complication: ah, os servidores IRC não estavam atualizados naquela época, não deveria acontecer mais 16:49 <+Complication> Sem eu usar o "ghost". Usos recentes do comando ghost foram por operar com muitos nós. 16:49 <+postman> jrandom: e a medição de lag? 16:49 <jrandom> cervantes: certo. e/ou, se necessário, o proxy poderia injetar uma mensagem PING extra no servidor se ele /precisar/ de uma. 16:49 <+postman> acho bastante útil saber se estou com lag ou não 16:49 <jrandom> postman: eu também, mas você sempre pode /msg para você mesmo 16:50 <dust> talvez você pudesse reduzir o número de pings 16:50 <jrandom> economizaria uma quantidade substancial de banda, já que as mensagens do tunnel são blocos de 1024byte, enviados por 2*k+1 saltos 16:50 <jrandom> isso também 16:50 <jrandom> não sei, só uma ideia. o que temos agora já é sensacional 16:51 <+postman> ok, eu tentaria aplicar um patch em um servidor de teste 16:51 <@cervantes> talvez possamos analisar reduzir a quantidade... mas acho que ainda devemos enviar alguns pings reais para determinar se os clientes ainda estão vivos 16:51 <+postman> talvez funcione 16:51 <jrandom> parece razoável, cervantes. acho que não precisaria de nenhum patch no servidor, espero? 16:52 <+postman> jrandom: para desativar talvez - mas reduzir o intervalo é parâmetro de conf 16:53 * postman mastiga a documentação do ircd ( de novo ) 16:53 <jrandom> legal, sem pressa. só algo que podemos analisar algum dia 16:53 <@cervantes> class servers 16:53 <@cervantes> { 16:53 <@cervantes> pingfreq 120; 16:54 <@cervantes> class clients { pingfreq 90 } 16:54 <@cervantes> essa é a minha configuração atual 16:54 <+postman> cervantes: sim, eu sei - a questão é se dá para desativar mesmo 16:54 <@cervantes> eu não desativaria... só veria como reduzir 16:55 <+postman> ok, vamos começar com isso 16:55 <+postman> cervantes: que tal 180 s? 16:56 <@cervantes> já começar fundo com 240 16:56 <@cervantes> mas talvez devêssemos preparar primeiro o lado do ircproxy 16:57 <@cervantes> *discutir após a reunião* 16:57 <+postman> concordo 16:57 <jrandom> w3rd. ok, mais algo em 2) I2PTunnelIRCClient, ou passamos para 3) Syndie? 16:57 <@cervantes> qualquer coisa para reduzir meus atuais 40 kb/s de tráfego médio do router ;-) 16:58 <jrandom> heh, por algum motivo duvido que isso seja só IRC ;) 16:58 <jrandom> ok, seguindo 16:59 * cervantes esconde os downloads de vídeos de pônei que ele tem baixado do jrandom a semana toda 16:59 <@cervantes> is=the 16:59 <+postman> LOL 16:59 <jrandom> como mencionado no e-mail, tem umas coisas bem legais rolando com o Syndie 16:59 <jrandom> a cli é trivial, mas o novo Sucker do dust parece bem promissor 16:59 <jrandom> dust: quer nos dar um resumo? 17:00 <dust> ah, 17:01 <dust> bem, ele usa rome para fazer o parsing dos feeds e depois converte para sml, como descrito no blog do jrandom 17:02 <dust> ainda não é o que você chamaria de robusto, mas tem só dois dias :) 17:02 <dust> já tenho um pouco de Dilbert no meu Syndie.. 17:02 <dust> :) 17:02 <dust> . 17:02 <jrandom> legal 17:03 <jrandom> ok, o que você acha sobre a direção - devemos jogá-lo no código-fonte do Syndie e expô-lo como uma cli, ou mantê-lo separado e distribuí-lo independentemente, ou outra coisa? 17:04 * dust não sabe, você decide 17:04 <dust> quanto menos ferramentas separadas, melhor 17:04 <jrandom> sim, provavelmente é mais fácil empacotar tudo junto, assim todo mundo sabe que pode usá-lo 17:05 <jrandom> aí poderíamos fazer coisas como integrá-lo à interface web, e talvez ao scheduler do Ragnarok (sindicando com outros nós e puxando de rss/atom/etc) 17:07 <jrandom> ok, alguém tem perguntas/comentários/preocupações sobre 3) Syndie? 17:07 <wiht> Se vocês continuarem integrando software no I2P, ele pode virar um pacote inchado. 17:07 <wiht> Claro, posso desligar o Syndie se não estiver usando. 17:08 <jrandom> o i2p sdk 13KLOC 17:08 <jrandom> e o router do i2p tem só 22KLOC 17:08 <jrandom> mas sim, há um impacto nos tempos de download da instalação 17:09 <jrandom> se alguém quisesse, poderia construir um router enxuto sem apps cliente, usando apenas o router.jar, jbigi.jar, e i2p.jar 17:09 <wiht> Sim, eu me referia ao download. 17:09 <jrandom> (mas é muito mais útil quando há uma interface web para controlá-lo, e i2ptunnel, e a biblioteca de streaming, etc ;) 17:11 <jrandom> smeghead estava trabalhando em um sistema de distribuição (tipo o emerge, para java), e também tem o pessoal do jpackage 17:11 <jrandom> se alguém quiser procurar uma forma transparente e confiável de gerenciar os apps sem empacotar, seria bem legal 17:12 <jrandom> ok, se não há mais nada nisso, vamos pular para 4) I2Phex 17:13 <jrandom> não tenho muito a acrescentar além do que está nas notas de status 17:13 <jrandom> redzara: você por aqui? 17:13 <+redzara> sim tô 17:13 <+redzara> já estou trabalhando na próxima versão, enquanto aguardo a reunião com o Gregor. 17:13 <jrandom> ah, ótimo 17:13 <+redzara> Trabalho, por enquanto, consiste principalmente em identificar as diferenças e as necessidades relacionadas ao uso do I2P como por exemplo tcp/udp vs i2p, gestão dos parâmetros específicos do I2P (e gestão da atualização desses mesmos parâmetros na época das próximas versões, ...) portar o GWebCache para I2P, usar RSS ou não, usar push ou não... 17:14 <+redzara> Tenho muita documentação e código para ler 17:15 <jrandom> uau, sim, parece bastante. me avise se tiver alguma pergunta sobre integração com i2p, ou se só quiser alguém para trocar ideias 17:16 <jrandom> transformar a parte I2Phex em um plugin para o Phex principal seria sensacional 17:17 <jrandom> ok, mais alguém tem algo para 4) I2Phex? 17:18 <+redzara> Eu certamente precisaria de assistência para a parte de petname 17:19 <+redzara> e talvez também para o afinamento fino dos parâmetros dos tunnels 17:19 <jrandom> legal, a nomeação é bem fácil - em um nível básico, você poderia até se virar sem usar nomes (é assim que o I2Phex faz atualmente) 17:20 <jrandom> a config do tunnel também não deve ser um problema, embora isso traga a ideia de que talvez o Phex precise de uma seção de "configuração avançada" para plugins 17:20 <jrandom> (obviamente, queremos ter bons padrões de qualquer forma) 17:21 <+redzara> talvez algo como o ircclient, um filtro para garantir 17:22 <@cervantes> melhor deixar o app em forma, imho 17:22 <jrandom> isso pode funcionar, embora lidar com sequências arbitrárias de bytes possa ser difícil 17:23 <jrandom> embora um proxy como o ircclient talvez permita que qualquer cliente gnutella o use. mas daria um trabalhão. 17:23 <+redzara> humm, é só uma ideia ;) 17:23 * jrandom não conhece o protocolo bem o suficiente para dizer qual é a melhor abordagem, então sugere ir com a coisa mais simples que possa funcionar :) 17:25 <jrandom> ok, se não houver mais nada, talvez possamos passar rapidamente por 5) stego e darknets 17:26 <jrandom> não sei se tenho algo a acrescentar além do que está sendo dito na lista (e a discussão principal provavelmente deve continuar lá) 17:27 <jrandom> dito isso, alguém quer levantar algo sobre as questões apontadas? 17:27 <wiht> As versões 0.5 e 0.7 do Freenet foram mencionadas na discussão. Existe uma versão 0.6 do Freenet? 17:27 <jrandom> 0.6 é o ramo "unstable" atual da rede deles 17:27 <jrandom> até onde sei 17:27 <+postman> ohh, e eu pensei que tinha sido roubada por forças alienígenas 17:28 <jrandom> embora culpar os alienígenas normalmente seja uma aposta segura, este é um dos poucos casos em que não é culpa deles 17:28 <+postman> :) 17:28 <wiht> O Toad estava falando sobre conseguir coletar os endereços IP de nós do I2P ou do Freenet, certo? 17:28 <jrandom> entre outras coisas 17:29 <wiht> Só queria esclarecer isso, obrigado. 17:29 <jrandom> sem problema. ok, mais alguém tem algo sobre o 5), ou vamos para o bom e velho 6) ??? 17:30 <+postman> ok, tenho uma para o 6) 17:30 <jrandom> considere-nos lá. 17:30 <jrandom> e aí, postman? 17:30 <+postman> todos vimos que proxies capazes de filtro específico por protocolo são bons e necessários 17:31 <+postman> seria viável investir reflexão em um proxy genérico 17:31 <+postman> que possa ser alimentado com uma descrição de protocolo 17:31 <+redzara> Eu gostaria de ter um aplicativo tipo cron usando beanshell para executar código java dinamicamente 17:31 <+postman> junto com coisas para observar/filtrar/disfarçar 17:31 <+postman> como uma descrição xml de filtrar/sanitizar 17:32 <+postman> para que não precisemos de novo código-fonte, mas apenas de um novo arquivo/perfil de filtro 17:32 <+postman> (apenas uma pergunta se vale a pena pensar nisso) 17:32 <jrandom> muito, muito complicado, postman. seria possível usar um lexer como o javacc para construir linguagens de entrada e um app para traduzir essa linguagem para o formato de saída 17:32 <@cervantes> o difícil é captar as coisas que desviam do protocolo 17:33 <+postman> foi só uma ideia para disparar um processo de brainstorming 17:33 <+postman> imho, algo como um proxy genérico com filtro/parser modelado é bem utilizável 17:33 <wiht> Alguém conseguiu conectar a eepsites.i2p? Tentei várias vezes na última semana, mas nunca tive sucesso. 17:33 <jrandom> wiht: carreguei uma vez, é o mesmo que eepsites.com 17:34 <jrandom> (ou é .net? ou .org? esqueci) 17:34 * wiht visita eepsites.com 17:34 <jrandom> postman: se alguém conseguir bolar algo que funcione, seria sensacional 17:34 <+postman> jrandom: ok, vou pensar um pouco junto com a susi 17:34 <jrandom> w3wt 17:34 <+postman> jrandom: talvez a gente solte isso na semana que vem 17:35 <wiht> É eepsites.com, e é um mecanismo de busca para eepsites. 17:35 <+postman> mas eu tive um sonho de que funcionava 17:35 <+postman> :] 17:35 <jrandom> :) 17:36 * Complication suspeita que descrever todas as sutilezas que ocorrem em protocolos... exige código, nada menos que código 17:36 <+Complication> (para a maioria dos protocolos, pelo menos) 17:36 <@cervantes> nah, só umas regex malignas 17:36 <+postman> Complication: talvez essa suspeita seja o motivo que nos impede de ir mais a fundo 17:37 <+postman> Complication: ainda não tenho certeza, mas só a suspeita não vai me deixar em paz nesse assunto 17:37 <jrandom> bem, um ponto importante aqui é algo que o dust nos demonstrou - 17:37 * Complication teme uma regex capaz de tais coisas 17:37 <jrandom> código não é necessariamente tão assustador. 17:37 <+postman> viu? :) 17:37 <+postman> uma boa linguagem de modelagem de filtros fará o mesmo 17:38 <+postman> :) 17:38 <@cervantes> tcl? :) 17:38 <+Complication> Teria que ser boa. 17:38 * jrandom vê que você também tem seus próprios pôneis voadores, postman ;) 17:38 * dust também ficou incomodado em duplicar código aqui e ali 17:38 <+postman> jrandom: sem vacas :) 17:38 <jrandom> código funcionando>>> melhorias teóricas em código 17:39 <+postman> mmh 17:40 <+postman> uma coisa que aprendi com o i2p 17:40 <wiht>>>> significa "muito, muito melhor?" 17:40 <+postman> não desista à primeira vista 17:40 <jrandom> verdade, postman 17:40 <jrandom> sim, wiht 17:41 <jrandom> seria muito legal 17:41 <jrandom> ok, mais alguém tem algo para trazer para a reunião? 17:41 <+bar> bem, como está o IMAP funcionando, postman? (li sobre isso nos fóruns mas ainda não testei eu mesmo) 17:41 <+postman> bar: teste você mesmo - não tenho relatos de usuários ainda 17:41 * cervantes traz o gongo em formato de pônei 17:42 <+bar> ok, vou fazer :) 17:42 <+postman> bar: e para mim funciona MUITO BEM :) 17:42 <jrandom> legal 17:42 <+bar> legal 17:42 <+postman> cervantes: você é fixado 17:42 <@cervantes> eu?! 17:42 <@cervantes> :) 17:43 <jrandom> ok, antes de chegarmos à marca de 90 minutos 17:43 * jrandom se prepara 17:43 * jrandom *baf* encerra a reunião