Reunião de desenvolvimento do I2P - 20 de dezembro de 2005

15:20 <jrandom> 0) oi 15:20 <jrandom> 1) Estado da rede 15:20 <jrandom> 2) Atualizações do I2PSnark 15:20 <jrandom> 3) Interface de blog do Syndie 15:20 <jrandom> 4) ??? 15:20 <jrandom> 0) oi 15:20 * jrandom acena 15:20 <jrandom> notas semanais de status publicadas em http://dev.i2p.net/pipermail/i2p/2005-December/001240.html 15:22 <jrandom> ok, vamos direto para 1) Estado da rede 15:22 <jrandom> Não tenho muito a acrescentar além do que está nas notas de status. 15:22 <+Complication> Se não fosse pelos OOMs ocasionais, eu até diria que está bom 15:22 <jrandom> os testes de carga estão bem promissores, sugerindo que temos bastante margem para melhorar o desempenho 15:23 <+Complication> E acho que os OOMs 15:23 <jrandom> heh, OOMs relacionados ao i2psnark? ou de antes? 15:23 <+Complication> contribuem para a instabilidade, quando instâncias de i2p-bt, i2psnark ou i2p-rufus fazem... coisas. 15:24 <zzz> minha teoria é que o aumento do tráfego de torrent está prejudicando um pouco a confiabilidade do IRC 15:24 <+Complication> (talvez eu não devesse chamar a estranheza do SAM de OOM, já que não olhei de perto, mas é um dos fatores com certeza) 15:24 <jrandom> hmm, não tenho certeza, pois o estado do irc estava semelhante ao de antes das últimas atualizações do snark 15:25 <+Complication> A largura de banda tem sido sólida, os tunnels participantes sólidos também... só caindo de vez em quando 15:26 <zzz> De qualquer forma, estou otimista de que as correções de construção de tunnel que virão na 0.6.1.8 vão melhorar a experiência de IRC das pessoas 15:26 <+Complication> Por motivos conhecidos, que esperamos que sumam quando chegar a hora :) 15:26 <jrandom> sim, também acho, zzz, então provavelmente teremos um lançamento daqui a um dia ou dois 15:26 <+legion> Bem, o irc pode ser sensível demais, talvez usar algo como jabber fosse melhor? 15:26 <zzz> especialmente para quem tem máquinas e/ou conexões mais lentas 15:27 <jrandom> jabber não mudaria as coisas 15:27 <+Complication> Especialmente com a redundância de tunnel em 2 15:28 <+bar> eu diria que o irc é um excelente cagômetro para determinar o clima da rede 15:28 <+legion> É, o vento sopra um pouco e o irc já pifa 15:28 <+bar> exatamente :) 15:28 <+Complication> Percebo que, depois da correção do 'shitlisting', "Recent" tende a sempre exceder "Known" 15:29 <+Complication> Isso seria porque "Known" não inclui pares 'shitlisted', enquanto "Recent" inclui? 15:29 <jrandom> sim, o irc dá uma boa visão das coisas, pois mostrou variação substancial entre diferentes usuários (por ex., dreamtheaterfan sempre tem problemas, etc.) 15:30 <jrandom> hmm, isso faz sentido, Complication 15:30 <+Complication> (Não tenho certeza se é isso, só supondo) 15:30 <jrandom> (como os pares 'shitlisted' são excluídos do netDb, mas seus perfis não são removidos) 15:32 <+Complication> Então os indicadores parecem OK (só queria perguntar caso não estivessem) 15:33 <jrandom> ok, mais algo em 1) Estado da rede? 15:33 <jrandom> se não, vamos passar para 2) Atualizações do I2PSnark 15:33 <tealc_> que tipo de atualizações estão disponíveis? 15:34 <jrandom> veja http://dev.i2p.net/pipermail/i2p/2005-December/001240.html para uma breve lista ;) 15:34 <jrandom> basicamente, o I2PSnark agora pode lidar com múltiplos torrents ao mesmo tempo sobre um único destino I2P, tem uma interface web e está embutido no console do router 15:35 <tealc_> estou rodando os builds mais recentes do CVS e o i2psnark está causando muitos erros de heap de memória ou algo assim 15:35 <+Complication> ...e também lida com torrents criados pelo Azureus com metatags estranhas. 15:35 <+Complication> Com os quais anteriormente ele travava. 15:35 <jrandom> ah, sim, ainda há algumas coisas que estou depurando ali, tealc_ 15:35 <jrandom> (como mencionado nas notas de status semanais ;) 15:35 <jrandom> ah, verdade, Complication 15:36 <jrandom> ah, também, o pessoal do Azureus corrigiu um bug no tracker deles que impedia o I2PSnark de usá-lo 15:36 <jrandom> (então quem estiver rodando trackers do azureus anteriores ao B16 deve atualizar assim que possível) 15:37 <+bar> eu gostaria de ter a possibilidade de desativar facilmente o autostart do i2psnark (para cenários de baixa largura de banda, etc.) 15:38 <jrandom> isso deve ser fácil de adicionar 15:38 <+bar> parece ótimo 15:39 <jrandom> ok, mais algo em 2) Atualizações do I2PSnark? 15:40 <jrandom> se não, vamos passar para 3) Interface de blog do Syndie 15:40 <zzz> dois polegares para cima pelo novo i2psnark - bom trabalho 15:41 <jrandom> gracias, o mjw fez o trabalho pesado, tornando o snark tão fácil de estender 15:41 <jrandom> ok, como mencionado nas notas de status, o syndie agora tem uma nova UI de blog 15:42 <jrandom> Acho que isso vai oferecer um equilíbrio entre listas brancas e listas negras, lidando com os diferentes problemas de spam que as pessoas enfrentam 15:43 <jrandom> vamos lançar isso no próximo release, para que vocês possam explorar em um dia ou dois 15:43 <+legion> O spam realmente vai se tornar um grande problema em breve? 15:44 <+Complication> legion: como alguém teve a gentileza de demonstrar, pode ser 15:44 <jrandom> nah, as listas negras cuidam dos autores que fazem flood, e as listas brancas cuidam dos spammers que criam muitos autores 15:44 <dust> (o anonimato traz à tona o pior em algumas pessoas) 15:44 <jrandom> (então spam não é um problema) 15:45 <+Complication> (Embora eu ache que o sujeito estava regenerando chaves para evitar uma lista negra permanente, o que até causa uma certa lentidão.) 15:45 <+Complication> Embora não seja uma grande lentidão, e por isso concordo de coração que listas brancas também são boas. :) 15:46 <+bar> talvez alguma solução de hashcash possa ser viável mais adiante, se necessário 15:46 <jrandom> se necessário, mas não vejo por que seria 15:46 <+bar> concordo, por enquanto eu também não 15:46 <+Complication> bar: tipo "não mostrar a menos que tenham se dado ao trabalho de calcular alguma coisa"? 15:47 <+bar> sim, algo nessa linha 15:47 <+Complication> Parece possível, embora provavelmente desnecessário. 15:47 <+bar> provavelmente. 15:47 <jrandom> se um conjunto de spammers estivesse fazendo flood com muitos autores novos o tempo todo, as pessoas ainda poderiam contar a outras sobre autores novos publicando seus favoritos e referências de blogs no próprio blog 15:47 <+Complication> Ou melhor, tomara que desnecessário. 15:48 <+Complication> Pode ser bom considerar se o Syndie consegue acomodar tal funcionalidade, caso surja a necessidade. 15:49 <jrandom> sim, consegue, com cabeçalhos no post do blog ou na própria metainfo do blog 15:49 <jrandom> quer dizer, metadata (maldito bt!) 15:51 <jrandom> ok, se não há mais nada em 3) Syndie, vamos pular para 4) ??? 15:51 <jrandom> alguém tem mais alguma coisa que queira trazer para a reunião? 15:51 <+legion> sim, algumas coisas 15:52 <+legion> primeiro, clunk 15:52 <jrandom> legal, sim, clunk parece interessante 15:52 <+legion> Como mencionei hoje mais cedo no i2p-chat, tenho trabalhado para fazê-lo compilar com Cygwin e/ou MinGW. 15:53 <+legion> Até agora só o cliente está com problemas; o resto, incluindo o servidor, compila e parece funcionar 15:53 <jrandom> bacana 15:54 <tealc_> i2p pode acabar sendo uma bela pedra no sapato do programa de vigilância sem limites do George Bush. Vejo vocês nos campos de extermínio, tragam as cartas, tá? 15:54 <+legion> Tenho tentado não só descobrir por que o cliente está com problemas, mas também resolvê-lo. No momento estou empacado. 15:56 <+legion> A outra coisa que eu queria discutir: poderia ser incluído um tunnel padrão para o meu servidor jabber na próxima atualização? Só para facilitar para quem quiser experimentar jabber. 15:57 <tethra> 20:34:37 <jrandom> se um conjunto de spammers estivesse fazendo flood com muitos autores novos o tempo todo, as pessoas ainda poderiam contar a outras sobre autores novos publicando seus favoritos e referências de blogs no próprio blog <--- talvez algo no sentido da forma do polecat de combinar confiança pudesse ter um papel nisso? (isto é, tanto para bloquear spammers -e- promover autores populares.) 15:57 <tethra> </$0.02> 15:58 <+polecat> Isso seria um exemplo primitivo da minha ideia de rede de confiança, com uma heurística de 100% de transferência de confiança, sim. 15:58 <jrandom> legion: hmm, adicionar uma config desativada é fácil para novos usuários, mas a hesitação que tenho é em relação à filtragem de protocolo (e que informação cada cliente vaza). qual é a sua experiência com diferentes clientes? 15:59 <jrandom> sim, há muito espaço para integrar métricas de confiança no syndie 16:01 <+legion> Bem, até onde sei, o jeti não vaza, exceto sua transferência de arquivos, que está desativada nas configurações do meu servidor de qualquer forma. Possivelmente a próxima versão do jeti vai corrigir isso. Fora isso, não sei sobre os outros clientes. 16:02 <+legion> Sei com certeza que o bate-papo em grupo é sólido, independentemente dos clientes; é só o contato fora do bate-papo em grupo que alguns clientes podem vazar, embora eu não tenha certeza. 16:03 <jrandom> hmm, vazamento não é exatamente um booleano, é uma questão de /que informação/ os clientes vazam, não se vazam alguma informação 16:04 <+legion> Certo, eu estava me referindo a informações críticas como endereços IP, embora bons clientes, se vazarem essa informação, deveriam relatá-la apenas como 127.0.0.1 ou localhost 16:06 <+legion> Então eu recomendaria usar apenas clientes conhecidos que não vazam, como o jeti. 16:07 <zzz> você poderia adicionar uma coluna 'verificado-não-vaza' à sua tabela de clientes? 16:07 <jrandom> seria útil se você pudesse documentar o que o jeti vaza e o que não vaza (nos moldes do que o postman montou para o proxy SMTP e POP) 16:08 <+legion> Segundo o desenvolvedor do jeti, ele não vaza nada que comprometa a anonimidade. Isso é certo, sem dúvida. Eu também examinei o código-fonte e não encontrei nada que me fizesse pensar o contrário. 16:09 <jrandom> que o desenvolvedor tenha dito isso pode ser certo, mas o que o desenvolvedor entende por anonimato é outra questão ;) 16:09 <+legion> Sim, zzz, eu poderia adicionar mais uma coluna dessas 16:09 <jrandom> Não duvido da possibilidade de que o jeti se comporte corretamente, mas precisamos saber o que isso significa 16:10 <zzz> parece que a não-existência de vazamento só pode ser verificada por rastreamento do protocolo 16:10 <zzz> não olhando o código-fonte ou perguntando ao desenvolvedor 16:12 <jrandom> ok, alguém tem mais algo para a reunião? 16:12 <+bar> só um lembrete para não esquecer o jbigi amd64 16:13 <+bar> (mas aposto que está na sua lista de tarefas) 16:13 <jrandom> sim :) 16:13 <jrandom> (Windows amd64, isto é, Linux amd64 já está funcionando) 16:13 <jrandom> mas, se não há mais nada... 16:14 * jrandom vai encerrando 16:14 <+bar> sim, Windows amd64. 16:14 * jrandom *baf* encerra a reunião