Reunião de desenvolvimento do I2P - 28 de dezembro de 2004

13:06 <@jrandom> 0) oi 13:06 <@jrandom> 1) 0.4.2.5 13:06 <@jrandom> 2) 0.5 13:06 <@jrandom> 3) ??? 13:06 <@jrandom> 0) oi 13:06 * jrandom acena 13:06 <+postman> *aceno* 13:06 <ant> <jnymo> olá 13:06 <@jrandom> notas breves de status publicadas em @ http://dev.i2p.net/pipermail/i2p/2004-December/000535.html 13:07 <@jrandom> vamos pular para 1) 0.4.2.5 13:07 <@jrandom> como mencionado, as coisas estão basicamente funcionando 13:08 <+postman> sim, bastante impressionante 13:08 <+postman> sem mais timeouts de lease nos meus sistemas 13:08 <@jrandom> muita gente viu o que você viu, jnymo, com 0 tunnels participantes, em grande parte devido ao aumento da eficiência e à seleção de pares (onde agora sabemos sugar da máquina do postman ;) 13:08 <ant> <jnymo> eu também 13:08 <@jrandom> legal 13:08 <ant> <jnymo> e as eepsites estão rápidas 13:09 <+postman> :) 13:09 <ant> <jnymo> valeu, postman :) 13:09 <+postman> largura de banda total é 29kb / 30.1kb/s 13:09 <frosk> todo mundo se sente menos amado, mas na realidade o amor está sendo colocado para trabalhar de forma mais eficiente 13:10 <ant> <jnymo> uau 13:10 <@jrandom> irado, postman 13:10 <mule2> não acho que esse seja o ideal. é melhor termos algum tráfego passando por todos os nós 13:10 <ant> <jnymo> eu lidaria com isso se as pessoas apenas me amassem :( 13:10 <+postman> sim 13:10 <mule2> como uma espécie de tráfego de cobertura 13:10 <@jrandom> mule2: é uma questão de nossa carga ser muito menor do que a capacidade da rede 13:11 <@jrandom> não acho que conseguiremos manter a capacidade maior que a carga por muito tempo 13:11 <ant> <jnymo> mule2, o postman também age como um mixer.. então é difícil dizer para onde seus pacotes vão depois que entram 13:11 <@jrandom> então não me preocupo muito em não empurrar dados por pares mais lentos 13:12 <mule2> provavelmente uma otimização menos perfeita seria boa para o anonimato 13:12 <@jrandom> por outro lado, isso também incentiva mais pessoas a (implementar &) usar i2pcontent, para que possam espelhar e também ganhar tráfego de cobertura ;) 13:12 <jdot__> é um problema de segurança um router lidar com todos (mais ou menos) os tunnels? 13:13 <@jrandom> mule2: vamos primeiro deixá-lo o melhor possível, depois podemos discutir piorá-lo proativamente 13:13 <@jrandom> jdot__: não temos um router lidando com todo o tráfego, mas estamos vendo o agrupamento de routers que estão em conexões muito rápidas (colo, etc.) lidando com mais do que usuários de dialup/dsl/cable 13:14 <@jrandom> além disso, a redução nas falhas de tunnel significa que estamos trocando e explorando menos 13:14 <mule2> talvez alguma distribuição de tráfego seria possível, desde que estejamos longe dos limites dos routers 13:14 <@jrandom> certo, a rejeição probabilística de tunnel está no router e pode ser habilitada com base nos limites de largura de banda do router 13:15 <ant> <jnymo> sim, mas um throughput tão alto no nó do postman torna mais difícil analisar o nó dele.. então pode ser mais seguro enviar por ele do que todos os nós fazerem 1 KB/s.. 13:15 <@jrandom> (mas se o postman não definir nenhum limite, não podemos rejeitar com base em uma % disso ;) 13:15 <ant> <jnymo> agrupamentos de nós mais rápidos causam uma espécie de estrutura de cascata de mix, não? 13:15 <@jrandom> sim, é uma forma de ver 13:15 <lektriK> posso fechar a janela Start I2P? 13:15 * postman sente muito por NÃO restringir sua largura de banda 13:16 <@jrandom> lektriK: infelizmente, não muito, a menos que você inicie o i2p como um serviço (Veja http://localhost:7657/configservice.jsp) 13:16 <@jrandom> heh postman não se preocupe, vamos aliviar seu router se/quando atingirmos a capacidade do seu router 13:17 <lektriK> Ok, diz serviço iniciado 13:17 <lektriK> posso fechar agora? 13:17 <@jrandom> lektriK: não/sim - você pode desligar seu router e então iniciá-lo de novo via start->run->"net start i2p" 13:18 <mule2> do jeito que está, alguns routers muito grandes poderiam lidar com todos os tunnels, removendo todo o tráfego de cobertura de todos os outros routers. mas vamos continuar com isso depois da reunião. 13:18 <mule2> não quero reclamar da rede se comportando bem demais :) 13:18 <@jrandom> hehe 13:20 <@jrandom> alguma exploração adicional vai ocorrer com a 0.5, embora haja questões relacionadas ao anonimato ao espalhar demais. haverá mais detalhes a serem trabalhados nisso para a 0.5 (e no documento que pode ficar pronto semana que vem como um primeiro rascunho) 13:21 <@jrandom> de qualquer forma, mais alguém tem algo para levantar sobre 0.4.2.5? 13:21 <@jrandom> ou devemos passar rapidamente para 2) 0.5? 13:21 <+postman> seguir 13:21 <ant> <jnymo> muito estável... seguimos 13:21 <@jrandom> considere-nos movidos 13:22 <@jrandom> 2) 0.5 13:22 <@jrandom> sim. ainda em andamento. mais informações quando estiver pronto. 13:22 <ant> <Quadn-werk> Sir Arthur C. Clarke está vivo :P 13:22 <ant> <Quadn-werk> http://slashdot.org/articles/04/12/28/0120240.shtml?tid=99&tid=1 13:22 <ant> <jnymo> .5 é empolgante 13:22 <@jrandom> ok, isso é tudo que tenho a dizer sobre isso - alguém tem perguntas / coisas para discutir? 13:23 <@jrandom> sim, definitivamente há algumas reformulações importantes acontecendo, baseadas no que aprendemos nos últimos 16 meses 13:23 <@jrandom> (ou droga, 18) 13:23 <+postman> jrandom: então 0.5 vai empregar principalmente um novo sistema de gerenciamento de tunnel? 13:23 <ant> <Quadn-werk> arg, espero não ter interrompido a reunião :/ 13:23 <+postman> uau 13:23 <ant> <Quadn-werk> foi mal heh 13:23 <ant> <jnymo> heh. eu tinha uma sugestão 13:24 <@jrandom> sim, postman, novo gerenciamento, pooling e construção 13:24 <+postman> quadn: olha o que você fez - seu paste causou um netsplit :) 13:24 <@jrandom> seu bastardo! 13:24 <ant> <Quadn-werk> ! 13:24 <@jrandom> e aí, jnymo? 13:24 <+postman> jrandom: cada tunnel ainda será um Destination local separado? 13:25 <@jrandom> huzzawuzzah? 13:25 <@jrandom> não haverá nenhuma mudança no i2ptunnel na 0.5 13:25 <+postman> jrandom: ok 13:25 <@jrandom> (pelo menos, não planejo nenhuma) 13:26 <mule> postman montando um ataque de interseção? 13:26 <ant> <jnymo> para quem não está tendo /nenhum/ uso de largura de banda.. que tal deixar os routers construir tunnels com eles no meio.. tipo ABCABCA 13:26 <+postman> mule: não, a culpa foi do quadn :) 13:26 <ant> <jnymo> e isso seria um tunnel fictício 13:27 <@jrandom> jnymo: anunciar um router dizendo "ei, eu tenho largura de banda sobrando, use-me" é um jogo perigoso 13:27 <+postman> jrandom: quais questões serão tratadas pela reformulação (em poucas palavras) 13:27 <ant> <jnymo> não sei se foi isso que eu quis dizer, jrandom 13:27 <@jrandom> mas pelo que parece agora teremos dois conjuntos de tunnels - os normais, e os exploratórios, onde os últimos são construídos a partir de pares selecionados aleatoriamente que não estão falhando 13:28 <ant> <jnymo> jrandom: eu quis dizer criar um tunnel fictício, e me colocar no meio desse tunnel só para simular algum tráfego 13:29 <@jrandom> postman: tornando muito mais difícil correlacionar pares em um tunnel, permitindo que clientes escolham efetivamente o comprimento do seu tunnel de saída, e fornecendo as opções necessárias para lidar com o ataque de predecessor (com vários trade-offs) 13:29 <@jrandom> (ah, e melhorando o desempenho eliminando muitas chamadas de modPow) 13:29 <+postman> ok obrigado 13:29 <ant> <jnymo> postman: e IDs de tunnel por salto é uma grande 13:30 <+postman> modpow? 13:30 <@jrandom> ah jnymo. sim, há muito potencial para várias gerações de tráfego chaff (ruído) 13:30 <ant> <jnymo> dessa forma, dois nós não vizinhos não podem saber que estão no mesmo tunnel, postman 13:30 <@jrandom> postman: exponenciação modular, uso pesado de CPU e desperdício de memória 13:31 <ant> <jnymo> jrandom: ok, legal 13:31 <+postman> ok 13:31 <scintilla> jrandom, com relação a permitir que clientes escolham o comprimento do tunnel: haverá algo para impedir as pessoas de aumentarem isso para 99 (ou o que for)? 13:31 <ant> <jnymo> poder de CPU 13:32 <@jrandom> quando necessário podemos adicionar hashcash, mas tunnels excessivamente longos acabarão falhando mesmo assim 13:32 <scintilla> ah, bom ponto 13:32 <@jrandom> podemos até adicionar um truquezinho - exigir que um tunnel tenha uma mensagem de tunnel válida bombeada através dele dentro de 60s da criação para que seja 'válido' 13:33 <@jrandom> (então se o tunnel tiver 20 saltos, eles levariam tempo demais para construir todos esses saltos) 13:33 <scintilla> ótima ideia - isso vai impedir que esse tipo de absurdo perdure por muito tempo 13:33 <@jrandom> mas isso é tudo contra os hackers. usuários normais apenas usarão a interface exposta 13:34 <ant> <jnymo> certo, que você vai limitar em algum lugar, certo? 13:34 <ant> <jnymo> vamos ter mais do que o máximo 2 como é agora, certo? 13:34 <@jrandom> certo, como o menu suspenso de # de saltos em /configclients.jsp ou /i2ptunnel/edit.jsp 13:35 <@jrandom> ah achei que o máximo fosse 3 agora? ok, mas sim, maior que 2 estará disponível 13:35 <ant> <jnymo> 3 tunnels, 2 saltos 13:35 <@jrandom> ah 'k 13:35 <@jrandom> sim, a 0.5 vai adicionar alguns novos ajustes importantes, como se deve aleatorizar esses comprimentos, bem como quanto aleatorizar, etc. 13:36 <frosk> o máximo é de fato 3 13:36 <ant> <jnymo> hmm 13:37 <@jrandom> ah é 3 em /configclients 2 no i2ptunnel 13:37 <frosk> 0.5 ainda está previsto para janeiro? 13:37 <ant> <jnymo> ah 13:37 <@jrandom> sim, frosk 13:37 <frosk> boa 13:37 <@jrandom> não vou enrolar muito mais na biblioteca de streaming, prometo ;) 13:37 <frosk> parece muito trabalho :) 13:38 <@jrandom> na verdade não é tão ruim, a parte difícil é acertar os algoritmos 13:38 <@jrandom> (detalhes, schmetails ;) 13:39 <+postman> frosk: e já está tudo no papel 13:39 <+postman> :) 13:39 <ant> <jnymo> heh 13:39 <frosk> verdade :) 13:39 <@jrandom> em sua maioria, sim ;) 13:39 <@jrandom> ok, alguém tem mais algo para 2) 0.5? 13:39 <ant> <jnymo> nada 13:39 <frosk> el zilcho 13:40 <@jrandom> 'k, passando para o bom e velho 3) ??? 13:40 <@jrandom> oi 13:40 <@jrandom> alguém tem mais alguma coisa que queira trazer? 13:41 <ant> <jnymo> postman: não há inproxies de SMTP/POP3 em i2pmail.org, há? 13:41 <cat-a-puss> Ainda estou vendo atrasos estranhos no lado do cliente... 13:41 <+postman> hmm não 13:41 <frosk> é aqui que eu entregaria a garrafa de vinho de congratulações por um ótimo ano de desenvolvimento ;) 13:41 <+postman> jnymo: POP3 está disponível apenas para usuários de i2p 13:41 <@jrandom> cat-a-puss: ah perdi essas mensagens quando você esteve aqui antes 13:41 <+postman> jnymo: há um inproxy de SMTP como MX para o domínio i2pmail.org 13:42 <@jrandom> frosk: saúde 13:42 <ant> <jnymo> certo, certo.. isso é legal.. 13:42 <cat-a-puss> Tipo, posso ter duas Destinations locais e quando uma tenta se conectar à outra há um atraso e não é limitado por CPU 13:42 <mule> cat-a-puss: você também entrega o cheque bônus? 13:42 * postman doa um bom uísque 13:42 <@jrandom> cat-a-puss: certo, você viu um atraso de .5-1.0s, certo? 13:42 <cat-a-puss> mule: o quê? 13:42 <cat-a-puss> jrandom: sim 13:43 <@jrandom> cat-a-puss: perfeitamente normal, parte do SYN adiado 13:43 <mule> desculpa, o comentário foi do frosk 13:43 <ant> * jnymo tira aquele vinho de caixa ruim 13:43 <mule> frosk: você também entrega o cheque bônus? 13:43 <@jrandom> (ele espera um pouco para enviar o SYN e o ACK relacionado caso haja mais dados para agrupar) 13:43 <scintilla> ah, para sua informação, devo receber em breve o livro com a especificação do algoritmo Fortuna... enquanto isso venho experimentando como coletar entropia em Java sem destruir uma máquina 13:44 <@jrandom> ah sensacional 13:44 <ant> <jnymo> mmm, alguém estava querendo montar alguns ataques no i2p 13:44 <ant> <jnymo> quem foi? 13:44 <@jrandom> connelly 13:44 <cat-a-puss> Há como evitar isso, ou eu só tenho que tentar evitar conexões de curta duração onde der? 13:45 <ant> <jnymo> alguma novidade sobre isso, jr? 13:45 <@jrandom> cat-a-puss: sim, há algumas opções que você pode passar ao criar o I2PSocketManager, deixa eu pegar aqui 13:46 <@jrandom> jnymo: é um ataque de interseção de longo prazo, então depois de um tempo ele terá dados para ajudar a identificar em quais routers determinadas eepsites estão. tenho certeza de que ele vai escrever alguns dados de resumo para nós assim que tiver 13:46 <ant> <jnymo> scintalla: o que é o algoritmo Fortuna? 13:46 <ant> <jnymo> jrandom: certo 13:48 <@jrandom> cat-a-puss: i2p.streaming.initialResendDelay=50 i2p.streaming.connectDelay=100 13:48 <scintilla> é um gerador de números pseudo-aleatórios criptograficamente seguro... algo absolutamente essencial para criptografia confiável 13:48 <jdot__> alguém já se voluntariou para esse ataque? 13:48 <@jrandom> cat-a-puss: então certifique-se de chamar flush() depois de write() no I2PSocket 13:48 <@jrandom> jdot__: sim, ele tem 7 sites voluntários 13:48 <cat-a-puss> jrandom: ok 13:49 <ant> <jnymo> com relação ao grande debate sobre nomes.. 13:49 <ant> * jnymo dá uma risadinha 13:49 <@jrandom> oh e i2p.streaming.initialAckDelay=1000 13:49 <@jrandom> ou até =100 13:49 * jrandom atira lama em jnymo 13:50 <ant> <jnymo> na verdade eu trabalho com x500 e meu trabalho me permite ter winSevers grátis 13:50 <ant> <jnymo> então, talvez eu apenas configure um DNS central para fins de teste em um mês ou dois 13:51 <@jrandom> heh, ter um servidor centralizado de nomes hospedado em um .mil seria hilariamente engraçado 13:51 <ant> <jnymo> embora enfiar endereços i2p no winserver possa não ser trivial.. não sei 13:51 <ant> <jnymo> heh.. dnsalias é o caminho 13:52 <@jrandom> nano fez um trabalho muito legal, integrando dnsjava com i2p 13:52 <ant> <jnymo> ooooh 13:53 <@jrandom> veja nano.i2p para mais detalhes 13:53 <ant> <jnymo> e ninguém ia me contar.. ah, valeu 13:53 <@jrandom> mas, como mencionado da última vez, as pessoas devem postar seus pensamentos e ideias sobre nomes na wiki 13:54 <@jrandom> ok, alguém mais tem algo para trazer para a reunião? 13:55 <ant> <jnymo> não 13:57 <@jrandom> ok, nesse caso 13:57 * jrandom se prepara 13:57 * jrandom encerra a reunião com um *baf*