Reunião de Desenvolvimento do I2P - 22 de novembro de 2005

16:18 <jrandom> 0) oi 16:18 <jrandom> 1) Status da rede 16:18 <jrandom> 2) Fox hunt 16:18 <jrandom> 3) ??? 16:18 <jrandom> 0) oi 16:18 * jrandom acena atrasado, de uma casa com a energia restabelecida 16:18 <jrandom> notas semanais de status publicadas @ http://dev.i2p.net/pipermail/i2p/2005-November/001227.html 16:19 <jrandom> 1) Status da rede 16:20 <jrandom> não há muito a acrescentar além do que está no e‑mail.. alguém tem algo que queira levantar sobre o status da rede? 16:21 <jrandom> se não, vamos passar para 2) Fox hunt 16:21 <zzz> ótima ideia 16:22 <jrandom> aqui também, não tenho muito a acrescentar além do que está no e‑mail e das propostas do Raccoon23.. 16:22 <+fox> <ailouros> tenho algo contra o nome "Fox hunt". Preferiria chamar de "Man hunt". As raposas não fizeram nada de errado. 16:22 <Raccoon23> haha 16:22 <jrandom> sim, concordo, zzz, será bastante útil dar às pessoas um incentivo real sem os perigos sérios do uso real 16:23 <nickless_head> chame de "<animal politicamente correto> hunt 16:23 <Raccoon23> "Fox hunt" é o nome típico de um concurso de rádio amador em que você tenta encontrar um transmissor clandestino 16:24 <+fox> <ailouros> não me importo com transmissores de rádio chamados Fox, estamos falando i2p aqui, nenhuma raposa anônima permitida 16:24 <+fox> <ailouros> :D 16:24 * cervantes se pergunta se ailouros sabe o nome do changate 16:24 <nickless_head> talvez "Dissident hunt" 16:25 <@cervantes> <fox> <ailouros> :D 16:25 <+fox> <ailouros> (er o que é changate?) 16:25 <jrandom> heh 16:25 <@cervantes> ailouros: são os bots que retransmitem o chat entre redes diferentes 16:26 <+fox> <ailouros> você quer dizer vulpine aqui? 16:26 <@cervantes> o chat lá no i2p é retransmitido para você como vulpine 16:26 <@cervantes> e o seu chat é retransmitido para nós via fox 16:26 <@cervantes> ;-) 16:26 <@cervantes> *seu 16:26 <+fox> <ailouros> então a caça é ao pobre bot escravo? :D 16:27 <Raccoon23> então sim, acho que deveria haver uma página de recompensa/info configurada. Acho que deveríamos tentar arrecadar US$ 1 mil 16:27 <+fox> <ailouros> é, foi mal, eu normalmente não vou ao i2pchat :) 16:27 <+fox> <ailouros> agora, isso é que é recompensa! 16:28 <jrandom> Raccoon23: concordo, mas pode ser um pouco prematuro fazer isso agora. 16:28 <jrandom> (podemos sempre alocar fundos do fundo geral para a recompensa para dar o pontapé inicial quando necessário) 16:28 <+fox> <ailouros> começar a caça agora mas sem recompensa? 16:28 <+fox> <ailouros> digo, quanto antes começar, mais olhos se abrem 16:28 <jrandom> para a Fox hunt fazer sentido (ou seja, ajudar o I2P), precisamos fazer isso com cuidado. 16:28 <jrandom> não, ailouros, discordo. 16:29 <jrandom> rodar o concurso antes de o I2P estar pronto seria muito ruim. 16:29 <Raccoon23> sim 16:29 <jrandom> tanto porque desperdiçaria o tempo das pessoas avaliando algo que não está pronto, quanto porque não diria nada útil 16:30 <+fox> <ailouros> ....ponto entendido 16:30 <Raccoon23> e seria má publicidade se "encontrassem" vulnerabilidades que já estavam programadas para serem corrigidas nas próximas versões 16:30 <jrandom> sim 16:33 <jrandom> ok, mais alguma coisa sobre o 2), ou vamos passar para 3) ??? 16:34 <zzz> na outra parte do thread jrandom/raccoon23, ficou como conclusão mudar para 2-hop-minimum? mais alguma conclusão? 16:35 <jrandom> hmm, é tudo uma questão de quem é o adversário, mas não faria mal padronizar em 2 +0-1 e daria proteção contra uma classe de atacante 16:35 <jrandom> outras conclusões podem ser "ei, vamos tocar a 0.6.2" :) 16:35 <+fox> <ailouros> como configuro para que os tunnels sempre tenham um valor fixo (como variância 0+1)? Eu continuo recebendo valores padrão a cada reinício 16:36 <jrandom> ailouros: você deveria conseguir salvar as configurações em /i2ptunnel/ 16:36 <jrandom> ou você está mudando em /configtunnels.jsp ? 16:37 <Raccoon23> acho que tunnels de 1 hop permitem que um atacante bem fraco faça muita coisa na 0.6.1, pelo menos. Eu defenderia que a 0.6.1.6 não deveria ter tunnels de 1 hop por padrão 16:37 <+fox> <ailouros> então é no configtunnels 16:37 <jrandom> sim, concordo, Raccoon23 16:37 <jrandom> ailouros: use /i2ptunnel/ e salve suas configurações 16:37 <+fox> <ailouros> não tinha reparado na interface nova :D 16:38 <@cervantes> ailouros: acabou de ser adicionada na 0.6.1.5 16:38 <jrandom> sim, o cervantes fez um ótimo trabalho ali, ailouros 16:38 <+fox> <ailouros> bem, parabéns por isso 16:39 <@cervantes> já que estamos no assunto, se o pessoal estiver com problemas para salvar configurações na interface nova, talvez queiram usar um navegador que não seja o IE por enquanto, até a próxima versão 16:39 <@cervantes> *resmungo* microsoft *resmungo* 16:40 <+fox> <ailouros> em outro tópico, alguém se interessaria se eu configurasse um servidor de nethack no i2p? :D 16:41 <@frosk> ailouros: pensei nisso (jogando nethack irl), mas o lag ficaria horrível, temo eu (e lag é péssimo quando se joga nethack) 16:42 <+fox> <ailouros> acho que sim 16:42 <+fox> <ailouros> ok, ideia descartada 16:43 * frosk teve sua primeira ascensão há alguns meses, uhul 16:44 <jrandom> ok, alguém tem mais algo para a reunião? 16:45 <+fox> <ailouros> sim, algum indicador para o syndie quando o thread tiver uma nova mensagem 16:46 <nickless_head> jrandom: e seria legal se novas mensagens (os títulos) pudessem ser impressas em negrito/itálico na primeira vez que forem exibidas 16:47 <nickless_head> jrandom: existe uma forma _realmente simples_ de acessar as mensagens no banco de dados do syndie, via http? 16:47 <jrandom> ah sim, ailouros/nickless_head, estou pensando em usar cores/sinalização na primeira coluna por data (por exemplo, coisas postadas hoje recebem uma bandeira brilhante, ontem uma menos brilhante, etc). 16:47 <nickless_head> jrandom: de preferência em algo bacana e importável como xml 16:48 <jrandom> nickless_head: wget -R http://localhost:7657/syndie/archive/ 16:48 <nickless_head> se houver, eu poderia escrever um exportador de syndie para nntp 16:48 <jrandom> ah, se você quer exportar para nntp, use rss para nntp 16:48 <nickless_head> jrandom: ok, vou tentar isso :) 16:48 <nickless_head> jrandom: isso já existe? ... droga. ;) 16:49 <jrandom> também estou pensando em adicionar históricos de mensagens por usuário para permitir marcar mensagens como lidas/não lidas, mas isso provavelmente não estará na 0.6.1.6 (a menos que alguém mais implemente :) 16:49 <jrandom> ou talvez um novo filtro na árvore do thread - mostrar apenas mensagens postadas desde [hoje |v] 16:49 <jrandom> (ou ontem, ou 2 dias atrás) 16:50 <jrandom> nickless_head: http://www.methodize.org/nntprss/ 16:50 <nickless_head> jrandom: obrigado 16:54 <jrandom> de nada 16:54 <Raccoon23> jrandom: então vai levar um tempo até eu conseguir implementar isso (quero terminar restricted routes primeiro), mas o que você acha de garlic routing opcional de 1024 bits para tunnels de servidor de saída? 16:54 <jrandom> sobrecarga tremenda - O(data) é>>> O(tunnels). se já estamos com problemas agora com O(tunnels), não há como esperar por O(data) 16:55 <Raccoon23> ainda estamos com problemas de CPU? meu router tem ficado bem baixo, mas eu não tenho exatamente uma T1 por aqui.. 16:56 <jrandom> nem todo mundo tem p4s ;) 16:56 <jrandom> ouço relatos de 8–15% de uso em máquinas lentas, mas isso dá picos feios sob congestionamento 16:56 <jrandom> (para 100+%) 16:56 <+Complication> Sobre consumo de CPU: curioso, Java no Mandriva 10.1 consome muito menos que Java no Mandriva 2006. 16:56 <Raccoon23> sim, mas quem não tem provavelmente também não tem T1 16:56 <Raccoon23> também :) 16:57 <+Complication> Ambos ajustados, 2006 tem jbigi compilado localmente. 16:57 <jrandom> estranho, Complication 16:57 <jrandom> mesmas revisões do i2p? 16:57 <+Complication> No 2006 (Celeron 2.4) o Java pode chegar a 20%. 16:58 <+Complication> No 10.1 não passa de 5%. 16:58 <+Complication> (Normalmente) 16:58 <+Complication> (normalmente==não na inicialização) 16:58 <+Complication> Mesmas revisões. 16:58 <+Complication> Quase o mesmo Java também (_04 versus _05) 16:59 <+Complication> Lembra-me de ajustar os daemons um pouco mais. Talvez algum deles esteja atrapalhando o Java. 16:59 <+Complication> De algum jeito maluco que não consigo entender. 17:00 <+Complication> Mas sim, o Cel 300 está se sentindo notavelmente melhor. Pode ter sido o MTU adaptativo 17:01 <jrandom> ah, legal, sim, temos umas coisas bacanas a caminho :) 17:03 <+Complication> Fico pensando se haveria uma forma de contornar os problemas do jbigi relacionados à libc em certas distros Linux? 17:03 <jrandom> sim, com certeza, só precisamos reconstruir todos os jbigis 17:03 <jrandom> (não é a libc, é a libg++) 17:05 * Raccoon23 decide que não vai abrir mão dos seus sonhos de garlic routing, mas vai esperar a performance estabilizar.. talvez 2.0 17:05 <+Complication> Ah, você acha que uma recompilação adequada vai ajudar? 17:05 <jrandom> Complication: sim, os erros de link do jcpuid são desnecessários, já que jcpuid é realmente apenas uma chamada ASM (e não deveria ter sido implementado em c++ mesmo ;) 17:06 <jrandom> Raccoon23: legal :) é algo que podemos fazer eventualmente na rede ao vivo também, apenas usando um tipo de mensagem I2NP diferente, anunciando a capacidade certa e filtrando com base nisso 17:06 <jrandom> (eventualmente) 17:07 <Raccoon23> tipo um caps=S para CPU rápida? ;) 17:08 <jrandom> e caps=I para insano ;) 17:08 <jrandom> ok, mais alguém tem algo para a reunião? 17:08 <Raccoon23> haha 17:09 <Raccoon23> o que você acha da medida paliativa de compartilhar chaves entre múltiplos tunnels? retorno pequeno demais pelo trabalho? 17:09 <jrandom> por que isso seria melhor do que simplesmente ter múltiplos tunnels e enviar a mensagem por um dos vários tunnels? 17:10 <jrandom> (e, erm, isso não seria pior, do ponto de vista de segurança e de anonimato) 17:10 <Raccoon23> bem, a ideia é que os nós não conseguissem dizer qual tráfego fazia parte de um tunnel, de modo que, se você estivesse rodando i2phex e um eepsite, e escolhesse os mesmos hosts para seus tunnels, o tráfego dos dois seria mesclado no que os hops conseguiriam ver 17:11 <Raccoon23> o que deveria tornar ataques de temporização mais difíceis 17:11 <jrandom> ah, eita, sim. isso adiciona uma linkabilidade Realmente Ruim 17:11 <jrandom> é por isso que mudamos para pools de tunnels por cliente na 0.4 17:11 <Raccoon23> explica? 17:11 <jrandom> i2ptunnel permite que as pessoas compartilhem pools, se quiserem, compartilhando o mesmo destination 17:12 <jrandom> se mensagens de 2 clients passam por um mesmo tunnel, você sabe que ambos esses clients são controlados pela mesma pessoa 17:12 <jrandom> s/clients/destinations/ 17:13 <Raccoon23> bem, se as chaves fossem compartilhadas, os hops iniciais poderiam ser mesclados, mas os leasesets separados.. 17:13 <Raccoon23> os hops iniciais sendo os perigosos para ataques de temporização mesmo assim 17:13 <jrandom> ainda permitiria um vetor para vincular os dois destinations que deveriam ser não vinculáveis 17:14 <jrandom> poderia fazer algumas modificações para, com sorte, ofuscar a linkabilidade, mas elas estariam inerentemente ligadas. o que não é necessário, e é ruim. 17:18 <Raccoon23> voltando a sonhar com caps=SI, acho :) 17:19 <jrandom> ah, enfim. ok, alguém tem mais alguma coisa? 17:20 * jrandom encerra 17:20 * jrandom *baf* fecha a reunião