Reunião de Desenvolvedores do I2P - 18 de maio de 2004

14:07 <jrandom> 0) oi 14:07 <jrandom> 1) status da testnet 14:07 <jrandom> 2) SAM 14:07 <jrandom> 3) atualizações do roadmap 14:07 <jrandom> 4) MyI2P 14:07 <jrandom> 5) ??? 14:07 <jrandom> 0) oi 14:07 * jrandom acena 14:08 <Nightblade> oi 14:08 * jteitel retribui o aceno 14:08 <jar> oi 14:08 <duck> olá 14:08 <Masterboy> :P 14:08 <jrandom> notas semanais de status publicadas até http://dev.i2p.net/pipermail/i2p/2004-May/000239.html 14:09 <jrandom> desculpem se estou meio desligado hoje, meu horário de sono está mais desregulado do que o habitual 14:09 <jrandom> de qualquer forma, passando para 1) status da testnet 14:10 <duck> a diversificação aconteceria automaticamente com uma rede maior, não é? 14:10 <jrandom> sim, e/ou limiares de seleção de peer menos enviesados 14:11 <jrandom> por exemplo, se o limiar de velocidade fosse a mediana em vez da média, teríamos metade de peers rápidos em relação a peers confiáveis 14:11 <jrandom> ao contrário da situação que temos hoje, onde as velocidades estão fortemente distorcidas 14:12 <Masterboy> bom, a rede se recuperou, não é tão ruim 14:12 <jrandom> sim, embora tenha levado mais tempo do que deveria, e revelou maneiras de melhorar 14:13 <jteitel> a rede se recuperou? ainda não consigo conectar ao i2p irc de forma confiável 14:13 <jrandom> os perfis dos peers não decaíram rápido o suficiente, nem promoveram novos candidatos de forma eficiente 14:14 <jrandom> isso também disparou uma cadeia de eventos secundários — sobrecarregando routers que não eram capazes de suportar a carga (devido a perfilamento insuficiente), fazendo com que alguns routers sobrecarregados ficassem sem memória e desligassem 14:15 <human> aiii aiii aiii! 14:15 <jrandom> tem sido uma progressão, jteitel — alguns dos problemas que temos visto estão relacionados às falhas no netDb 14:15 <jrandom> oi, human 14:15 <jteitel> Ah, OK 14:16 <_cervantes_> um router com problemas não poderia transferir tunnels para outro peer? 14:16 <ugha_node> Uau, Taxa acumulada: 8.87KBps enviados 8.35KBps recebidos. 14:16 <Nightblade> jteitel: conectei agora há pouco depois de várias tentativas... ainda esperando o meu /join ser concluído 14:16 * BrianR olha ao redor. 14:16 <jrandom> não — um router pode simplesmente descartar um tunnel (se não deveria tê-lo aceitado em primeiro lugar) 14:16 <ugha_node> (E reiniciei meu router há meia hora) 14:16 <BrianR> droga. estou atrasado. 14:17 <BrianR> jrandom: (Obrigado por deixar o myi2p mais para o fim da pauta) 14:17 <jrandom> ugha> sim, vocês tiveram que compensar por aqueles três rápidos 14:17 <jrandom> hehe :) 14:18 <duck> foi um ataque bacana 14:18 <ugha_node> jrandom: Obviamente. 14:18 <_cervantes_> então não seria melhor ser mais rigoroso e rejeitar tunnels com um limiar mais baixo 14:19 <jrandom> sim, cervantes — os routers hoje nunca rejeitam um tunnel a não ser que não consigam alcançar o próximo salto 14:19 <jrandom> vamos querer incluir algum tipo de throttling (limitação de taxa) aí, talvez com base no tamanho da jobQueue / avg lag, etc 14:20 <jrandom> além disso, vamos garantir que não tentemos construir tunnels demais de uma só vez, como aconteceu quando uma grande parte deles falhou 14:20 <_cervantes_> ou simplesmente permitir que o usuário defina um limiar com base no hardware/largura de banda que sabe que tem disponível 14:20 <jrandom> (devido aos peers rápidos+confiáveis saindo do ar) 14:20 <_cervantes_> pelo menos nesta fase 14:20 <jrandom> ah, bom ponto — permitir que as pessoas definam explicitamente um número máximo de tunnels participantes. 14:21 <jrandom> vamos colocar isso na próxima revisão. boa chamada. 14:21 <ugha_node> Isso soa como lógica fuzzy. 14:21 <jrandom> temos que lidar com sobrecarga, e simplesmente enfileirar mensagens na memória certamente não funciona 14:21 <duck> (oi, fvw) 14:21 <_cervantes_> seria bom ter algum tipo de estatísticas consolidadas sobre o desempenho dos tunnels... o tipo de carga que podem impor a um processador de benchmark 14:22 <_cervantes_> btw tirei meu servidor do ar... estava recebendo uma tonelada de tunnels e ainda não compilei o jbigi ;-) 14:22 <jrandom> veja http://localhost:7655/routerStats.html#Tunnels 14:23 <jrandom> ah! sim, jbigi é algo que queremos encorajar todos a usarem 14:23 <BrianR> Alguma ideia sobre fazer orçamentação de largura de banda para tunnels? 14:24 <jrandom> atualmente previsto para 3.0 (com limitação de largura de banda geral para o router como um todo @ 0.4.1) 14:24 <jrandom> mas ter limites de largura de banda por tunnel antes não faria mal 14:25 <fvw> É sensato gastar esforço nisso tão cedo, quando é muito mais fácil e preciso fazê-lo no kernel dos SOs que a maioria dos usuários/testadores atuais está rodando? 14:25 <_cervantes_> algo que eu gostaria de ver são configurações de profundidade por tunnel (talvez isso já seja possível) 14:25 <_cervantes_> por exemplo, já sei que posso confiar no meu servidor... então não quero ter que passar por _x_ saltos para chegar até ele 14:25 <jrandom> fvw> é um bom ponto, especialmente porque atualmente não devoramos muita largura de banda 14:26 <jrandom> hmm cervantes — sim, cada cliente pode especificar o comprimento dos seus tunnels, mas não tenho certeza de que seja exatamente isso que você quer 14:26 <_cervantes_> não 14:26 <jrandom> cervantes — acho que o que você quer é um QoS (Qualidade de Serviço) onde possa encurtar a conexão para um peer específico 14:26 <_cervantes_> por exemplo... 14:26 <_cervantes_> sim 14:27 <jrandom> (o que estava previsto para i2p 4.0, mas isso está a mais de um ano de distância == infinito) 14:27 <_cervantes_> nesse caso, também selecionar a profundidade por host i2p 14:27 <BrianR> fvw: sim, mas um i2p precisa saber aproximadamente quanta largura de banda os membros potenciais do tunnel têm disponível para tomar decisões sensatas de construção de tunnel... 14:27 <_cervantes_> ah ok 14:27 <_cervantes_> :) 14:27 <jrandom> mas é uma boa ideia, e tecnicamente viável, patches são bem-vindos :) 14:28 <_cervantes_> o patch já está no correio... junto com aquele cheque de 5000 barras de e-gold 14:28 <_cervantes_> ;-) 14:28 <jrandom> BrianR: talvez dê para ir até a metade — acompanhar quantos tunnels está participando, bem como quanta largura de banda esses tunnels estão usando, e usar isso como parte da decisão sobre aceitar ou rejeitar uma solicitação de criação de tunnel? 14:28 <jrandom> heh 14:30 <jrandom> ok, alguém tem mais alguma coisa para o status da testnet? 14:30 <Masterboy> e o meu paradoxo? 14:30 <Masterboy> :) 14:30 <jrandom> meu plano é lançar uma 0.3.1.3 com as atualizações até quinta ou sexta 14:31 <jrandom> Masterboy: não tive tempo de analisar seus logs, mas vamos resolver 14:31 <_cervantes_> sexta 2005? 14:31 <_cervantes_> legal 14:31 <Masterboy> k 14:31 <jrandom> ok, passando para 2) SAM 14:31 <Masterboy> agora sabemos quem está rodando o router desatualizado.. 14:32 * jrandom passa o microfone para o nosso intrépido dev do SAM.pm 14:33 <jrandom> (esse é você, BrianR :) 14:33 <BrianR> Um segundo.. :) 14:33 * duck aplaude 14:33 <jrandom> enquanto isso, dm ou firerabbit por aqui? 14:33 -!- Irssi: #i2p: Total de 26 nicks [0 ops, 0 halfops, 0 voices, 26 normais] 14:33 * jrandom confere o /names, nada. fazer o quê 14:33 <jrandom> (então sem atualizações da SAM lib em .net/C#) 14:34 <duck> o material em .py ainda está atual? 14:34 <duck> ou ficou obsoleto pelas melhorias no SAM 14:34 <jrandom> não tenho certeza 14:34 <BrianR> Ok. Voltei. 14:34 <Nightblade> Minha biblioteca em C parece estar funcionando... embora eu ainda não tenha escrito um aplicativo para usá-la 14:34 <jrandom> mandou bem, nightblade! 14:35 <Nightblade> Alguém aqui já programou GTK+/C no Windows? 14:35 <human> duck: a client lib precisa de uma pequena mudança para suporte a versionamento 14:35 <_cervantes_> "hello world"? 14:35 <human> duck: o resto deve funcionar sem problemas 14:35 * jrandom sugere um datagrama como tftp como o teste ideal para o SAM :) 14:35 <Nightblade> bem, qualquer coisa mesmo... o GTK funciona bem no Windows.....? 14:35 <jrandom> (ou até streaming do SAM em vez de datagram ou raw) 14:36 <jrandom> legal, BrianR — como vão o .pm e o samcat? 14:36 <BrianR> Net::SAM está no CVS em forma majoritariamente não funcional. 14:36 <BrianR> Espero ter todos os bugs resolvidos e datagram e raw funcionando antes do fim da semana. 14:37 <BrianR> Será necessário um pouco mais de trabalho para dar um acabamento OO bacana em streams. 14:37 <Nightblade> ah sim, não me preocupei com datagram ou raw... só stream 14:37 <Nightblade> mas é tudo o que eu usaria de qualquer forma 14:37 <fvw> human: você já considerou o wxWindows? É bem útil para esse tipo de coisa (acho que não há um target GTK para Windows, no entanto) 14:37 <jrandom> excelente, BrianR 14:38 <BrianR> Minha esposa está me chamando para jantar. Posso ou não voltar a tempo para a discussão do myi2p. Publiquei o modelo de ameaças (threat model) e umas coisas de dumb fileserver no nó 208 14:38 <human> fvw: o client do GTK para Windows existe (O GIMP roda no Windows também) 14:38 <jrandom> legal, nightblade, é melhor implementar primeiro o que é necessário 14:38 <human> fvw: s/client/port/ 14:38 <jrandom> heh 'k BrianR, valeu 14:38 <fvw> human: quero dizer um target GTK para Windows no wxWindows (que eu estava sugerindo você usar) 14:38 * fvw acena para BrianR. Bom apetite. 14:38 <human> fvw: ah... bem, não conheço o vxWidgets (novo nome do vxWindows :-) 14:39 <human> fvw: mas era o Nightblade falando sobre GTK+, não eu :-) 14:40 <fvw> Opa, meus olhos estão tortos, ignorem-me. 14:40 <Nightblade> Não sou tão familiar com C++ quanto sou com C 14:40 <Nightblade> que eu saiba, GTK é a única biblioteca GUI C multiplataforma 14:40 <Nightblade> não que eu seja particularmente fã do GTK 14:40 <fvw> não importa muito, o wxWindows é facilmente acessível a partir de C. 14:40 <Nightblade> hmm 14:40 <Nightblade> bem, talvez eu dê uma olhada nisso também 14:40 <Nightblade> eu sei C++, mas não escrevi nenhum programa grande nele 14:41 * fvw também não é programador de C++, mas configurei um visualizador de transações bem grande para uma empresa de transporte nele há um tempo, sem problemas. 14:42 <Nightblade> tenho certeza de que o wxwindows tem um port para Windows mais maduro 14:42 <Nightblade> do que o gtk 14:42 <fvw> bem provável, sim. 14:43 <Nightblade> (ok continuem a reunião) heh 14:43 <jrandom> :) 14:43 <jrandom> ok, pulando para 3) atualizações do roadmap 14:44 * jrandom tem sido negligente em atualizar http://www.i2p.net/roadmap no último mês 14:44 <jrandom> mas agora está atualizado de novo 14:44 <jrandom> infelizmente, obviamente não vamos lançar a 0.4 na próxima semana 14:44 <duck> (1.1, 2.0, 3.0 também estão atualizadas?) 14:45 <jrandom> sim, senhor 14:45 * Masterboy leu, gostou — sem pressa, não estamos pegando fogo.. 14:46 <duck> alguém deveria atualizar a wikipedia/infoanarchy também :) 14:46 <jrandom> ah, eu provavelmente deveria remover o "SAM bridge and client libraries implemented and tested" da 0.4 14:46 <jrandom> heh sim, por isso eu !thwapped o iA um tempo atrás quando eles apenas copiaram a página da wiki 14:46 <jrandom> (eles deveriam apenas apontar para o /roadmap, não duplicar o conteúdo) 14:47 <Masterboy> SAM está pronto? 14:47 <jrandom> está funcional, sim, embora o trabalho em bibliotecas de cliente adicionais esteja em andamento 14:47 <jrandom> s/are/is/ 14:48 <jrandom> ok, a menos que haja mais perguntas/preocupações sobre o roadmap, passando para 4) MyI2P 14:50 <jrandom> embora eu tenha parado de trabalhar no myi2p pessoalmente, abrimos o esforço para um bounty (recompensa) - http://www.i2p.net/node/view/216 14:50 <jrandom> parte disso significa que precisamos acertar os requisitos, e tem havido algum debate sobre quais deveriam ser 14:51 <Masterboy> tentei envolver meu amigo, ele disse trabalho demais, dinheiro de menos ;P bem, ele é capitalista ;) 14:51 <Masterboy> bem, eu me ofereci para programar isso.. 14:52 <jrandom> programar nisso é sempre bem-vindo :) 14:53 <jrandom> a questão arquitetural pendente no momento é como lidar com pessoas que não podem rodar seu router i2p / nó myi2p o tempo todo 14:53 <Nightblade> basta ter algum ISP i2p confiável 14:53 <jrandom> as duas propostas são usar provedores de serviço hospedados ou dividir o sistema para usar um armazenamento de apoio distribuído 14:54 <_cervantes_> sendo a última a solução ideal de longo prazo 14:54 <_cervantes_> *latter 14:54 <duck> (e sendo outro bounty) 14:55 <_cervantes_> ou um serviço de proxy de web cache... 14:55 <jrandom> certo — se fôssemos pelo provedor de serviço hospedado (ou nó executado localmente), quando uma DHT/etc estivesse disponível poderíamos empurrar cada vez mais conteúdo para a DHT 14:55 <jrandom> _cervantes_: isso é essencialmente o armazenamento distribuído de apoio — caches de dados não confiáveis 14:57 <deer> * Masterboy se pergunta onde está o bogobot 14:57 <jrandom> a parte difícil é obter a funcionalidade de controle de acesso necessária — com caches de dados não confiáveis / armazenamento distribuído de apoio, ACLs são essencialmente criptografia 14:57 <jrandom> mas um "canal paralelo" para esta discussão vem dos três pontos levantados por uma pessoa anônima @ http://www.i2p.net/node/view/215#comment-105 14:57 <_cervantes_> e conteúdo assinado 14:58 <jrandom> certo, de qualquer forma será necessário ter conteúdo assinado 15:00 <_cervantes_> é aqui que o modelo do hypercubus tem mérito... mas está longe de ser uma solução "rápida" 15:00 <jrandom> das discussões no irc ontem à noite, focamos no "modelo de ameaças do livejournal" — quais ataques importam para os usuários do LJ e quais não 15:01 <wilde> primeiro o básico, conseguir um MyI2P básico em primeiro lugar 15:02 <jrandom> certo, e para implementar o myi2p básico, precisamos conhecer a arquitetura de implantação 15:03 <jrandom> com o modelo de ameaças do LJ para usuários que não podem executar seus próprios nós, não acho que precisamos seguir pela rota de cache de dados não confiável 15:03 <jrandom> e por que alguém usaria o myi2p se precisa apenas do modelo de ameaças do LJ? porque é anônimo 15:04 <jrandom> poderíamos seguir em busca de um sistema idealizado, mas existe a lei dos retornos decrescentes 15:04 -!- Irssi: #i2p: Total de 24 nicks [0 ops, 0 halfops, 0 voices, 24 normais] 15:05 <jrandom> é por isso que estou inclinado a manter o bounty nos moldes atuais — podemos acrescentar alternativas depois, quando o sistema básico estiver no ar 15:05 -!- duck_ agora é conhecido como duck 15:06 <jrandom> de qualquer forma, acho que é tudo que tenho para 4) MyI2P, a menos que alguém tenha mais algo a levantar 15:06 <jrandom> se não, passando para 5) ??? 15:07 <_cervantes_> hmm você precisa de um martelo grande :) 15:07 <jrandom> esqueci de mencionar o novo eepsite do morph.i2p nas notas da reunião, e o nickster.i2p agora tem um fproxy público disponível! 15:08 <jrandom> (e o sungo.i2p está com a webcam no ar :) 15:08 <_cervantes_> heh... 15:08 <_cervantes_> i2pr0n 15:08 <jrandom> mais alguém tem algo que queira levantar? 15:10 <jrandom> se não, isso nos leva à marca de 70 minutos 15:10 <deer> <Masterboy> não 15:10 * jrandom vai encerrando 15:10 * jrandom fecha a reunião com um *baf*