Reunião de Desenvolvimento do I2P - 30 de dezembro de 2003

<jrandom> 0) oi <jrandom> 1) status do router <jrandom> 2) i2ptunnel <jrandom> 3) im <jrandom> 4) planos para a 0.3 <jrandom> 5) sincronização de tempo <jrandom> 6) ??? <jrandom> olá mihi, polo <polo> olá ! <mihi> oi jrandom <jrandom> 0) oi <jrandom> :) <rsk> oi <i2p> <duck> oi <jrandom> 1) status do router <jrandom> 0.2.3.3 saiu e parece estar funcionando <jrandom> ainda há muito a fazer, claro <jrandom> mas este deve ser o último lançamento 0.2 <jrandom> 0.3 vai adicionar o perfilamento de peers para permitir que routers evitem routers ruins <jrandom> (e 0.3.1 é uma reformulação dos mecanismos de transporte) <jrandom> hola Ophite1 <Ophite1> E aí. <rsk> então mais sobrecarga na 0.3? <jrandom> sim e não <jrandom> vai ter testes de peers, mas será mais focado <rsk> vamos ver um ganho de velocidade com a seleção de caminhos? <jrandom> sim <jrandom> há aquelas calculadoras de 'liveliness', e serão adicionadas novas calculadoras de latência e de taxa de transferência <jrandom> além disso, as pessoas poderão ajustar suas próprias preferências para peers específicos <jrandom> por exemplo, se você sabe que quer preferir o peer X ao peer Y, poderá dar a eles um bônus de ponderação de alguns pontos aleatórios <mihi> vai haver um desligamento limpo? *g* <jrandom> essa é realmente uma boa pergunta, mihi <jrandom> o I2P está chegando ao ponto em que precisa de uma interface de administração. <jrandom> o Job mais demorado que está travando sua operação é o GenerateStatusConsoleJob <jrandom> que agora pode levar de 4 a 6 segundos <jrandom> (segurando todo o resto) <jrandom> isso precisa ir para assíncrono e sob demanda. <jrandom> mas eu não quero escrever um web listener / etc. <jrandom> talvez o inverso - um servlet que inicia o router e se comunica com ele <mihi> você não precisa de um servidor web completo. apenas, quando vir GET, retorne seus dados. <jrandom> certo <jrandom> você tem razão, essas coisas deveriam estar na 0.3 também. <mihi> e quando vir outra coisa (como SHUTDOWN), faça o que quiser. claro, apenas de localhost ;) <jrandom> ahh qualé <mihi> então alguém pode fazer um bom programa de administração <jrandom> certo <mihi> você tinha alguns triggers por arquivos, não tinha? eles estão documentados em algum lugar? >>> mihi [~mihi@ags9-d9ba536a.pool.mediaWays.net] solicitou PING 1072820995 de jrandom <jrandom> aqueles estavam no IDN, não no próprio router <jrandom> mas isso pode ser um bom caminho a seguir <jrandom> é um sistema trivialmente simples <jrandom> boa ideia, vamos por esse caminho <jrandom> (e eu posso simplesmente reutilizar esse código :) <i2p> <duck> esse negócio mágico de arquivos começa a parecer com o plan9 <jrandom> lol <mihi> mas triggers por arquivo exigem polling <jrandom> certo, mihi, ler um diretório a cada 30s não é tão ruim <mihi> mas um ServerSocket#accept é mais barato. <mihi> pois não consome tempo. (assumindo um bom SO) <mihi> ok, triggers por arquivo são melhores do que nada, claro. <jrandom> um server socket permitiria administração remota <jrandom> (quando apropriado) <jrandom> sei lá. <jrandom> algo a ser trabalhado. <jrandom> (ou se alguém quiser abraçar isso e codar... :) <mihi> e o server socket poderia entregar o routerConsole também. <jrandom> certo <jrandom> ok, 2) i2ptunnel <jrandom> :) <jrandom> i2ptunnel ainda manda bem, e parece que queremos adicionar uma API baseada em socket para controlá-lo <i2p> <anon> os planos ic2cp2pc do aum estão cancelados por enquanto? <jrandom> sim, o ci2cp está morto na água, substituído pela API baseada em socket para controlar o I2PTunnel <jrandom> acho que consigo colocar essa API nos próximos dias, para que ele possa avançar na impl <mihi> apenas use um socket, faça in.readLine() e alimente essa linha para runCommand() ;) <rsk> o que a API dá ao I2P? <jrandom> basicamente isso, mihi (exceto que formata os resultados e os envia de volta de uma forma padrão) <mihi> com um "logger" apropriado para enviar os comandos de volta. <mihi> s/commands/results/ <jrandom> rsk> isso permite que desenvolvedores de aplicações construam sockets cliente e servidor sobre o I2P sem lidar com as necessidades de criptografia do I2CP <jrandom> isso, isso <jrandom> i2ptunnel /tem mesmo/ uma sobrecarga em situações onde há muitos i2ptunnels <jrandom> independentemente da JVM <jrandom> clientes i2ptunnel criam um novo destination por cliente contatado, e o router terá um desempenho muito pior à medida que o número de destinations locais cresce. <rsk> ah <jrandom> isso se deve às necessidades de anonimato da rede ligadas à forma como nossa criptografia funciona <jrandom> para aplicações que só querem abrir um tunnel ou dois para um peer, essa nova API vai MANDAR BEM <jrandom> mas para aplicações que precisam falar com muitos outros peers, I2CP é o caminho a seguir. <jrandom> (já que é um único destination, multiplexado pelo i2cp) <jrandom> acho que é aquele velho equilíbrio TCP vs UDP, de certa forma <jrandom> mihi> você tem algum pensamento, ou algumas ideias para o futuro do i2ptunnel? <rsk> como vai o trabalho de ip sobre i2p, ou as coisas de vpn? <mihi> jrandom: alguém escreva uma boa streaming API, e então deixa o i2ptunnel usá-la. <mihi> o mesmo para o naming server. <mihi> talvez adicionar alguns números de sequência se ninguém fizer as coisas acima. <mihi> o que significará uma mudança incompatível. <jrandom> mudanças incompatíveis não são ruins, estamos no começo do dev <jrandom> (se pudéssemos aumentar o tamanho dos IDs também para dois ou quatro bytes por lado?) <mihi> a streaming API será uma mudança incompatível de qualquer forma. e se o i2p funcionasse, não precisaríamos de números de sequência. <jrandom> rsk> em pausa, até alguém ter tempo para levar adiante? ≡ rsk/#i2p acha que mudanças incompatíveis são as melhores <jrandom> isso aí, mihi <mihi> o ID deve ser de 3 bytes no momento, então por que *aumentar* para 2 bytes? <jrandom> mihi> na verdade, eu gostaria de ir descontinuando o mode=GUARANTEED aos poucos e implementar isso na streaming API ≡ mihi/#i2p também <jrandom> deixando i2p = IP, não TCP ou UDP <jrandom> caramba, queria ter mais 14 horas no dia. <mihi> só 14? ;) <jrandom> ;) <jrandom> os IDs de 3 bytes não são derivados por ambos os lados da con? ou talvez eu esteja confuso <mihi> cada lado tem um ID de 3 bytes, porém, apenas um deve ser enviado por vez. <jrandom> talvez eu implemente a streaming API, arranque fora o GUARANTEED e adicione esse controlador por socket em seguida. <jrandom> ah ok <mihi> veja /apps/i2p/i2ptunnel/java/src/protocol.txt <jrandom> isso, isso <mihi> a propósito, quem colocou aquele arquivo *ali*? ≡ jrandom culpa o eco ;) <jrandom> espera, nah, você colocou eles lá <jrandom> não foi? <jrandom> ah espera, não, eu importei eles ≡ jrandom culpa a si mesmo por ser estúpido. <jrandom> (lá lá lá) <jrandom> droga. ok, é, trabalhar na streaming API e no controlador por socket vai me permitir refletir sobre o manifesto de testes / perfilamento / seleção de peers <jrandom> vou postar isso em alguns dias para comentários <jrandom> (e isso vai tirar minha cabeça do router. variety++) <jrandom> mihi> mais alguma coisa sobre i2ptunnel? <mihi> não que eu saiba <jrandom> beleza <jrandom> (obrigado novamente por reservar um tempo para opinar nessas coisas, eu sei que você está ocupado com o fiw e o resto) <jrandom> ok, thecrypto não está aqui, mas ele está progredindo no app de IM. <jrandom> (esse é o item 3 da pauta) <jrandom> 4) planos para a 0.3 <jrandom> 0.3.0 ~= coisas de perfilamento de peers, e agora também incluirá a streaming API e aquele controlador por socket para i2ptunnel <jrandom> mas, se você não adivinhou, não vai ser lançado em 1º de jan <jrandom> 15 de jan é uma possibilidade remota. vamos ver como as coisas andam. <jrandom> 0.3.1 não é um mês inteiro de trabalho, então pode não precisar ser adiada. <jrandom> fora isso, o roteiro ainda está bem encaminhado e representativo de para onde estamos indo <jrandom> 5) sincronização de tempo <jrandom> uma nova FAQ foi publicada em http://wiki.invisiblenet.net/iip-wiki?I2PTiming <jrandom> mihi, você tinha uma sugestão sobre a quarta opção lá (construir nosso próprio timing dentro do I2P)? <jrandom> oi brawl <mihi> sim. ∙φ∙ brawl agora é conhecido como eco_ <eco_> oi pessoal <jrandom> ah, e aí eco <mihi> você deve conectar 3 nós aleatórios e lembrar a diferença entre o tempo médio e o horário local. <jrandom> acabamos de discutir a streaming API / tunnel API <mihi> e então hackear seu próprio getTimeMillis que corrija isso. <Ophite1> mihi: não, você não deveria. <jrandom> mihi> então, se um atacante cria 1000 nós com o horário errado, todo mundo se ferra <jrandom> (já que a média iria enviesar aleatoriamente no meio) <mihi> se um atacante cria 1000 nós, todo mundo se ferra de qualquer forma...? <rsk> isso não seria auto-corretivo? <Ophite1> mihi: ok, 3. <jrandom> não, deveríamos conseguir lidar com isso, mihi. <mihi> ok, então use a média apenas se o desvio padrão for menor que 1s ou algo assim. <rsk> se todo mundo tiver o mesmo horário você está ok, mesmo que esse horário esteja errado, certo? <jrandom> rsk> se todos os 1000 nós estivessem sincronizados, mas e se todos estiverem aleatórios <mihi> use apenas tempos que estejam suficientemente próximos. se não, pegue 3 novos nós. <jrandom> mihi> certo, poderíamos implementar NTP (que basicamente faz o que você diz, usando uma série de médias candidatas para se aproximar iterativamente do horário correto <mihi> mas não precisamos nos preocupar com tudo (como latências de ping), como o NTP faz. <Ophite1> se não fizermos isso, mihi, o tempo lentamente iria recuar. ≡ mihi/#i2p acha que isso é melhor do que deixar os usuários ajustarem seu horário individualmente. <jrandom> então qualquer um que escolha aleatoriamente 3 desses nós enviesados é enviado para sua própria rede privada? <jrandom> e quanto àquela terceira opção - <jrandom> I2P tem um componente que verifica com um servidor NTP real via NTP ou SNTP <mihi> se você tiver apenas nós enviesados na sua netDB, você também está nessa rede privada... <jrandom> em vez de reinventar a roda <Ophite1> embora eu goste parcialmente dessa... <Ophite1> NTP não é assinado, está sujeito a um ataque MITM. <Ophite1> ou envenenamento de cache DNS em, digamos, time.nist.gov <jrandom> certo, Ophite1, embora com 200.000+ hosts SNTP ou NTP, seja um conjunto grande para atacar. <jrandom> definitivamente não sincronizaríamos do time.nist.gov. <Ophite1> conexões do I2P para o servidor de horário da NSA podem levantar algumas sobrancelhas, né? :) <jrandom> e se um atacante for atrás do time.nist.gov, todo mundo em todo lugar é afetado <jrandom> heh <mihi> então combinamos ambos. pergunte a um servidor NTP "real" e ao seu vizinho. se ambos disserem o mesmo, está ok. <jrandom> então ainda /mais/ código ;) <jrandom> mas é, isso é razoável. <Ophite1> Interessante. E se não disserem? <Ophite1> escolhe outro servidor NTP? <jrandom> recuse o peer. <mihi> tente outro servidor NTP e outro peer. <mihi> até você ter uma correspondência. depois recuse todos os peers anteriores. ≡ mihi/#i2p digita mais devagar que o jrandom :( <Ophite1> correspondência dentro de um certo limiar, digamos 1s? <jrandom> 1s seria bom. <jrandom> aceitando peers até cerca de 30s (para lidar com lag) <Ophite1> 1 segundo é ok em conexões MUITO CARREGADAS? <jrandom> já vi a latência em DSL chegar a 5 segundos ao fazer coisas malignas com ela. <jrandom> com TCP ou UDP? <Ophite1> mas então, nesse caso, esse host talvez não seja aquele com o qual você quer sincronizar o horário mesmo ;) <jrandom> certo <Ophite1> UDP. <jrandom> hmm 'k <Ophite1> você pensaria que isso seria descartado :) <i2p> <duck> acho que o problema é mais deixar o usuário saber que há um problema <jrandom> duck> isso é verdade. <i2p> <duck> só depois de vasculhar logs enormes eles veem que o relógio está errado (se encontrarem) <Ophite1> Talvez. Mais ou menos. <i2p> <duck> ou que a porta já está ocupada <jrandom> uma interface de administração seria legal. <i2p> <duck> o mundo é melhor com todo mundo usando NTP conectado ao seu servidor local de stantrum (sp) 2 CTCP Cloaking agora está [On] <jrandom> talvez tenhamos um lançamento 0.4 com um monte de limpezas e coisas para o usuário final, antes de ir para 1.0? <jrandom> certo (stratum) <i2p> <duck> apenas clientes Windows provavelmente não terão isso <i2p> <duck> mas eles também provavelmente não serão estáveis <jrandom> Windows tem NTP <i2p> <duck> então quem liga <Ophite1> duck: Windows XP e Windows Server 2003 incluem NTP. <jrandom> um bocado mais fácil do que com Unix também <Ophite1> sincronizado por padrão com time.windows.com iirc. <jrandom> com opções em lista suspensa para outros <Ophite1> é uma parte essencial da Ativação de Produto do Windows. <Ophite1> não pode expirar se você não sabe a hora :) <jrandom> heh <mihi> sem opção na minha universidade... todos os relógios estão de 1 hora a 5 horas errados. mas talvez eu nem possa rodar I2P lá de qualquer jeito... <Ophite1> mihi: I2P deveria se esforçar especialmente para funcionar em tal situação... <jrandom> mihi> sensacional! você pode ajudar a testar a operação escondida :) <jrandom> à parte, vou viajar um pouco neste verão <jrandom> provavelmente ficarei offline, sem meu laptop. <i2p> <duck> pensamento paralelo: ntp.duck.i2p :) <Ophite1> Veja assim: Brianna Kazaa baixa um novo cliente de compartilhamento de arquivos anônimo super legal que sua melhor amiga disse que era muito bacana e que permite conversar secretamente com as pessoas e tal. Queremos dizer a ela que ela precisa ajustar o relógio dentro de 30 segundos (como ela vai conseguir isso?)? Ou queremos que simplesmente funcione? <jrandom> mas vou garantir que ainda posso estar no I2P usando apenas terminais públicos. CTCP Cloaking agora está [Off] <jrandom> sem dúvida, Ophite1. apenas funcione (com docs para geeks) <jrandom> duck> bootstrap ;) <jrandom> e o I2P /não/ vai exigir root. <Ophite1> esse é o meu ponto. <Ophite1> jrandom: você rodaria um router em uma máquina na qual você não tem root? <jrandom> então sim, uma mistura entre a opção 3 e a 4 <Ophite1> opção 3,5 me parece legal ;) <jrandom> Ophite1> eu rodaria uma centena deles :) <mihi> opção 3,1415926... <jrandom> (e seguir para o próximo laboratório, rodar mais uma centena) <Ophite1> Ooh. Torta. Saborosa.;) <Ophite1> jrandom: eu disse que você não tinha root. Amador. :) <jrandom> lol <jrandom> então é basicamente para aí que estamos olhando. <jrandom> até que a coisa do tempo seja implementada, todos devem usar a opção 1 ou 2. <jrandom> para a opção 2, se alguém puder escrever alguma documentação, eu agradeceria <Ophite1> isso é aceitável por enquanto, pois ainda Não Estamos Prontos para Brianna Kazaa e cia ;) <mihi> para constar: eu não vou testar a "operação escondida". minha conta da universidade já foi desativada uma vez e não quero que ela seja bloqueada outra vez... <Ophite1> mihi: você é o melhor teste que poderíamos ter. <jrandom> Ophite1 > não para teste. <jrandom> 'k mihi, vamos encontrar um jeito, e quando estiver pronto você poderá usá-lo. <Ophite1> OK, talvez não teste. Algumas universidades ficam tão irritadas que te expulsam em vez de apenas te bloquear. <Ophite1> eu conheço alguém na universidade mais anti-compartilhamento e pró-RIAA dos EUA. Ele mantém um dumpsite de 2 Gbit. <jrandom> lol legal <Ophite1> eu reconheço que pouquíssimas pessoas têm essa coragem. <jrandom> ok, é isso de sincronização de tempo. <jrandom> eco_> oi. alguma coisa de BT sobre a qual você queira falar? {ou deixar para a próxima semana} <Ophite1> mas tenha em mente que a maior parte da internet no futuro provavelmente vai se tornar universitária/corporativa. I2P pode ser banido. I2P pode MUITO BEM ser considerado abuso pelos grandes ISPs. I2P terá que funcionar de qualquer forma. <Ophite1> tenho algumas ideias interessantes nessa linha que vou apresentar no futuro. <jrandom> isso aí <Ophite1> (transporte) <rsk> I2P é considerado abuso pelos grandes ISPs, leia seu contrato <Ophite1> rsk: rodar um cache de proxy distribuído? <rsk> rodar qualquer 'servidor' <Ophite1> rsk: não a menos que encaminhe para SMTP ou WWW. <jrandom> rodar serviços de qualquer tipo <jrandom> certo <Ophite1> rsk: hehe, eu tenho uma solução para isso ;) <eco_> jrandom: posso dar uma breve atualização <jrandom> a palavra é sua :) <eco_> estou portando o cliente BitTorrent em Java snark (www.klomp.org/snark) para me familiarizar com o I2P <eco_> o primeiro port roda em cima do i2ptunnel, chamando diretamente as classes Java <eco_> estado atual: funciona com 2 peers, as coisas se bagunçam com > 2, tunnels não são limpos, então reiniciar é doloroso <eco_> eta: neste fim de semana ≡ eco_/#i2p percebe que isso pode ser considerado > 2003 <jrandom> w00t! ≡ jrandom invade o time.nist.gov <eco_> um port "real" provavelmente reduziria a sobrecarga dos tunnels, mas isso é um próximo passo <jrandom> legal ≡ eco_/#i2p devolve a palavra ao mc jrandom <jrandom> 'k, acho que era isso <jrandom> 6) ??? <jrandom> alguém tem mais alguma coisa? ≡ eco_/#i2p gostaria de expressar seus agradecimentos pelo trabalho bem feito por jrandom cs até agora <eco_> e que o sono tem alguma utilidade para o home sapiens, embora jrandom pareça provar o contrário <jrandom> ;) <jrandom> o que vocês acham de nos reunirmos aqui em vez do iip, até o I2P ser confiável o suficiente? <jrandom> pessoalmente, estou cansado de as reuniões serem despedaçadas toda semana. <i2p> <anon> lilo é uma droga! <eco_> podemos estar excluindo pessoas ao vir para cá <jrandom> estamos, eu sei. <jrandom> se conseguirmos uma ponte iip<-->aqui <i2p> <duck> iip está excluindo ppl todos os dias <jrandom> seria bom. <jrandom> certo. <jrandom> iip é, infelizmente, inutilizável para uma comunidade de desenvolvimento confiável. <i2p> <duck> http://banaan.zeelandnet.nl/open/changate.html <i2p> <duck> esse é o código no qual eyeKon etc se baseia <jrandom> e embora eu goste de sair codando por conta própria, vocês aparecem com ideias muito boas e fazem coisas legais que são essenciais ≡ rsk/#i2p está escrevendo um script de atualização do Windows <i2p> <duck> teoricamente ele poderia se conectar a 3 servidores e espelhar cada um deles <jrandom> isso aí, duck, talvez eu tente colocar um rodando em i2p.dnsalias.net <jrandom> ping flood do inferno ;) <eco_> o IRC em duck.i2p esteve bem bom hoje, ganhou do iip <jrandom> concordo <jrandom> mesmo assim, me derrubou algumas vezes. <jrandom> talvez esteja mais confiável na próxima semana <eco_> está nas suas mãos :-) <jrandom> a confiabilidade provavelmente não vai melhorar até a 0.3, que está a ~2 semanas <jrandom> (1 semana para fazer as coisas de tunnel/streaming, 1 semana para perfilamento/testes de peers) <jrandom> depois haverá os bugs que isso introduzir :) <jrandom> embora eu deva dizer que fiquei realmente animado em fazer streaming de áudio a partir do aum ontem à noite <jrandom> e o ardvark conseguiu transmitir por 42 minutos sem buffering! <jrandom> então talvez possamos ser confiáveis o suficiente <jrandom> (meu router local é apenas phttp, o que provavelmente é uma pequena causa) <jrandom> ok, alguém tem mais alguma coisa? <i2p> <duck> não consigo pensar em nada ≡ eco_/#i2p também não consigo ≡ jrandom finaliza... ≡ jrandom *baf* fecha a reunião