Reunião de Desenvolvedores do I2P - 27 de março de 2007

16:02 <jrandom> 0) oi 16:02 <jrandom> 1) Status da rede 16:02 <jrandom> 2) propostas de NTCP/SSU do zzz 16:03 <jrandom> 3) status do desenvolvimento do Syndie 16:03 <jrandom> 4) status de DNS/registrar 16:03 <jrandom> 5) ??? 16:03 <jrandom> 0) oi 16:03 * jrandom acena 16:03 <jrandom> notas semanais de status publicadas em http://dev.i2p.net/pipermail/i2p/2007-March/001342.html 16:04 <jrandom> passando para 1) status da rede 16:04 <jrandom> as coisas parecem bem boas e, como mencionado, há mais pesquisa a fazer quanto às mudanças mais recentes 16:05 <+Complication> Eu queria reclamar um pouco sobre a conectividade do IRC (o resto parece suficientemente decente), mas no último dia, tive apenas umas 6 desconexões, o que nem é tão ruim 16:05 <cervantes> /mute Complication 16:05 <jrandom> heh 16:05 <+Complication> :D 16:06 <+Complication> O sucesso na construção de tunnel está muito bom, porém 16:06 * Complication confere de novo, por via das dúvidas 16:06 <jrandom> sim, vi um pouco de churn de descons (embora, pra ser sincero, eu leio meu backlog com um grep -v -\!- então nunca vejo as desconexões ;) 16:06 <cervantes> houve várias trapalhadas de ISP recentemente no lado do irc - postman está buscando arranjos alternativos de hospedagem 16:06 <jrandom> as taxas de construção de tunnel nas estatísticas deram uma subida, embora pareçam geralmente em linha com os ciclos lá no stats.i2p 16:06 <cervantes> com sorte conseguiremos alguma redundância de rede melhor 16:06 <jrandom> ah ok cervantes 16:07 * jrandom se ofereceria para ajudar com o dev.i2p.net, mas não lembro a última vez que a carga ficou abaixo de 4 nele 16:08 <jrandom> ok, alguém tem mais algo a trazer sobre o status da rede? 16:10 <jrandom> se não, pulando para 2) propostas de NTCP/SSU do zzz 16:10 <jrandom> zzz não parece estar por aqui no momento, e eu deixei minhas postagens do Syndie respondendo ao tópico em casa (d'oh) 16:11 <jrandom> de qualquer forma, publiquem suas ideias no blog do zzz (ou leiam lá para mais informações) 16:11 <jrandom> alguém tem algo a discutir sobre isso aqui agora? 16:12 <+Complication> Bem, eu pessoalmente escrevi uma resposta lá, expressando preocupação com confiança excessiva em UDP (já que, para mim pessoalmente, UDP tinha taxas de retransmissão bem altas) 16:12 <jrandom> sim 16:12 <+Complication> Contudo, pensei em uma abordagem... 16:12 <+Complication> Atualmente os bids (lances) são totalmente determinísticos (em oposição a probabilísticos com um componente aleatório), certo? 16:13 <jrandom> sim, totalmente determinísticos 16:13 <+Complication> Eu estava pensando se haveria algum benefício (no sentido de evitar extremos) em fazê-los ter um componente de probabilidade 16:14 <+Complication> Como em "60% de probabilidade de conseguir NTCP, 40% de probabilidade de conseguir SSU" 16:14 <+Complication> (assumindo que não haja dados prévios — se houvesse dados prévios de falha/sucesso, provavelmente seria preciso enviesar a probabilidade a favor do transporte de melhor desempenho para aquele link) 16:15 <jrandom> bem, depende do que se pretende alcançar — pelo que entendi da proposta do zzz, o objetivo é usar SSU sempre que possível 16:15 <+Complication> (assumindo, claro, que ambos os transportes sejam utilizáveis para um determinado link — às vezes certamente não são) 16:15 <jrandom> aleatorizar isso não ajudaria com isso, embora oferecesse mais oportunidade para coletar dados sobre ambos os transportes no ambiente real 16:16 <+Complication> Só um pensamento sobre uma forma possível de tentar equilibrá-los (porque se um sempre dá lance mais alto, os routers provavelmente não vão "experimentar" muito) 16:19 <jrandom> é um método que poderíamos usar para reunir mais dados, vale manter em mente 16:19 <jrandom> ok, como mencionado, postem lá naquele tópico para mais coisas :) 16:20 <jrandom> passando para 3) status do desenvolvimento do Syndie 16:20 <jrandom> não tenho muito a acrescentar além do que está no e-mail 16:20 <jrandom> alguém tem perguntas/comentários/preocupações? 16:21 <+Complication> Ainda não. :) 16:22 <jrandom> hehe 16:22 * Complication tem esperança de ajudar mais, seja no I2P ou no Syndie, mas eu realmente preciso lançar aquela coisa do webcache primeiro 16:22 <jrandom> pois é, ansioso por ambos :) 16:24 <jrandom> ok, vamos pular o 4 e ir para 5) ??? 16:25 <jrandom> alguém tem mais alguma coisa que queira trazer para a reunião? 16:26 <TrevorReznik> há algum interesse em um gerador de hashcash para i2p? 16:26 <TrevorReznik> isto é, pela interface do navegador. 16:26 <TrevorReznik> pensei nisso como uma forma de eliminar possíveis cenários de DoS dentro do I2P. 16:27 <jrandom> hmm, em javascript ou c/java? 16:27 <jrandom> acho que há alguns geradores de hashcash por aí 16:27 <TrevorReznik> em java. 16:28 <+Complication> bem, alguma pesquisa sobre esquemas de hashcash provavelmente será necessária em algum momento 16:28 <TrevorReznik> www.hashcash.org tem alguns, acho. 16:28 <TrevorReznik> eles são uma iniciativa para estabelecê-lo para clientes de e-mail como mecanismo anti-spam. 16:28 <+Complication> talvez não pesquisa no sentido propriamente dito, mas sim no sentido de implementação e melhores práticas sese 16:28 <+Complication> =sentido 16:28 <TrevorReznik> eles têm uma coleção de implementações em uma variedade de linguagens. 16:28 <TrevorReznik> há 2 classes Java e pelo menos um applet lá, embora eu não saiba os parâmetros exatos de licença até o momento. 16:30 <+Complication> lugares que poderiam usar isso: 1) registro de nym (pseudônimo) no Syndie 2) registro de nomes no I2P 16:30 <+Complication> 3) e-mail, obviamente 16:30 * TrevorReznik concorda. 16:30 <+Complication> 4) em cenários menos otimistas, mensagens comuns no Syndie 16:31 <+Complication> no próprio nível da rede I2P... 16:31 <+Complication> hmm 16:31 <jrandom> é possível inseri-los nas mensagens de criação de tunnel, mas já estamos ferrados nesse front de CPU do jeito que está ;) 16:39 <jrandom> ok, alguém tem mais alguma coisa para a reunião? 16:41 <jrandom> se não 16:41 * jrandom se prepara para encerrar 16:41 * jrandom *baf* fecha a reunião