Reunião de Desenvolvedores do I2P - 16 de março de 2004

13:12 < jrandom> pauta: 13:12 < jrandom> 0) oi 13:12 < jrandom> 1) assuntos administrativos 13:13 < jrandom> 2) status 0.3 13:13 < jrandom> 3) perfilamento/seleção de pares 13:13 < jrandom> 4) arquitetura web 13:13 < jrandom> 5) ??? 13:13 < jrandom> 0) oi 13:13 * jrandom acena para a galera 13:14 < deer> * jrandom_ acena do i2p 13:14 < deer> * wilde dá um hi5 13:15 < deer> <ughabugha> Oi! 13:15 < deer> * duck está lendo 13:15 < deer> <human> yo! 13:16 < jrandom> w0rd, desculpem o atraso em colocar aquelas notas de status em (http://i2p.net/pipermail/i2p/2004-March/000165.html) 13:18 < jrandom> 1) assuntos administrativos 13:19 < jrandom> por simplicidade, e para evitar os problemas que tivemos na semana passada com as várias redes sendo enjoadas, rolou uma mágica e esta reunião está acontecendo em três redes de IRC 13:19 < deer> <duck> (incrível!) 13:19 < jrandom> #i2p da iip, #i2p da rede de IRC i2p do duck/baffled, e #i2p da freenode 13:19 < jrandom> :) 13:19 < deer> <baffled> quem é paranoico? 13:20 < deer> <ughabugha> Ok, terminei de ler as notas de status. 13:20 < deer> <ughabugha> jrandom: E aí? 13:20 < deer> <ughabugha> Ou elas? 13:21 < jrandom> só mencionando, assim quem tiver problema com uma pode usar outra 13:21 < deer> <mihi> beleza. terminei as notas de status também 13:21 < jrandom> além disso, a máquina do drupal deve voltar online neste fim de semana (dedos cruzados) 13:22 < deer> <ughabugha> Ah, ok. Tem algo a discutir no 1)? 13:22 < deer> <ughabugha> Ou estamos esperando o pessoal terminar a leitura? 13:22 < deer> <ughabugha> jrandom: Bom. :) 13:22 < jrandom> não, a menos que alguém tenha algum assunto administrativo que queira levantar? 13:23 < deer> * mihi quer marcar um ponto no item 3 13:23 < jrandom> ponto marcado ;) 13:23 < deer> * duck no item 2 13:23 < deer> <duck> err, que índice usamos? 13:24 * jrandom supõe que podemos passar para o item 2 da pauta) status 0.3 13:25 < jrandom> acabei digitando muito mais do que o normal nas notas de status 0.3, então em vez de repeti-las aqui, alguém tem alguma pergunta/preocupação que queira levantar? 13:25 < deer> <ughabugha> Manda ver. 13:26 < deer> <duck> por que as descriptografias ElGamal/AES+SessionTag falham com tanta frequência? 13:26 < jrandom> duck> devido a sobrecarga e latência. se uma mensagem roteada via garlic for atrasada além do tempo de vida daquele sessionTag, a descriptografia vai falhar 13:27 < deer> <duck> blz 13:27 < jrandom> além disso, se a mensagem roteada via garlic for descriptografada direitinho, mas o conteúdo atrasou tanto que os cloves expiram, é uma descriptografia desperdiçada também 13:28 < deer> <duck> de algum jeito essa frase me fez acreditar que havia uma causa além de sobrecarga/latência 13:28 < deer> <tro|l> ce zi e azi? 13:28 < jrandom> bem, houve alguns problemas com blocos de resposta com roteamento de origem falhando na descriptografia, mas como eles vão sumir no 0.3.1, não vale muito a pena depurá-los 13:29 < deer> <kaji> uau, funciona! 13:29 < jrandom> (e um ElG falhado é provavelmente a coisa mais intensiva em CPU que o i2p faz) 13:30 < deer> <jrandom_> heh bem-vindo ao i2p #i2p :) 13:30 < deer> * kaji louva o 0.2.5.1 13:30 < deer> <jrandom_> 0.2.5.1? caraca, pegue o 0.2.5.4 :) 13:30 < jrandom> ok, mais alguma coisa sobre o status 0.3? 13:31 < deer> <kaji> .. 13:31 < deer> <duck> . 13:31 < deer> <kaji> ping? 13:31 < jrandom> p0ng 13:31 < mihi> pung 13:31 < deer> <mihi_backup> pung2 13:32 < deer> <Pellinore> prawn 13:32 < jrandom> ok, passando para 3) perfilamento/seleção de pares 13:32 * mihi move a bandeira para o outro número 3 ;) 13:32 < jrandom> (cara, é meio engraçado que não existam substitutos vegetarianos para frutos do mar...) 13:32 < deer> * kaji louva 0.2.5.4.1 13:32 < deer> <duck> todo esse lance de perfilamento de pares parece magia, como você planeja depurar isso? 13:32 < deer> <Pellinore> Existe carne de caranguejo vegetariana. 13:32 < jrandom> ah, verdade, pellinore. 13:32 < deer> <wilde> jrandom: e sushi veg 13:33 < jrandom> duck> que parte disso parece magia? 13:33 < deer> <duck> toda a classificação etc 13:33 < deer> <Pellinore> E eu poderia jurar que vi algum substituto de filé de peixe tipo chik, mas posso estar errado. 13:33 < deer> <duck> Quero dizer, como você sabe que está fazendo o ideal? 13:33 < jrandom> o organizador de pares (que move perfis entre os diferentes grupos) é um componente bem simples e separável 13:33 < jrandom> ah, bom ponto. 13:34 < jrandom> eu estava fazendo alguns benchmarks outro dia, executando o organizador com 10,000 perfis, e ele estava organizando todos em ~50ms 13:34 < jrandom> (organizando == runningthe calculators e movendo-os entre grupos) 13:34 < jrandom> os perfis também consomem apenas ~3-4KB para um perfil completo, e um perfil mínimo ocupa ~200 bytes 13:35 < deer> <duck> sim, mas como você sabe que está certo com '0.597s reply' para o grupo 1 13:35 < deer> <duck> e que não deveria ser 0.603s 13:35 < jrandom> (então vamos manter um perfil completo dos 1000 melhores peers, e mínimo dos próximos 10,000) 13:35 < jrandom> ah, ok, boa pergunta. 13:36 < jrandom> esse é o componente Rate 13:36 < jrandom> obviamente vai haver alguma oscilação, e não seremos muito exatos. a meta é chegar perto e organizá-los de acordo 13:37 < deer> <duck> Eu vi que usa médias 13:37 < jrandom> por exemplo, encontrar os routers em T3s com processadores quad, e mantê-los separados dos routers em 386s com modems de 2400 bps 13:37 < deer> <duck> então se você jogar 100 nós ruins, você influencia muito a média 13:37 < jrandom> concordo - há dois aspectos diferentes nisso que podemos ajustar 13:38 < jrandom> primeiro, podemos fazer o limiar usar os 10% do topo para determinar "rápido" vs "não rápido" 13:38 < jrandom> (ou top 90%, tanto faz) 13:38 < jrandom> segundo, podemos ajustar o componente Rate para manter várias estatísticas - em vez de uma média simples, ele pode ignorar assimetria, achar desvio padrão, etc 13:39 < jrandom> o componente Rate atualmente é bastante básico, e eu adoraria que alguém bom com estatística pudesse dar uma olhada e melhorá-lo 13:39 < jrandom> (uma das metas-chave dele, porém, é ser livre de escala - então se tivermos 100,000 eventos, ele não precisa manter todos esses pontos de dados na memória, etc) 13:40 < deer> <duck> ok, então o que impede outro desastre NGRouting de acontecer? 13:40 < jrandom> mas você está absolutamente certo - os calculadores e os algoritmos de seleção de pares vão ser um foco importante de melhorias futuras da rede 13:40 < jrandom> o ngrouting tentou fazer duas coisas diferentes - encontrar dados específicos e encontrar peers disponíveis. 13:40 < jrandom> nós só precisamos encontrar peers disponíveis 13:41 < deer> <duck> bom 13:41 < jrandom> (e colocar nossos tunnels lá) 13:41 < deer> * duck remove breakpoint 13:41 < jrandom> :) 13:41 < mihi> mas temos que encontrar tunnels também. 13:41 < jrandom> certo, mihi - o netDb é um ponto importante 13:42 < deer> <Pellinore> Eu me viro bem com a matemática de estatística, mas sou péssimo com os aspectos técnicos de traduzir os dados para algo útil no computador. 13:42 < deer> <Pellinore> Mas eu ficaria feliz em me juntar a alguém e contribuir se puder. 13:42 < jrandom> sensacional, pellinore! 13:43 < jrandom> a classe principal rate está em http://i2p.net/cgi-bin/cvsweb.cgi/i2p/code/core/java/src/net/invisiblenet/i2p/stat/Rate.java?rev=1.3&content-type=text/x-cvsweb-markup e podemos conversar depois para discutir :) 13:43 < deer> <Pellinore> ok 13:43 < jrandom> (eu sei, não espero que você leia o código, só mencionando) 13:44 < deer> <Pellinore> Eu vou ler, mas vai ser como meu cachorro lendo Kierkegaard. 13:44 < jrandom> hehe 13:45 < deer> <Pellinore> Mas estou aprendendo. 13:45 < deer> <Pellinore> Enfim, por favor prossiga — não quero travar as coisas. 13:45 < jrandom> (se voluntariar para ajudar não está travando as coisas ;) 13:46 < jrandom> um ponto que esqueci de mencionar sobre o código de perfilamento/seleção de pares é que o ranking de 'integração' só é usado no banco de dados da rede para 'exploração', não para busca/armazenamento 13:46 < jrandom> ainda fazemos busca/armazenamento (bastante) tradicional kademlia com todos os peers que não falham 13:46 < jrandom> além disso, dentro de cada grupo de pares, nós sempre escolhemos *aleatoriamente* 13:46 < jrandom> (vulgo não escolhemos sempre o mais rápido do grupo dos rápidos, etc) 13:47 < jrandom> isso por motivos de segurança e balanceamento de carga 13:48 < jrandom> (segurança, para que um atacante não possa simplesmente criar um router muito rápido e ver todo mundo usá-lo - eles teriam que criar um grande número de routers muito rápidos, enviesar toda a distribuição a seu favor, etc) 13:49 < jrandom> ok, temos mais alguma coisa para 3) perfilamento/seleção de pares? 13:49 < deer> <duck> . 13:50 < deer> <ughabugha> Parece que não. 13:50 < jrandom> ok, passando para 4) arquitetura web 13:52 < jrandom> a nova lib de streaming do mihi nos dá muita flexibilidade, além dele ter mencionado algumas vezes o desejo de isolar o código do httpclient em algo mais robusto. além disso, o human começou a atualizar as coisas para permitir proxy transparente via squid (ou tor-www) e proxy de eepsite dentro do mesmo cliente 13:52 < jrandom> dados todos esses fatores diferentes, e a probabilidade de que funcionalidades do tipo web serão importantes para a base de usuários do i2p, acho que devemos dar um passo atrás e tentar visualizar como tudo deve se encaixar 13:53 * mihi tem algum código voando pelo meu hd para aquele código de httptunnel. mas está longe de estar pronto 13:53 < mihi> para mim httptunnel == httpclient + alguns filtros 13:53 < mihi> claro que usando minha naming e API de streaming. 13:54 < mihi> o código no momento só permite diferentes "perfis de anonimato". 13:54 < jrandom> alguma opinião sobre o estilo do human de fazer failover para outproxies como squid/etc? 13:54 < mihi> ou seja, enviar todas as requisições por um destination, multiplexá-las até 10, multiplexá-las até um dest por hostname, etc. 13:54 < jrandom> ah, interessante 13:55 < mihi> mas esses dests ainda não são usados ;) 13:55 < jrandom> w3rd. é, tem a grande ressalva de que ter muitos destinations em um router aumenta a carga de CPU de forma não trivial 13:55 < jrandom> (já que qualquer falha de garlic vai precisar falhar uma vez por dest antes de falhar completamente) 13:56 < jrandom> ainda tem alguma mágica que pode ser usada para minimizar isso, eu acho 13:56 < deer> <ughabugha> Você tem certeza que o proxy transparente via squid é uma boa ideia do ponto de vista de desempenho? Digo, as pessoas podem ficar preguiçosas e não desligar o eepproxy depois de navegar em sites I2P ou usar o squid do I2P, desperdiçando assim banda do I2P com coisas que não exigem anonimato. 13:56 < jrandom> ughabugha> tudo requer anonimato :) 13:57 < jrandom> (e se não conseguem perceber a diferença, bem, caraca...) 13:57 < mihi> minha intenção para o httptunnel é que links http sejam reescritos (similar ao fproxy) para que você não precise de um proxy, mas apenas de um servlet. 13:57 < deer> <ughabugha> jrandom: Heh. Desse jeito, o I2P nasceu morto. Não vai haver banda disponível suficiente na rede, que todos os nós finais provavelmente consumiriam. 13:58 < mihi> nessa página de info poder-se-ia adicionar um recurso para navegar no site através, p.ex., do squid. 13:58 < jrandom> não estou bem certo se entendi. eu entendo e concordo com as questões de DNS envolvidas (embora eu ache que podemos contorná-las de algumas formas) 13:58 < jrandom> ah, ok, mihi 13:58 < deer> <aum> bom dia a todos 13:58 < jrandom> mihi> então tipo uma "Não foi possível alcançar o peer" muito, muito mais avançada? 13:59 < mihi> mais como uma página de "aviso de anonimato" como no freenet ;) 13:59 < jrandom> ughabugha> se não conseguimos lidar com navegação web, como vamos lidar com BT/compartilhamento de arquivos? 13:59 < jrandom> hmm, mihi, mas queremos isso, para pessoas que querem navegar na web anonimamente? ou o httpclient não seria o app que usariam? 14:00 < jrandom> 'mornin aum, bem a tempo para a reunião de dev :) 14:00 < mihi> jrandom: se alguém só quiser navegar na web anonimamente, ele 14:00 < deer> <ughabugha> jrandom: Hmm... Bom ponto. Vamos lidar com isso mesmo? ;) 14:00 < deer> <aum> jrandom: você não está na iip, você não está na irc.duck.i2p ?!? 14:00 < jrandom> ughabugha> temos que lidar. 14:01 < mihi> pode configurar o httptunnel para fazer isso (o httptunnel ainda funcionará como um proxy, então é bem trivial adicionar isso) 14:01 < mihi> e muito provavelmente alguém navegando na web "anonimamente" vai gostar de alguns filtros de conteúdo, imagino ;) 14:01 < jrandom> mihi> acho que o human já fez :) 14:01 < jrandom> concordo, mihih 14:01 < jrandom> /hih/hi/ 14:02 < mihi> quando digo httptunnel, não quero dizer httpclient ;) 14:02 < jrandom> ah ok 14:02 < deer> <jrandom_> estou aqui, aum ;) 14:02 < mihi> mas nós *realmente* deveríamos mover o i2ptunnel para usar a streaming api ASAP, o que reduzirá o número de arquivos que devemos manter 14:03 < jrandom> concordo 14:03 < mihi> human só corrigiu a versão antiga, eu corrigi a versão nova mesmo 14:03 < jrandom> encontramos alguns bugs esta tarde, não sei se o human já te mandou logs 14:03 < deer> <wilde> outra coisa para a lista: outproxy foi usado, mas mais como i2p2i 14:04 < mihi> ainda não recebi logs de ninguém... 14:04 < jrandom> mihi> vamos partir para o código de streaming o quanto antes, podemos falar disso após a reunião se você tiver um minuto, ou por email? 14:04 < deer> * aum passou parte de ontem olhando apps p2p com vista a rodá-los no i2p 14:04 < jrandom> wilde> hmm? 14:04 < jrandom> massa, aum, algo promissor? 14:04 < deer> * aum está inclinado no momento a favorecer compartilhamento do tipo 'push', ex konspire2b 14:05 < jrandom> o i2psnark poderia ser modificado para usar a nova streaming api do i2ptunnel com bastante facilidade também 14:05 < deer> <human> mihi: enviando os logs (mihi@i2p.net, certo?) 14:06 < mihi> não sei se o mihi fez um redirecionamento para mim 14:06 < deer> <mihi> s/mihi/jrandom 14:06 < jrandom> hmm aum, você acha que o modelo freenet/insert realmente funcionaria de forma mais eficaz? 14:06 < deer> <wilde> jrandom: eu estava pensando em usar um i2p webserver -> proxy -> internet, assim as pessoas podem navegar num site i2p, mas talvez um tunnel comum consiga gerenciar o tráfego 14:06 < jrandom> mihi> quer que eu configure isso para encaminhar para você? 14:06 < mihi> jrandom: nada contra ;) 14:07 < deer> <ughabugha> aum: 'Push'-type? O que é isso? 14:07 < deer> <aum> o que eu gosto no konspire2b é que tira a expectativa de entrega instantânea/pronta e reduz a necessidade de banda, só transmitindo anúncios de conteúdo, então deixando as pessoas 'assinarem' 'feeds de conteúdo' 14:07 < jrandom> mihi> feito. 14:08 < deer> <aum> então em vez de solicitar um arquivo, ficar coçando os dedos, ficando p. da vida esperando ele chegar, você só 'assina' o 'canal' da fonte, e vai tocar outras coisas 14:08 < deer> <aum> konspire2b.sf.net 14:08 < jrandom> aum> mas isso não é incrivelmente ineficiente, já que você tem que gerenciar uma rede de sobreposição (broadcast) para a lista de coisas disponíveis e depois tem que retransmiti-las? 14:09 < jrandom> um sistema de swarm direto não seria muito mais útil/eficiente? 14:09 < deer> <ughabugha> Heh. Isso parece promissor para o I2P. 14:09 < deer> <aum> jrandom: algum exemplo de swarm direto? 14:09 < jrandom> wilde> ah, tipo o cgiproxy no duck e no site do janonymous? 14:09 < jrandom> aum> bittorrent 14:10 < deer> <ughabugha> aum: Você quis dizer http://konspire.sourceforge.net/? 14:10 < jrandom> onde você pega o torrent em algum lugar, e obtém blocos de conteúdo diretamente dos peers que têm 14:10 < deer> <aum> ughabugha: acho que sim :) 14:10 < mihi> argl... $me->brother removeu o port forward para i2p... 14:10 < jrandom> d'oh 14:10 < deer> <aum> jrandom: alguém está tentando bt/i2p atualmente? 14:11 < deer> <baffled> aum, você deu uma olhada de perto no mnet? 14:11 < jrandom> aum> o eco fez algum progresso com o i2psnark 14:11 < deer> <aum> eu vi, mas não de perto 14:11 < jrandom> (embora ele esteja mia no momento) 14:12 < jrandom> hmm, mnet com metatrackers via eepsite e o transporte i2p/twisted do human pode funcionar 14:12 < deer> <duck> testes pesados por janonymous e por mim parecem mostrar que os problemas atuais do i2psnark são 50% causados pelo i2p e 50% pelo snark 14:12 < jrandom> duck> quão recentes foram esses testes? 14:12 < deer> <duck> semana passada 14:12 < jrandom> embora eu não tenha problema em potencialmente explorar outras implementações de bt 14:12 < jrandom> ah ok 14:13 < deer> <duck> sobre mnet, eu _acho_ que você teria que consertar o próprio mnet antes de conseguir fazer isso funcionar 14:13 < deer> <duck> então você pode muito bem consertar o freenet e usar aquilo 14:13 < jrandom> heh 14:13 < deer> <aum> consertar o freenet, ok! logo depois de trazermos a paz mundial ;p 14:13 < deer> <duck> mas pergunta no #mnet @ freenode 14:13 < deer> <Pellinore> mnet=? 14:13 < deer> <Pellinore> Mute? 14:14 < jrandom> nesse sentido, talvez um mod do azureus para i2p possa funcionar? 14:14 < deer> <wilde> não, uma abordagem p2p baseada em mercado 14:14 < jrandom> pellinore - mnet.sf.net, um repositório de dados distribuído sem anonimato 14:14 < deer> <baffled> Na verdade, estou usando mnet com bastante confiabilidade em umas cinco máquinas. 14:14 < jrandom> certo, o sucessor do mojonation 14:14 < deer> <baffled> Eu não consigo usar o freenet de forma confiável nem em uma máquina. 14:14 < deer> <duck> baffled: 0.6 ou 0.7? 14:14 < deer> <duck> (0.7 é com twisted iirc) 14:16 < deer> <Pellinore> jrandom -- obrigado. 14:16 < deer> <Pellinore> Você não consegue usar o Freenet de forma confiável em máquina nenhuma. 14:17 < deer> <baffled> 0.6.[23]. 14:17 < deer> <Pellinore> Isso é, entre outras razões, por que estamos aqui. :) 14:17 < deer> <aum> eu acho que entropy funciona bem... eventualmente! 14:17 < jrandom> eu não sei, ainda acho que o freenet pode ser uma boa base para trabalhar no DHT do i2p (quando pudermos cortar a maior parte do código e manter o repositório de dados / SSK/CHK) 14:18 < jrandom> para compartilhamento de arquivos, devemos aprender com a galera de filesharing o que funciona melhor 14:18 < deer> <aum> mas desde o meu artigo no linuxworld sobre entropy, há zilhões de nós entropy agora, e a rede assumiu algumas características de desempenho de freenet 14:18 < deer> <Pellinore> Eu gosto do layout básico e dos recursos do Freenet, é que essa porra não funciona, especialmente se você estiver usando uma conexão discada. 14:18 < jrandom> por exemplo clones de DC, BT, [ou o que mais essas pessoas loucas de filesharing usam?] 14:19 < jrandom> heh aum, maldito seja ;) 14:19 < deer> <duck> além disso tem as coisas que o Newsbyte identificou sobre o entropy... 14:19 < deer> <aum> anonimato mais fraco, por exemplo? 14:19 < deer> <baffled> Certo, mas há questões de instabilidade com a 0.7. 14:19 < deer> <baffled> Acho que esta conexão ficou instável de novo. 14:19 < jrandom> e questões de segurança. acho que infelizmente podemos passar de usar o entropy 14:21 < jrandom> mas, erm, estamos no ponto de discussão 4, arquitetura *web*, então por enquanto vamos voltar para isso ;) 14:21 < deer> <aum> outra ideia doida de compartilhamento de arquivos - e se usássemos nntp, com n pessoas rodando nntpds interligados, e só usar uma daquelas libs que dividem arquivos em pedaços b64 e postam, e libs para recuperá-los? 14:22 < jrandom> NNTP seria muito interessante - é confiável pra caramba e testado pelo tempo 14:22 < deer> <duck> interligar os servidores? 14:22 * jrandom adoraria ter um innd rodando com i2p ;) 14:23 < deer> <aum> e como o i2p faz o anonimato, não há necessidade de o nntp tê-lo 14:23 < jrandom> certo, a feed line do innd poderia apontar para um proxy do i2ptunnel local 14:23 < deer> <aum> e pessoas com servidores diferentes podem configurar os servidores para fazer cache dos grupos que quiserem 14:23 < mihi> dependendo de com que frequência eles fazem peering, seria possível censurar artigos criando colisões de id de mensagem 14:23 < deer> <duck> (já tentou configurar o innd?) 14:24 < jrandom> muitas vezes, duck, mas há muuuuito tempo 14:24 < deer> <aum> configurar innd é difícil? 14:24 < deer> <duck> ah bom, você é deus 14:24 < jrandom> mihi> concordo - esse não é um meio de distribuição à prova de censura 14:24 < jrandom> aum> é um saco 14:25 < jrandom> assim como squid - é bom no que faz, mas provavelmente precisamos de algo muito simples (um clique, de preferência) para empacotar 14:25 * jrandom nos puxa de volta ao tópico 14:26 < deer> <aum> e ainda outra abordagem p2p/compartilhamento - eu me lembro de ter visto um app p2p que funciona via http, encadeando servidores http 14:26 * mihi imagina que a maioria dos usuários não sabe configurar um proxy no seu brwoser... 14:26 < deer> <aum> foi mal, qual é o tópico? 14:26 < jrandom> item 4 da pauta) arquitetura web ;) 14:26 < aum> tipo, servidores web dentro do i2p? 14:26 < mihi> aum: sim 14:26 < jrandom> é um bom ponto, mihi - um sistema web vai querer o básico (scripts .bat, .sh) para iniciar/parar 14:27 < jrandom> hmm, o mozilla não inclui uma URL de javascript que você pode usar para configurar o proxy? 14:27 < jrandom> por exemplo, poderíamos ter uma página de config no httptunnel para clicar "on"/"off"? 14:28 < jrandom> eu sei que não vamos chegar a nenhuma decisão hoje sobre como a funcionalidade web deve funcionar, mas devemos definir algumas direções 14:28 < aum> qual é o problema com a configuração atual do eepproxy? 14:29 < jrandom> por exemplo, filtragem, proxies de entrada (eeproxies), servidores de saída (servidor normal do i2ptunnel), proxies de saída (outproxies tipo squid ou tor-www) 14:29 < mihi> aum: requer bastante habilidade tanto para prover quanto para solicitar eepsites 14:29 < jrandom> além disso, o sistema de outproxy existente é uma droga. 14:29 < jrandom> é totalmente não escalável 14:29 < jrandom> precisamos de algo para permitir/forçar a distribuição da carga de requisições web de saída por múltiplos outproxies 14:30 < mihi> como os usuários podem obter esses outproxies. arquivo de config (tipo no hosts.txt?) 14:30 < jrandom> e um motivo pelo qual pessoas normais iriam querer rodar outproxies é pela negabilidade plausível - mesmo que ELES estejam solicitando "coisas ruins", podem dizer "foi o i2p" 14:31 < jrandom> essa é uma opção, mihhi 14:31 < mihi> jrandom: hehe 14:31 < jrandom> s/hh/h/ 14:31 < aum> mas o eepproxy não faz conexão http 'direta' com o servidor solicitado, ou seja, tão 'direta' quanto as conexões i2p são? 14:31 < deer> <wilde> . /castvote DHT ala Freenet 14:31 < mihi> aum: o problema são as URLs "normais" da web. 14:31 < jrandom> ./castvote 3 developers x 1 month x 12h / day 14:32 < deer> * human adicionou suporte ao httptunnel no TunnelManager, a propósito 14:32 < deer> <human> s/httptunnel/httpclient/ 14:32 < deer> <aum> o que é isso? 14:32 < deer> <aum> ah, suporte a http client? 14:32 < deer> <human> aum: sim 14:32 < jrandom> certo, precisamos achar uma forma de deixar as pessoas navegarem no slashdot.org via i2p 14:32 < deer> <aum> então o tunnelmgr agora fala http? 14:32 < jrandom> nice1 human! 14:32 < jrandom> aum> lembra do proxy squid? 14:33 < deer> <aum> sim 14:33 < deer> <wilde> jrandom: então ~4 homem-meses para um DHT? 14:33 < deer> <human> aum: sim: openhttpclient <port> [<outbound WWW proxy>] 14:33 < jrandom> wilde> acho isso razoável, sim. 14:34 < deer> <aum> human: você escreveu isso em algum lugar? 14:35 < jrandom> aum> tudo que faz é dizer "if !eepsite { send through $outboundWWWproxy } else {send to eepsite}" 14:35 < deer> <human> aum: eu ia fazer commit, aí fiquei preso num bug do StreamingI2PTunnelServer... 14:36 < jrandom> uma boa solução de curto prazo seria um "outproxies.txt", estilo hosts.txt 14:36 < deer> <aum> human: e o que exatamente 'openhttpclient <port> [<outbound WWW proxy>]' faz? 14:36 < jrandom> embora devamos começar a pensar em soluções de médio e longo prazo 14:37 < deer> <human> human: vai abrir um proxy escutando conexões, que redirecionará para o proxy WWW tudo que for para URLs não terminadas em .i2p 14:38 < deer> <Pellinore> Agora isso é interessante. 14:38 < deer> <aum> human: ahh, legal, então você desmembrou uma thread dentro do tunnelmgr? 14:38 < deer> <human> human: i.e. você pode usá-lo para navegar tanto eepsite quanto a web normal 14:38 < deer> <human> human: sim 14:38 < deer> <human> s/human/aum/ :-) 14:39 < deer> <aum> um tanto fora do 'escopo' do tunnelmgr, mas poxa, não há outro lugar mais apropriado no código do i2p - bom trabalho d00d 14:39 < deer> <aum> human: então você fala python E java? isso está estragando seu cérebro? 14:39 < deer> <human> aum: fiz isso para evitar lançar mais uma JVM para o EepProxy 14:40 < jrandom> (bem, o código está implementado no httpclient do i2ptunnel, o human só expôs recentemente isso via tunnelmanager também) 14:40 < deer> <aum> sim, sempre bom manter as instâncias da jvm no mínimo 14:40 < jrandom> ((e na minha humilde opinião httpclient é exatamente onde isso deve ir ;) 14:40 < jrandom> (((até o NextGen httpclient [httptunnel] do mihi sair))) 14:41 < deer> <aum> o httpclient está no cvs, de forma que vai compilar para mim como parte do i2p update/build? 14:41 < jrandom> sim, o eepProxy usa httpclient 14:42 < deer> <aum> *cara isso é tão esquizofrênico - eu tenho 3 sessões do xchat abertas (irc.duck.i2p,iip,freenode)) 14:42 < jrandom> :) 14:42 < deer> <aum> latência sinistra no irc.duck.i2p 14:42 < jrandom> ok, então sem fechamento hoje sobre a arquitetura web, obviamente, mas discussão válida 14:43 < jrandom> é, aum, uns 15s para mim 14:43 < jrandom> mais algo na arquitetura web por enquanto, ou devemos passar para 5) ??? seção de discussão aberta? 14:43 < deer> * human está pensando em um I2PSocksTunnel 14:44 < jrandom> eita, isso seria legal 14:44 < deer> <human> (bem, talvez isso pertença ao 5) 14:44 < deer> <aum> socks? há como "encaixar" clientes que não suportam socks até uma interface socks? 14:44 < deer> <human> aum: apt-get install tsocks :-) 14:45 < aum> discussão web - uma última coisa - e quanto a talvez fazer fork/patch em um cliente web existente 14:45 < mihi> aum: sockscap para windwos 14:45 < jrandom> aum> assustador. muito poderoso, mas assustador. 14:45 < jrandom> [eu odiaria ter que manter isso] 14:45 < aum> mesmo que por ora, um navegador cabeça-oca como dillo 14:46 < jrandom> [[embora pudesse ser feito ‘uber secure’, etc. mas ainda assim, muito, muito assustador]] 14:46 < aum> ou melhor, o controle de navegador no wxwindows, é multiplataforma 14:46 * jrandom relembra o flinks orignial, quando tinha um navegador de freesite embutido 14:47 < aum> mas por outro lado, os n00bs vão whingar se não conseguirem navegar nos seus sites usuais infestados de javascript específico da m$ 14:47 < jrandom> certo, aum, e os hackers também se não suportar o código mais recente e compatível com padrões 14:47 < aum> ei, deveríamos pedir o código-fonte do IE6 à Microsoft, aí a gente faz patch ;p 14:47 < jrandom> construir um navegador == ótima forma de desperdiçar milhares de horas-homem 14:47 < jrandom> heh 14:47 < deer> * human está bem feliz usando privoxy 14:48 < aum> talvez eles joguem o código do ie6 como parte do acordo punitivo europeu 14:48 < deer> <human> (http://www.privoxy.org/) 14:48 < aum> s/toos/toss/ 14:48 < jrandom> human> como isso funcionaria para os dois lados do proxy? 14:48 < jrandom> por exemplo, vamos querer o conteúdo filtrado localmente, não no endpoint de saída 14:49 < deer> <human> jrandom: poderíamos incentivar os usuários a instalar 14:49 < jrandom> (mas o endpoint de saída vai querer filtrar algum conteúdo para evitar abuso, etc) 14:49 < deer> <human> jrandom: ou pode fazer parte da instalação padrão do I2P 14:49 < aum> e se um DWP (proxy web distribuído) usasse um DHT para seu cache? 14:49 < jrandom> incentivar == só geeks. empacotar :) 14:49 < jrandom> isso seria Bom, aum 14:49 < deer> <human> jrandom: eheheh, combinado :-) 14:49 < deer> <human> jrandom: o privoxy também roda em windogs, a propósito 14:50 < jrandom> word. é, precisamos de algum tipo de filtragem de conteúdo - privoxy, muffin, tanto faz. 14:50 < deer> <wilde> reunião longa... 14:50 * jrandom pega a dica.. 14:51 < deer> <Pellinore> wilde: Tem muita coisa a dizer. 14:51 < jrandom> mais alguém tem algo que queira trazer? sempre temos a lista de discussão para mais coisas 14:51 < deer> <Pellinore> E muito a fazer, claro. 14:51 < deer> <Pellinore> Tenho algumas perguntas pequenas. 14:51 < aum> poderíamos fazer fork do privoxy e 1) fazê-lo funcionar sobre i2p, 2) fazê-lo usar DHT para cache? 14:51 < deer> <Pellinore> Mas são tão fáceis de tratar em privado. 14:51 < jrandom> pellinore> manda 14:51 < deer> <Pellinore> Nada, desculpe ter dito algo. 14:51 < jrandom> aum> muito provavelmente não precisaríamos fazer fork 14:52 < deer> <Pellinore> Vou falar com você sobre isso em privado, ou com o duck, outra hora. 14:52 < deer> <Pellinore> Não é algo realmente específico de dev. 14:52 < deer> <duck> 10+16+7=33 horas-homem desperdiçadas nessa hora extra :) 14:52 < jrandom> mas construir um DHT dá muito trabalho. totalmente incrivelmente válido 14:52 -!- Irssi: #i2p: Total de 10 nicks [0 ops, 0 halfops, 0 voices, 10 normais] 14:52 * aum vai novamente visitar as páginas wiki do infoanarchy.org sobre DHTs 14:52 < jrandom> há 16 pessoas na iip? 14:53 < deer> <human> aum: não precisa fazer fork, apenas: web browser <-> privoxy <-> httpclient <-> i2p <-> outbound proxy <-> www.pr0n.com 14:53 < deer> <wilde> um DHT genérico que funcionaria fora do I2P também, e que permita outros bindings além de http 14:53 < jrandom> aum> confira o link que o duck adicionou ao wiki do i2p, listando vários 14:54 < deer> <human> aum: você pode configurar o privoxy para fazê-lo conectar a outro proxy HTTP/socks (é assim que meu privoxy I2P-para-tor funciona) 14:54 < deer> <duck> (http://www.bamboo-dht.org/) 14:54 < aum> não sei se gosto da ideia de um dht funcionando fora do i2p - o melhor dht é aquele sem anonimato (e a sobrecarga de anonimato) que possa funcionar de forma mais otimizada dentro do i2p 14:54 < jrandom> hrm duck, o que aconteceu com aquela lista deles? 14:54 < deer> <duck> aum: mais fácil de testar 14:55 < deer> <duck> jrandom: algum comunista removeu, eu acho 14:55 < jrandom> heh 14:56 < jrandom> google++ : http://www.etse.urv.es/~cpairot/dhts.html 14:56 < jrandom> (não é a mesma página, mas interessante) 14:56 < jrandom> oh, aqui está a página - http://himalia.it.jyu.fi/ffdoc/storm/pegboard/available_overlays--hemppah/peg.gen.html 14:57 < jrandom> mas sim, um DHT que não tente implementar anonimato, além de um DHT que suporte tanto conteúdo estilo CHK quanto estilo SSK seria o ideal 14:58 < jrandom> (estilo SSK não é estritamente necessário, mas caramba seria muito útil) 14:58 < jrandom> mas, enfim 14:58 < jrandom> alguém tem mais alguma coisa que queira trazer? 14:59 < deer> <duck> amanhã é o Dia de São Patrício 14:59 < deer> <wilde> tópico 5) ? 14:59 < deer> <duck> então todos bebam cerveja irlandesa 14:59 < jrandom> bom ponto 14:59 < deer> <Pellinore> Amanhã é tanto o aniversário do meu relacionamento atual quanto do meu segundo casamento. 14:59 * jrandom toma nota para evitar pubs irlandeses amanhã 15:00 < jrandom> ah, parabéns, pellinore :) 15:00 < jrandom> wilde> estamos no 5) ??? 15:01 < jrandom> (e prestes a estar no 6) [baf]) 15:01 * jrandom vai para a iip em instantes [se eu conseguir] 15:01 * jrandom vai encerrando 15:01 * jrandom encerra a reunião com um *baf*