Reunião de desenvolvedores do I2P - 17 de janeiro de 2006

15:40 <jrandom> 0) oi 15:40 <jrandom> 1) Status da rede e 0.6.1.9 15:40 <jrandom> 2) Criptografia de criação de tunnel 15:40 <jrandom> 3) blogs do Syndie 15:40 <jrandom> 4) ??? 15:40 <jrandom> 0) oi 15:40 * jrandom acena 15:40 <jrandom> notas de status semanais publicadas @ http://dev.i2p.net/pipermail/i2p/2006-January/001251.html 15:41 <@cervantes> pfff, ainda bem que o I2P é mais confiável que a NASA 15:41 <jrandom> hehe 15:41 <tethra> haha 15:41 <jrandom> (embora eu esteja 20 minutos atrasado... ;) 15:41 <jrandom> enfim, vamos direto para 1) Status da rede e 0.6.1.9 15:42 <wmpq> NSA ou NASA, não são tão diferentes, né? 15:42 <@cervantes> Eu disse I2P, não jrandom ;-) 15:42 <jrandom> bem observado, cervantes ;) 15:42 <tethra> não seja bobo, jrandom É o i2p! ;D 15:42 <@cervantes> ah, achei que era um modo de pensar 15:42 <wmpq> [redact] 15:43 <jrandom> hehe bem, de qualquer forma, 0.6.1.9 já está na praça, com 70% da rede atualizada (valeu, pessoal) 15:43 <Pseudonym> hmmm, nova versão saborosa 15:44 <+zzz> o sucesso de construção de tunnel do cliente permanece <30% 15:44 <jrandom> não ouvi muitos relatos de aumento substancial de throughput ponta a ponta, embora alguns routers estejam mais do que saturando linhas T1 15:44 <+zzz> abaixou de ~40% 15:44 <+Complication> A largura de banda parece normal, um pouco maior do que no último CVS antes do lançamento. As contagens de pares parecem um pouco maiores. 15:45 <jrandom> hmm, é, não estou muito preocupado com isso, zzz, já que tudo isso será completamente refeito para a 0.6.2 15:45 <+zzz> Largura de banda média subiu de ~12K para ~20K 15:45 <jrandom> 0.6.1.9 não deve escolher pares mais propensos a concordar (isto é, de alta capacidade), mas sim focar naqueles com throughput mais alto 15:46 <+Complication> A porcentagem de retransmissão (notei 7% na noite do lançamento) caiu para 6 e alguma coisa 15:46 <jrandom> pois é, com routers chegando a 1–300 KB/s, vai haver um viés 15:46 <jrandom> hmm, essa é uma taxa bem louca, Complication, eu só vi 2–3% 15:46 <jrandom> (mas não duvido do que você está vendo) 15:47 <+Complication> estou praticamente saturando meu upstream 15:47 <+Complication> (e quero dizer a capacidade total da linha) 15:47 <jrandom> ah, isso explicaria 15:47 <+zzz> ainda recebendo NULLs antes dos GETs, o que resulta em 405 bad method; a taxa pode estar diminuindo, difícil afirmar com certeza 15:48 <jrandom> sim, zzz, há algumas coisas a resolver na biblioteca de streaming, mas provavelmente só vou mexer nisso depois das reformulações de tunnel da 0.6.2 15:48 <jrandom> (mas se alguém quiser se aprofundar nisso antes, seria demais, claro) 15:49 <jrandom> Complication: se você reduzir seu limitador de bandwidth para algo como 70% da capacidade da sua linha, a taxa de falhas volta para um valor razoável? 15:49 <+zzz> Ainda acho que foi algo que entrou no código pouco antes do Ano‑Novo, então é melhor olhar isso antes que essas mudanças recentes sejam esquecidas :) 15:50 <+zzz> Visto pela primeira vez em 29 de dez. 15:50 <jrandom> sim, zzz, certamente foi. provavelmente relacionado a como agora respeitamos timeouts. 15:51 <+Complication> jrandom: na verdade estou testando isso agora :) 15:51 <+Complication> Ajustei alguns segundos antes de você perguntar, mas acho que não saberei tão cedo 15:51 <jrandom> mas há bastante trabalho a fazer ali para limpar tudo, e é mais importante implementar o novo código de criação de tunnel (o que vai melhorar substancialmente as taxas de sucesso de construção de tunnel, além de adicionar um conjunto inteiro de melhorias de anonimato) 15:51 <jrandom> legal, Complication, sim, dê de 3 a 6 horas 15:51 <jrandom> (para limpar os valores/conexões antigos) 15:52 <+zzz> ~1%–3% dos GETs estão corrompidos no momento 15:54 <jrandom> então você sugere reverter as mudanças na biblioteca de streaming (para que o i2psnark dê OOM em todos os seus usuários em 12–48 horas) e adiar mais retrabalho da biblioteca de streaming até depois do trabalho nos tunnels da 0.6.2, ou adiar o trabalho dos tunnels da 0.6.2 por uma ou duas semanas enquanto reformulamos a biblioteca de streaming? 15:55 <+zzz> com certeza, não reverta 15:56 <+zzz> você decide 15:56 <+Complication> É um bug bem sorrateiro, só posso dizer isso 15:58 <jrandom> há outros bugs na biblioteca de streaming, então se eu for arregaçar as mangas, gostaria de enfrentá‑los todos juntos (já que nenhum dos bugs restantes é aparente). 15:59 <jrandom> por outro lado, teremos uma redução substancial do uso de largura de banda, aumento do percentual de sucesso de construção, melhor anonimato e uma capacidade aprimorada de monitorar o balanceamento de carga na rede ao vivo se formos primeiro com o trabalho de tunnel 15:59 <Pseudonym> se for só uma taxa de falhas de 1–3% na navegação, eu diria que pode esperar, mas é só a minha opinião. 16:00 <jrandom> estou inclinado a fazer primeiro o trabalho de tunnel, já que, depois de implantá‑lo, podemos monitorar a rede passivamente enquanto reformulamos ativamente a biblioteca de streaming 16:01 <jrandom> (eu também gostaria de construir uma GUI para editar/publicar no Syndie, mas isso pode esperar até que ambas as coisas estejam resolvidas ;) 16:01 <+Complication> Essa é a taxa por aqui também 16:02 <+Complication> (no meu eepsite) 16:04 <jrandom> Ok, acho que seria ótimo se vocês pudessem ficar de olho para ver se essas taxas mudam, mas, enquanto isso, vou continuar com a reformulação de tunnel, após a qual virá a reformulação da biblioteca de streaming (ambas estarão em vigor antes da 0.6.2) 16:05 <jrandom> (ou, se alguém quiser se aprofundar na biblioteca de streaming [ou ver se há alguma interação estranha com i2ptunnel], me avise!) 16:06 <+Complication> jrandom: por curiosidade, daria para excluir o i2ptunnel com um app de teste? 16:07 <+Complication> por exemplo, se algo como o app de exemplo do jnymo também recebesse nulls, isso tiraria o i2ptunnel da lista de causas suspeitas? 16:07 <jrandom> daria para conectar uma implementação leve (em VM) de I2PSocket para fazer isso, com certeza 16:07 <+Complication> Já que, se não me engano (IIRC), aquele exemplo usava diretamente a biblioteca de streaming... 16:08 <+Complication> (ou quase diretamente) 16:08 <jrandom> pois é, claro, se algo usando a biblioteca de streaming puder reproduzir isso, inocentaria o i2ptunnel 16:10 <+Complication> Hmm, a menos que alguém chegue primeiro (vou tentar terminar aquela parada do webcache antes), talvez eu tente emular HTTP com algo assim... 16:10 <jrandom> irado, valeu, Complication 16:10 <jrandom> ok, mais alguma coisa em 1) Status da rede e 0.6.1.9? 16:11 <jrandom> se não, vamos dar um pulo em 2) Criptografia de criação de tunnel 16:11 <+Complication> Nah, pode não levar a nada útil, ou posso tropeçar no meio do caminho... mas é uma possibilidade que me intriga 16:11 <jrandom> pois é, definitivamente vale explorar, Complication 16:12 <jrandom> (e explorações não precisam ter resultados positivos para valer a pena :) 16:12 * cervantes encontra uma exceção “moo” nas mudanças de fonte antes do Ano‑Novo... talvez seja isso? :) 16:13 <jrandom> ok, há uma nova especificação de criptografia de criação de tunnel referenciada no e‑mail, baseada na discussão que toad, Michael e eu tivemos na lista de correio em outubro passado 16:14 <jrandom> dá uma olhada e me diga o que acham – não será implantada na rede ao vivo por um tempo, pois há outras coisas que precisam ser implementadas primeiro, mas está chegando 16:14 <+Complication> “moo” é uma palavra reservada em Java? ;P 16:14 <+zzz> sobre o 2) vou ajudar a revisar as referências no e‑mail de status 16:14 <+Complication> Sobre o assunto de criptografia de tunnel, se importa de verificar se a reformulação abaixo é decente? Só gostaria de garantir que entendi direito... 16:14 <jrandom> obrigado, zzz 16:15 <+Complication> "Cada salto cifra todos os registros com sua reply key, que eles decifraram a partir de seu registro, usando sua chave privada ElGamal, e ao cifrar dessa forma, reverte uma camada de decifragem (ou devo dizer, cifragem) feita pelo dono do tunnel, tornando o registro do próximo participante legível com a chave privada ElGamal do próximo participante?" 16:15 <jrandom> Complication: sim 16:15 <+Complication> Ou a minha reformulação está simplesmente errada? 16:16 <+fox> <jme___> e muito complicada, se me permitem 16:16 <jrandom> está correta, acredito, mas sim, cláusulas demais :) 16:16 <+Complication> Não pensei em uma forma melhor de visualizar. Já foi difícil assim. :P 16:16 <jrandom> (ou jme___, você está dizendo que o algoritmo é complicado demais?) 16:17 <+fox> <jme___> não, tentei ler rapidamente a doc e desisti, pois muitas coisas exigem conhecimento prévio 16:17 <+fox> <jme___> por outro lado, não tentei muito :) outras coisas a fazer 16:17 <jrandom> Complication: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/java/src/net/i2p/router/tunnel/BuildMessageProcessor.java?rev=HEAD 16:18 <+fox> <jme___> esta revisão por pares é uma formalidade, ou você está realmente preocupado/incerto quanto a isso? 16:19 <+Complication> Bem, é sempre bom saber o que o mecanismo subjacente está fazendo... 16:19 <jrandom> Estou confiante de que faz o que pretendo, mas estou sinceramente interessado se alguém enxergar um problema 16:19 <+fox> <jme___> se for a segunda, eu poderia dedicar tempo, mas meu conhecimento é antigo e não está fresco 16:20 <+fox> <jme___> se não, confio :) 16:20 <jrandom> a seção de notas tem algumas questões - http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.notes 16:22 <jrandom> não há pressa, provavelmente levará uma ou duas semanas até que essa nova criptografia seja realmente usada no router 16:22 <@cervantes> jrandom: sobre isso, haveria muito impacto de desempenho ao injetar um atraso aleatório entre os saltos? 16:22 <@cervantes> já que essa parece a opção mais sensata para prevenir ataques de temporização 16:23 <jrandom> é criação de tunnel, então um atraso não faria mal, embora possa causar expiração prematura do lease set em falhas catastróficas 16:25 <jrandom> bem, não sei quão eficazes seriam esses atrasos. podem ajudar bastante, como podem não ajudar. porém, tunnels ativos podem simplesmente usar blending para detectar pares em conluio nesse tunnel de qualquer forma, então não sei se importa 16:25 <+fox> <jme___> ok, relendo 16:27 <jrandom> valeu. ok, sem pressa, mas se/quando alguém tiver alguma ideia, mandem para mim (ou para a lista, ou para o seu blog, etc.) 16:27 <jrandom> ok, mais algo sobre o 2, ou vamos para 3) blogs do Syndie? 16:29 <jrandom> (considerem-nos lá) 16:29 <jrandom> ok, coisas novas legais de blog no Syndie, mandem ver ;) 16:29 <@cervantes> muito legal 16:30 <jrandom> os grupos à esquerda podem conter links para URLs arbitrárias, bem como links para blogs, posts dentro de blogs ou anexos a posts dentro de blogs 16:30 <jrandom> há uma porção de melhorias possíveis também, como adicionar estilos por blog ou por tag para posts, ícones, etc. se alguém quiser mexer nisso, seria ótimo (e teria um impacto bem visível :) 16:31 <@cervantes> a propósito, links externos definidos nos comentários também deveriam ter um atributo title definido para a URL de destino (como você fez no painel esquerdo) 16:31 <@cervantes> comentários/posts 16:32 <jrandom> ah, boa ideia 16:33 <jrandom> (net.i2p.syndie.sml.BlogPostInfoRenderer method renderLinks(...) :) 16:34 <@cervantes> *rabisco* 16:35 <jrandom> o que mais os blogs do Syndie precisam para oferecer uma alternativa funcional aos eepsites informativos? obviamente, Syndie é conteúdo estático, então você não pode fazer algumas coisas, mas pode publicar conteúdo e deixar as pessoas comentarem 16:36 <jrandom> há personalizações específicas que vocês querem poder fazer? se sim, me avisem 16:37 <DoubtfulSalmon> jrandom: atualizar conteúdo existente via script? 16:37 <@cervantes> arquivo por data 16:37 <jrandom> DoubtfulSalmon: via script? 16:37 <jrandom> cervantes: ah, tipo um widget de calendário, em vez dos links de “5 entradas mais antigas”? 16:38 <@cervantes> isso 16:38 <DoubtfulSalmon> jrandom: digamos que eu queira que este arquivo/texto substitua aquele arquivo/texto. Como faço isso? 16:38 <jrandom> ok, legal, sim, isso deve ser bem fácil (se alguém preparar o HTML :) 16:38 <@cervantes> ou mais simplesmente “ver posts do mês passado” 16:39 <@cervantes> jrandom: você só precisa de uma tabela 7x6 com alguns números ;-) 16:40 <jrandom> DoubtfulSalmon: mudar conteúdo que já foi publicado é uma direção interessante. de modo geral, nem sempre funcionaria, pois teria que operar como mensagens de controle do usenet (cancelando um post antigo, etc.) 16:40 <jrandom> DoubtfulSalmon: por outro lado, você pode simplesmente publicar um novo arquivo/entrada e mudar os links no lado esquerdo para apontarem para o novo arquivo/entrada 16:40 <jrandom> (assim, o conteúdo antigo ainda fica lá, mas as pessoas são direcionadas ao conteúdo novo) 16:41 <DoubtfulSalmon> jrandom: sim, tudo bem se o conteúdo antigo ainda estiver lá, desde que os links de todo mundo apontem para o conteúdo novo, sem que tenham que mudar o próprio conteúdo. 16:41 <jrandom> construir um wiki completo em cima disso, essencialmente publicando diffs com o Syndie renderizando o resultado, é possível, mas pode ser exagero 16:41 <jrandom> hmm, ok, entendi o que você está dizendo 16:42 <jrandom> então, você quer a capacidade de ter links redirecionáveis, em vez dos links existentes para versões exatas do conteúdo 16:43 <jrandom> talvez isso possa ser feito vinculando ao bookmark de um blog, e a versão exata é encontrada carregando os bookmarks atuais desse blog e vendo para onde apontam 16:44 <jrandom> por outro lado, a nova versão poderia ser marcada como uma resposta ao post antigo, assim, quando as pessoas seguirem um link, podem seguir até a resposta que substitui o conteúdo 16:44 <jrandom> (embora isso provavelmente não seja tão transparente) 16:44 <DoubtfulSalmon> é: digamos que eu queira ter um link para, digamos, uma imagem de radar atual, ou algo assim que será atualizado a cada 10 min. Tudo bem se o conteúdo não se propagar por toda a rede, mas se alguém linkar para minha página, o usuário deve ver a imagem atual. 16:45 <jrandom> bem, isso depende do que querem fazer – querem linkar para a imagem como ela era quando se referiram a ela, ou querem linkar para o serviço que renderiza a imagem quando o leitor a vê 16:45 <+Complication> cervantes: esquisitice do dia :D Último post em: http://forum.i2p/viewtopic.php?t=1199&start=15 16:46 <+Complication> Parece que pode ser mais um de nossos senhores robóticos :P 16:46 <jrandom> mas é uma boa ideia suportar ambos os conceitos, e não acho que daria muito trabalho 16:46 <@cervantes> valeu 16:46 <jrandom> embora precise de uma pequena extensão ao SML (por exemplo, [blog bloghash="ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=" bookmark="radar.webp"]) 16:47 * cervantes vai reforçar as defesas do fórum se começarmos a receber muitos deles 16:47 <@cervantes> (já sei como parar aquele) 16:47 <DoubtfulSalmon> jrandom: eles deveriam poder linkar tanto para uma versão estática disso, desde que o sindicador não tenha excluído o conteúdo, quanto para uma URL genérica que aponte para o que for a versão mais recente 16:47 <jrandom> (o que olharia para o meta post atual de bookmarks de ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=, puxando a URI exata do que se chama "radar.webp") 16:48 <DoubtfulSalmon> jrandom: isso poderia ser feito agora com algo como: "Ver o post mais recente na tag <string esquisita>" 16:48 <jrandom> ah, boa – sim, poderia 16:49 <jrandom> isso poderia até ser restringido para “Ver o post mais recente por $author com a tag $tag” 16:49 <jrandom> (para que outras pessoas não pudessem falsificar isso) 16:49 <DoubtfulSalmon> então talvez colocar algum tipo de UI para que o usuário não precise ver tags esquisitas e afins 16:50 <jrandom> há um exemplo de como isso fica ali em cima, embora eu não tenha a URI de cabeça... mas sim, é um link em torno do texto vinculado 16:50 <DoubtfulSalmon> presumo que toda essa informação possa vir em forma de URL. 16:51 <jrandom> mas definitivamente é complicado escrever o SML de origem, por isso uma GUI para criar SML seria útil 16:51 <jrandom> são atributos nas tags SML, não URLs 16:52 <@cervantes> e uma GUI de SML será complicada sem JavaScript 16:52 <DoubtfulSalmon> mas dá para favoritar um resultado de busca, certo? 16:52 <jrandom> o que é um resultado de busca? 16:52 <jrandom> e o que você quer dizer com favoritar? 16:52 <@cervantes> (ou uma extensão de navegador ;-) 16:52 <jrandom> ah, favoritos do lado do navegador, sim 16:52 <+Complication> Um resultado de filtro? 16:53 <jrandom> mas esses favoritos geralmente não são compartilháveis 16:53 <DoubtfulSalmon> ops: um “obter o post mais recente por X com a tag Y” 16:53 <jrandom> (na verdade, a maioria é, mas não é universal, pois são URLs, não URIs)) 16:53 <DoubtfulSalmon> sim, seria bom se outros blogs pudessem linkar para isso também 16:54 <jrandom> DoubtfulSalmon: podem, com SML 16:54 <jrandom> [blog tag="Y" bloghash="X"] 16:54 <DoubtfulSalmon> ah, que bom 16:55 <jrandom> cervantes: JavaScript, ou XUL, ou Java, ou algum outro app cliente específico de SO 16:57 <@cervantes> ah, legal, então você não se importa com uma dependência de script ou plugin 16:57 <jrandom> (quando nosso site for reformulado para a 0.6.2, o Syndie com certeza ganhará um site explicando que diabos é esse negócio de Syndie, e como ele faz tudo menos lavar a louça ;) 16:57 <@cervantes> (desde que degrade graciosamente) 16:57 <jrandom> cervantes: o Syndie deve ser funcional com o lynx, mas há muito espaço para clientes ricos 16:58 <jrandom> (s/function/functional/) 16:58 <@cervantes> certo... então usuários de lynx teriam uma tabela de referência de SML, mas nada além disso 16:58 <jrandom> sim, como temos agora 16:58 <jrandom> embora talvez um SML simplificado, não sei. 17:01 <+Complication> jrandom: você acha remotamente plausível... que o bug do null possa estar relacionado à codificação gzip? 17:01 <+Complication> eu estava pensando em como desativar o gzipping para o meu tunnel de eepsite... 17:01 <+Complication> Ou isso seria completamente implausível? 17:01 <@cervantes> foi adicionada alguma coisa de compressor HTTP pouco antes do Ano‑Novo no i2ptunnel 17:03 <jrandom> sim, pode – você pode desativar no lado do cliente com i2ptunnel.gzip=false (em /configadvanced.jsp). no momento não acho que dê para desativar no i2ptunnelhttpserver, porém 17:03 <+zzz> é no lado do request onde não há qualquer compressão 17:03 <+zzz> o servidor não vai comprimir se o cliente estiver definido como false 17:03 <+Complication> zzz: ah, verdade, esqueci disso 17:04 <jrandom> (mas sem muito trabalho você poderia adicionar isso ao I2PTunnelHTTPServer [linha 310, etc.) 17:04 * Complication é um tolo, e pede desculpas por isso 17:04 <@cervantes> (ou você poderia usar um tunnel normal) 17:04 <+Complication> Aha, valeu... 17:05 <jrandom> hmm, embora quando o i2ptunnelhttpserver recebe o GET, o null já esteja lá 17:05 <+zzz> sim, consegui mover o orion de volta para um tunnel HTTP, o que ajuda bastante nos tempos de carregamento das páginas dele, já que agora estão comprimidas novamente 17:05 <+Complication> De alguma forma esqueci completamente que o gzipping começa quando cliente e servidor concordam em fazê‑lo 17:05 <jrandom> então pode estar no lado do cliente, mas definitivamente não no lado do servidor 17:05 <jrandom> sim, zzz, está insanamente rápido agora :) 17:05 <+zzz> é no lado do _request_, não no de _response_ – pode ser tanto no lado do cliente quanto do servidor 17:06 <jrandom> verdade 17:09 <jrandom> ok, mais alguém tem algo sobre 3) blogs do Syndie? 17:09 <jrandom> se não, vamos para 4) ??? 17:09 <jrandom> alguém tem mais algo para trazer para a reunião? 17:10 <cat-a-puss> Complication: gzip stream do Java + tunnels I2P. NÃO funciona e é bug da Sun 17:10 <jrandom> hmm, cat-a-puss? sério? 17:10 <+zzz> atualização de conexões HTTP persistentes: lado do cliente quase pronto, lado do servidor progredindo bem, muito hardening e testes a fazer, conclusão estimada em 2–4 semanas 17:10 <jrandom> boa, zzz! 17:11 <cat-a-puss> jrandom: sim, falei com você sobre isso há muito tempo; provavelmente eu conseguiria achar a explicação longa do porquê, mas é melhor apenas documentar isso em algum lugar, já que não há motivo para fazê‑lo. 17:12 <jrandom> hmm, estou fora de contexto, o que exatamente não funciona? qual é o bug da Sun? 17:14 <dust> eu recebo logs estranhos assim: 21:21:59.816 WARN [%d0%a2%d1%4f] net.i2p.util.EepGet : ERR: status <html> 17:14 <jrandom> hmm, interessante 17:15 <jrandom> qual tracker? 17:15 <cat-a-puss> jrandom: pelo que me lembro, a Sun usa zips sem cabeçalho e algum número mágico para indicar que é um zip stream. Mas o número acontece de ser negativo, então se você acabar criando um zip stream dentro de um zip stream por algum motivo, ele lê os dados do stream como uma sequência de bytes sem sinal e assim o número mágico é convertido para algum outro número positivo. (provavelmente estou esquecendo algum detalhe, mas essa é a essência) 17:16 <dust> por exemplo o OSDevWithCVS_3E.pdf.torrent 17:17 <dust> d8:announce540:http://YRgrgTLGnbTq2aZOZDJQ... 17:17 <jrandom> hmm, não sei nada sobre isso, e não tenho certeza de como isso afetaria o gzip stream sobre i2ptunnel (se /afetasse/, todos falhariam, porque fazemos gzip em tudo) 17:19 <jrandom> ok, legal, dust, então o tracker do postman. hmm, você está na 0.6.1.9, dust? 17:20 <cat-a-puss> jrandom: sim, já faz quase um ano desde que tive esse problema, então não me lembro muito bem, e não sei se foi corrigido no 1.5, mas tive um trabalhão danado tentando entender por que todo tipo normal de stream funcionava, mas assim que eu os encapsulava em um stream comprimido, todos falhavam. 17:20 <dust> sim 17:20 <jrandom> cat-a-puss: mudamos as coisas dramaticamente para compressão sobre i2p no último ano ;) 17:21 <jrandom> (e eu pessoalmente não uso o 1.5) 17:21 <jrandom> mas fazemos nossa própria codificação zip explicitamente, em vez de usar o stream empacotado deles (por razões de anonimato/eficiência, não de compatibilidade) 17:22 <@cervantes> zzz: exatamente onde no request o null acontece? logo após o GET? 17:22 <+Complication> Antes, se bem me lembro 17:23 <+fox> <lordalbert> oi 17:23 <+Complication> Observação: um Celeron 300 mostra uma porcentagem de retrans. duas vezes menor que um Sempron 17:23 <jrandom> oi, lordalbert 17:23 <jrandom> legal, Complication, 2–3% é razoável (embora eu preferisse menos, claro) 17:23 <@cervantes> seria interessante disparar um monte de requests HEAD ou algo assim... 17:24 <jrandom> sim, uma bateria de testes locais seria ótima, embora, se não me engano, o Complication tentou isso um tempo atrás sem erros 17:24 <+fox> <lordalbert> alguém pode fazer um tracker anônimo? Eu tentei, mas não entendo como usar o tunnel 17:24 <+Complication> cervantes: uma vez tentei provocar isso, com um wget recursivo entre os meus 2 nós 17:24 <+Complication> Cansei antes de acontecer 17:25 <@cervantes> heh 17:26 <+fox> <lordalbert> 'lo b0unc3 ;) 17:26 <+fox> <b0unc3> lordalbert, :D 17:26 <+Complication> lordalbert: sobre qual parte você precisa de orientação? 17:27 <+Complication> Sobre configurar trackers, infelizmente eu não sei. 17:27 <+Complication> Sobre I2PTunnel, posso tentar explicar... 17:27 <+fox> <lordalbert> Instalei o BTtracker, e funciona perfeitamente 17:28 <+Complication> Também vale notar que, para o tracker permanecer anônimo, provavelmente ele deve rodar com uma configuração bem cuidadosa 17:28 <+fox> <lordalbert> agora, eu gostaria de anonimizá‑lo 17:28 <+fox> <lordalbert> então 17:28 <jrandom> Tenho certeza de que podemos ajudar a resolver isso depois da reunião. você não deve usar trackers genéricos, precisa de um feito para anonimato 17:28 <+fox> <lordalbert> acabei de fazer um i2ptunnel 17:29 <jrandom> (por exemplo, a modificação do bytemonsoon que você encontra em qualquer um dos trackers I2P, ou no CVS) 17:29 <+fox> <lordalbert> agora, eu gostaria de saber como usar esse tunnel. Eu já fiz um tunnel 17:29 <jrandom> ok, alguém tem mais algo para a reunião? 17:30 <jrandom> lordalbert: http://localhost:7657/i2ptunnel/ deve permitir criar um ‘http server tunnel’ apontando para o seu webserver/tracker, mas o seu tracker não vai funcionar a menos que tenha sido modificado para uso anônimo 17:30 <+fox> <lordalbert> qual tracker eu devo usar? 17:31 <+Complication> o postman usa uma versão modificada do ByteMonsoon, acho 17:32 <jrandom> i2p-bytemonsoon foi modificado para uso anônimo – há um zip em @ http://i2p-bt.postman.i2p/, e há o CVS em http://dev.i2p.net/cgi-bin/cvsweb.cgi/bytemonsoon/ mas eu realmente não sei muito sobre isso 17:32 <+fox> <lordalbert> o bytemonsoon não é obsoleto? 17:32 <jrandom> se funciona, não é obsoleto. funciona 17:33 <+fox> <lordalbert> ok XD 17:33 <jrandom> há muitos trackers por aí, e se algum desenvolvedor quiser modificá‑lo para funcionar com segurança e anonimato, seria ótimo 17:33 <+Complication> Pode até ser meio antigo... mas definitivamente funciona com destkeys em vez de IPs... 17:33 <+Complication> Não posso falar sobre segurança e ausência de vazamentos 17:34 <jrandom> (foi modificado pelo duck e outros para anonimato e segurança) 17:34 <+Complication> Mas está no ar há um tempo e parece se virar... 17:35 <jrandom> ok, se não há mais nada para a reunião... 17:36 * jrandom encerra 17:36 * jrandom *baf*S a reunião encerrada