Reunião de desenvolvimento do I2P - 20 de julho de 2004

14:05 <jrandom> 0) oi 14:05 <jrandom> 1) 0.3.2.3, 0.3.3 e o roadmap 14:05 <jrandom> 2) s/reliability/capacity/g 14:05 <jrandom> 3) atualizações do site 14:05 <jrandom> 4) ataques e defesas 14:05 <jrandom> 5) ??? 14:05 <jrandom> 0) oi 14:05 * jrandom acena 14:05 <jrandom> notas semanais de status publicadas em @ http://dev.i2p.net/pipermail/i2p/2004-July/000358.html 14:06 <jrandom> indo direto para 1) 0.3.2.3, 0.3.3 e o roadmap 14:07 <jrandom> (enquanto vocês leem adiante, imagino ;) 14:07 <jrandom> a versão 0.3.2.3 está por aí e parece estar indo bem 14:07 <jrandom> quais são os principais pontos problemáticos que as pessoas estão vendo? 14:08 <deer> <Nightblade> nenhum problema 14:08 <deer> <duck> 4d de tempo de atividade sem problemas 14:08 <jrandom> hmm, massa 14:08 <deer> <duck> para alguns o irc não parece muito estável 14:08 <deer> <duck> tipo o kaji sendo expulso a cada minuto 14:08 <deer> <duck> mas isso não é novidade 14:09 <jrandom> é, isso acontece com ele também na rede freenode, então não sei a que culpar 14:09 <deer> <duck> pois é 14:09 <deer> <duck> connelly teve alguns downloads ruins pelo que sei 14:10 <deer> <duck> mas você não me ouve reclamando 14:10 <jrandom> ah é mesmo? hmm, acho que descobrimos que alguns estavam relacionados à biblioteca dele, mas eu experimentei uma falha ocasional em transferências de arquivos maiores 14:10 <jrandom> especialmente enquanto baixava livros do alexandria 14:10 <jrandom> (bem, não especialmente, mas esse é o único site de que baixo) 14:11 <deer> <duck> :) 14:11 <jrandom> ok, bem, meu plano é que, assim que a versão 0.3.3 sair, meu tempo ficará focado em nos levar à 0.4, junto com quaisquer correções de bugs que surgirem 14:12 <jrandom> o trabalho restante para a 0.4 é basicamente coisa simples de web (novo console do router com servlets, integração com o Jetty, servlet para controlar o router e um servlet para configurar as instâncias do I2PTunnel) 14:13 <jrandom> talvez alguns pessoal de JSP/Servlet possa ajudar com parte disso para começar a se familiarizar com o código, embora eu já tenha feito bastante dessas coisas antes, então a impl não será muito difícil 14:13 <jrandom> pelo que sei, o instalador do hypercubus está praticamente pronto 14:13 <jrandom> (embora eu tenha jogado trabalho novo para ele hoje ;) 14:13 <deer> <duck> featurecreep++ 14:14 <jrandom> mantém o pessoal atento :) 14:14 <jrandom> (mas vamos lá, todo mundo odeia baixar todos os JARs separadamente para atualizações) 14:14 <deer> <duck> sim, esse é meu maior problema ao atualizar 14:14 <deer> <duck> (embora eu use cvs) 14:14 <deer> <duck> mas seria se eu não usasse 14:15 <jrandom> heh 14:15 <mihi> jrandom: é só tar todos eles -> 1 download ;) 14:15 <jrandom> isso seria simples o suficiente, e deixar updgrade.sh/upgrade.bat == jar xf upgrade.jar 14:16 <jrandom> (após uma chamada ao estilo wget) 14:16 <jrandom> bem, acho que o hypercubus tem o código para fazer todas essas coisas sob controle, então podemos deixar com ele para fazer a Coisa Certa 14:17 <jrandom> de qualquer forma, é, como vocês devem ter notado, nosso cronograma não é bem o que era antes 14:17 <jrandom> o roadmap foi atualizado e prooooolooongaaado 14:18 <mihi> jjrraannddoomm:: vveerrrriiiffiqqquuee sseeeuu sswwiittcchh ddee dduuuppplleexx 14:18 <deer> <Nightblade> hah 14:18 <jrandom> heh 14:18 * mihi cometeu um erro... quem acha primeiro? 14:19 <jrandom> (\n\n) 14:19 <jrandom> mas enfim 14:19 <mihi> ok, outro ;) 14:19 <duck> (sem espaços duplos) 14:19 <mihi> duck++ 14:20 <jrandom> acho que o roadmap está bem realista pelo menos até a versão 1.0 agora, embora, dependendo da adoção dos usuários e do feedback, possamos reordenar ou remover uma entre 0.4.2 ou 0.4.3 14:20 <jrandom> (e, claro, como sempre o roadmap está sujeito a mudanças se mais pessoas se envolverem :) 14:21 <modulus> talvez um dia eu me envolva, depois que eu aprender java, mas i2p não parece um projeto para novato. 14:21 <deer> <Sandworm> sim, vai levar mais tempo :) 14:21 <deer> * duck espera mais alguns deslizes pelo caminho 14:21 <modulus> :-) 14:22 <deer> * duck mal pode chamar de deslizes, olhe a tabela impressionante em http://www.i2p.net/redesign/announcements 14:22 <jrandom> deslizes podem acontecer, claro, mas acho que os marcos restantes são todos bem factíveis 14:22 <jrandom> é, valeu por mostrar que eu não tenho vida, duck ;) 14:22 <deer> <duck> esta é sua vida 14:22 <modulus> então, quando sai a 1.0? :-) 14:22 <deer> <duck> tenha orgulho disso 14:23 <jrandom> modulus: embora algumas partes do i2p sejam um saco, há muitas partes que um desenvolvedor novo pode encarar com bastante facilidade 14:23 <modulus> provavelmente partes bem chatas, né? 14:24 <jrandom> nada, de modo algum. por exemplo, criar um app bacana de transferência de arquivos anônimo ou de chat, um mini servidor web, um MUD, um app de xadrez, o que for 14:24 <duck> (atualizações do site) 14:24 <modulus> hmm, parece legal. 14:24 <jrandom> (também conhecidos como apps cliente simples que podem ser anônimos) 14:24 <jrandom> e claro, atualizações do site ;) 14:25 <modulus> qual é a dessa de atualizações do site? 14:25 <jrandom> nosso site precisa de trabalho (veja http://dev.i2p.net/pipermail/i2p/2004-July/000358.html ou espere alguns minutos pelo item 3 da agenda) 14:25 <cat-a-puss> Onde o myi2p entra nisso tudo? 14:25 <modulus> ah ah 14:26 <jrandom> cat-a-puss: http://www.i2p.net/redesign/myi2p :) 14:26 <modulus> acho que myi2p não é prioridade agora... 14:26 <jrandom> (acabei de escrever uma página breve sobre isso há algumas horas) 14:27 <jrandom> como observação, as atualizações do site são todas postadas na lista i2pwww (http://dev.i2p.net/pipermail/i2pwww/2004-July/thread.html) 14:28 <modulus> hmm, eu poderia escrever um aplicativo de nomes global :-) 14:28 <jrandom> mas ainda vejo a implementação do myi2p (pelo menos a base de livro de endereços e blog) sendo feita para a versão 1.0 14:28 <jrandom> (conforme o roadmap, previsto para novembro) 14:28 <jrandom> sim, certamente poderia 14:28 <modulus> algo mais simples que DNS, com autenticação e delegação de TLDs 14:28 <jrandom> também não seria ruim ter isso - um app simples em que você pudesse consultar um servidor de nomes central seria legal 14:29 <modulus> sim 14:29 <jrandom> então, mãos à obra :) 14:29 <modulus> Vou começar amanhã. puxe minha orelha se eu estiver em outras coisas ;-) 14:29 <jrandom> hehe legal, combinado 14:29 <jrandom> ok, passando para 2) s/reliability/capacity/g 14:29 <duck> pequena questão no site: 14:29 <duck> ah espera 14:29 <duck> isso é 3 14:29 <duck> desculpa 14:29 <jrandom> claro, manda? 14:30 <jrandom> ah, 'k 14:30 <jrandom> haverá uma mudança bastante fundamental no código de perfilamento e seleção de pares na versão 0.3.3, conforme descrito no email e em http://www.i2p.net/redesign/how_peerselection 14:31 <jrandom> tenho isso rodando em um par de routers no momento e parece se comportar bem (Speed: 25.18 (5 pares rápidos) Capacity: 17.50 (8 pares de alta capacidade) Integration: 37.00 (2 pares bem integrados)) 14:31 <jrandom> e nada de valores negativos :) 14:31 <modulus> :) 14:32 <jrandom> vou testar mais um pouco, talvez por mais um ou dois dias, e então lançar como 0.3.3 14:32 <cat-a-puss> d 14:32 <cat-a-puss> <modulus> 14:32 <cat-a-puss> ops 14:33 <duck> sugerindo não atualizar o cvs? 14:33 <cat-a-puss> para fazer DNS, olhe um cache de http://www.levien.com/thesis/compact.pdf 14:33 <jrandom> não, cvs está razoavelmente estável no momento 14:33 <jrandom> (mas como sempre, esteja preparado para voltar atrás se alguma coisa ruim acontecer) 14:35 <jrandom> parece legal, cat-a-puss, obrigado 14:35 <cat-a-puss> (Tenho uma cópia do original se alguém quiser) 14:36 <jrandom> o cache do Google embaralha um pouco as imagens, então se você tiver o PDF bruto seria ótimo 14:36 <jrandom> de qualquer forma, estamos nos afastando um pouco do tópico no momento (mas podemos voltar a isso) 14:37 <jrandom> é basicamente isso para a troca de reliability/capacity, então passando para 3) atualizações do site 14:37 <jrandom> duck: você tinha algo que queria levantar? 14:38 <jrandom> enquanto o duck prepara suas notas, talvez alguém tenha ideias/sugestões/preocupações com relação aos itens postados no email? 14:39 <deer> <Nightblade> o site está bom 14:39 <jrandom> é, eu gosto da nova navegação e o layout do site está bem limpo 14:40 <deer> <Nightblade> mais fácil encontrar as coisas 14:40 <cervantes> _bem_ mais fácil encontrar as coisas 14:40 <duck> antes de tudo quero agradecer ao nosso defensor dos usuários, o protocol, por se tornar útil :) 14:40 <jrandom> heh 14:40 <duck> ele teve boas sugestões e ele acabou de começar 14:40 <cervantes> hip hip hurra! 14:40 <jrandom> (muito bem!) 14:41 <duck> em seguida, acho que mal há motivo para não colocar o redesign no ar de verdade 14:42 <jrandom> concordo - talvez possamos apenas marcar news/development/documentation como itens de navegação que não são páginas, deixar de lado os ajustes de JVM e de configuração por enquanto e colocar algum conteúdo básico para a página do I2PTunnel, acho que podemos implantar 14:42 <jrandom> só quero que entre no ar com todos os links funcionando (e todas as páginas que não estão funcionando) 14:43 <jrandom> claro, haverá outras atualizações depois que entrar na vida ;) 14:43 <jrandom> er, no ar 14:44 <jrandom> como observação, o wilde também conectou nossa conta na 34sp, então vamos poder migrar o site para lá quando necessário 14:44 <cervantes> show 14:44 <jrandom> o que acha, duck? o menu.php consegue lidar com entradas de navegação que não sejam páginas? 14:44 * cervantes confere sua caixa de entrada por pontos de indicação 14:45 <jrandom> (ou seria muito esforço modificar isso?) 14:45 <jrandom> hehe cervantes, isso deve estar a caminho 14:45 <cervantes> ;-) 14:45 <cervantes> ah, o velho truque do "o cheque está no correio" 14:47 <duck> foi mal; fazendo algum outro trabalho no meio tempo. 14:47 <duck> ok; sim, é possível torná-lo apenas o título da seção de navegação 14:47 <jrandom> sem problema, podemos seguir e voltar a isso depois se preferir 14:47 <jrandom> ok, legal 14:47 <jrandom> (duck++) 14:48 <jrandom> ok, mais alguma coisa relacionada ao site? 14:48 <duck> com sua sugestão, parece pronto para subir. 14:48 <jrandom> se não, podemos ir para 4) ataques e defesas 14:48 <duck> . 14:48 <jrandom> combinado 14:49 <jrandom> ok, pressupondo que vocês leem a lista de discussão e viram as mensagens do connelly e as várias respostas 14:50 <cervantes> ele tem estado ocupado :) 14:50 <cervantes> (quase tanto quanto o proto) 14:50 <Connelly> na minha opinião, a rede parece sólida para tudo exceto análise de tráfego (sites com muito tráfego), ataques de corte de conexões por governos e para atacantes que tomem a maior parte da rede 14:50 <jrandom> embora eu ache que estamos bem, tenho certeza de que deve haver algo (ou algumas coisas) que perdemos, então por favor não assumam que o i2p faz ou fará o que diz - desafiem as suposições e digam por que isso é uma droga 14:50 <Connelly> a criptografia basicamente inviabiliza quaisquer ataques não agressivos 14:51 <jrandom> essa é a esperança 14:51 <jrandom> além disso, com capacidades do i2p 2.0 e 3.0, defesas para ataques por adversários em escala governamental serão possíveis 14:51 <Connelly> claro que na prática haverá brechas de segurança a corrigir 14:52 * jrandom ainda precisa escrever alguma documentação sobre como os atrasos do 3.0 vão prevenir ataques de segmentação 14:52 <jrandom> com certeza, connelly 14:54 <jrandom> ok, se não houver mais nada nessa linha, acho que é tudo que tenho 14:54 <jrandom> então 5) ??? 14:55 <jrandom> ah, como observação, tracei o gráfico de uso de banda vs. # de tunnels em que participou para uma das simulações ao longo de um período de 4 dias 14:55 <jrandom> isso está publicado em @ http://dev.i2p.net/~jrandom/4daybandwidth.webp 14:56 <jrandom> a simulação tinha mensagens de 32KB indo e voltando a cada 30s, com dois routers limitados a 6KBps, e as coisas se comportaram exatamente como 'deveriam' 14:56 <duck> (propriedade nolink implementada para o site) 14:56 <jrandom> (por exemplo, carga distribuída sobre os pares rápidos e confiáveis, pares lentos evitados, etc) 14:56 <jrandom> w00t 14:56 <Connelly> um gráfico logarítmico de banda/usuário vs tamanho da rede seria legal 14:57 <Connelly> assim você pode dizer 'sim, realmente escala' 14:58 <jrandom> isso nem precisaria de um gráfico log - a escalabilidade da comunicação do cliente é estritamente O(1) [requerendo 2k*msgSize, onde k = # de saltos no tunnel] 14:58 <jrandom> mas sim, concordo, precisamos de documentação descrevendo como o i2p escala 14:58 <Connelly> bem, para Kademlia ... isso está na sua sim? 14:58 <jrandom> sim, a sim é na verdade o código completo do router, tudo executado em uma única JVM 14:58 <jrandom> estou executando até com as conexões TCP completas em vez do sistema de comunicação da VM também 14:59 <jrandom> o código Kademlia é usado na primeira vez que a Alice quer contatar o Bob - enquanto continuarem conversando, a comunicação deles é O(1), pois anexam seu LeaseSet junto com o payload 14:59 <jrandom> (então não há necessidade de consultas subsequentes ao netDb) 15:00 <cervantes> vl07 e onb0 são os routers limitados? 15:00 <jrandom> mas sim, precisamos de uma simulação para demonstrar como o próprio netDb escala 15:01 <jrandom> cevantes: 0jvf e onb0 15:01 <cervantes> o que explica a queda do vl07 após um dia de tempo de atividade? 15:02 <cervantes> parece cruzar com 00u0 15:02 <jrandom> todos os routers não limitados são essencialmente iguais - estão todos na mesma CPU, todos têm a mesma latência (0ms), então a alocação de um como 'rápido' vs 'confiável' é apenas arbitrária 15:04 <Connelly> suas designações de 'rápido e confiável', 'lento' etc se recuperam de valores grandes? 15:04 <jrandom> por que reduziu sua classificação/uso depois de um dia? não sei, talvez uma sobrecarga transitória de CPU ou E/S durante o teste tenha feito sua velocidade cair um pouco 15:04 <jrandom> sim, os rankings usam a mediana agora, não a média, além de haver um decaimento relativamente rápido nos dados 15:05 <jrandom> s/fiarly/fairly/ 15:05 <Connelly> então se eu fizer você pensar que minha confiabilidade é 1000000000, você consegue se recuperar quando eu começar a descartar mensagens 15:06 <jrandom> certamente - se você 'falhar' eu imediatamente paro de pedir que você faça coisas e diminuo seu ranking 15:06 <jrandom> o novo cálculo de "capacity" por sua vez é bastante sensível a esses tipos de mudanças 15:06 <jrandom> (velocidade também é meio difícil de falsificar, já que todos os ranks de velocidade são valores realmente medidos) 15:07 <jrandom> ((como era a reliability, e como é o cálculo de capacity)) 15:09 <jrandom> ok, mais alguém tem algo que queira trazer? 15:10 <deer> * jrandomi2p sugere o *baf*er 15:11 * jrandom concorda 15:11 * jrandom se prepara 15:11 * jrandom *baf*a a reunião como encerrada