Reunião de Desenvolvedores do I2P - 6 de janeiro de 2004

[22:02] <jrand0m> pauta: [22:02] <jrand0m> 0) oi [22:02] <jrand0m> 1) http://i2p.dnsalias.net/pipermail/i2p/2004-January/000069.html [22:02] <jrand0m> 2) [discussion] [22:02] <wiht> Posso adicionar o instalador à pauta? [22:02] <jrand0m> 0) oi [22:02] <jrand0m> ah sim, claro! [22:02] <jrand0m> estamos tentando algo novo esta semana [22:03] <wiht> Você pode colocá-lo no final da pauta. [22:03] <jrand0m> em vez daquele fala fala fala responde fala fala fala, o post http://i2p.dnsalias.net/pipermail/i2p/2004-January/000069.html descreve a maioria das coisas que eu tinha planejado dizer [22:03] * mihi_ entrou em #i2p [22:04] <jrand0m> em vez disso, estamos tentando nesta semana tornar a reunião mais voltada à discussão — coisas sobre as quais as pessoas queiram falar a partir daquele post, quaisquer posts de acompanhamento e/ou qualquer outra coisa que as pessoas queiram discutir [22:04] <jrand0m> como, por exemplo, um novo instalador [22:05] <jrand0m> então, dito isso, as pessoas devem começar conferindo aquele e-mail/post e seguimos a partir daí :) [22:05] * mihi_away agora é conhecido como mihi [22:05] * kaji lê o post [22:05] * mihi_ agora é conhecido como mihi_backup [22:06] <jrand0m> 27 usuários com apenas um duplicado! u0u [22:07] * dm agora é conhecido como dup [22:07] <jrand0m> ok, quando as pessoas tiverem lido, talvez possamos começar passando pelo índice e ver se há algo que alguém queira acrescentar / comentar / discutir? [22:07] <mihi> jrand0m: como você sabe que não há mais duplicatas? [22:07] <jrand0m> hehe valeu dm [22:07] <jrand0m> mihi> Instalei keyloggers nos computadores de todo mundo (bwhahahaha) [22:07] <wiht> Eu gostaria de adicionar instalador como tópico 10 e, possivelmente, serviço de nomes como tópico 11. [22:07] * mihi enviou o followup para o endereço errado :(, reenviando... [22:08] <jrand0m> boa, wiht [22:09] <MrEcho> o novo dns do mrecho está a caminho [22:09] <jrand0m> legal, mihi, sim eu estava me perguntando ;) [22:09] <kaji> como está indo o dns? - ah [22:09] <jrand0m> MrEcho> seu post, certo? [22:09] <MrEcho> trabalhando no post [22:10] <jrand0m> ok, enquanto isso, alguém tem algo sobre 1) streaming? ou devemos pular para 2) I2PTunnel, TunnelManager e i2pmgr? [22:10] <lucky> misericórdia... eu poderia passar o resto da minha vida tentando entender essas dependências. [22:10] <wiht> Então vamos colocar DNS/NS como tópico 11. [22:10] <jrand0m> parece bom, wiht [22:10] * duck entra [22:11] <jrand0m> boa noite, duck [22:11] <mihi> sobre o 1, eu comitei código para i2ptunnel usando a streaming API [22:11] <jrand0m> ah certo, sensacional, mihi :) [22:11] <lucky> oi duck [22:11] * twosandals saiu do IRC (Leaving) [22:11] <kaji> jrand0m vários serviços podem usar a mesma chave se estiverem em portas diferentes? [22:11] <jrand0m> não, kaji [22:11] <mihi> aliás: por que seus arquivos do ant sempre apagam o jar antes de reconstruí-lo? [22:11] <jrand0m> mihi> paranoia [22:12] <mihi> roubando meu tempo de depuração, eu diria ;) [22:12] <jrand0m> kaji> em i2p, uma chave /é/ uma porta, essencialmente [22:12] <jrand0m> hehe [22:12] <kaji> ah [22:13] <jrand0m> mihi> se você quiser atualizar isso, contanto que ele gere o jar se os arquivos .class mudarem, tudo bem [22:13] <mihi> se o arquivo for mais novo do que todos os arquivos dentro dele, e poderia pular caso contrário. [22:13] <jrand0m> certo [22:13] <mihi> e por paranoia é melhor adicionar uma tarefa <depends> [22:13] <jrand0m> concordo [22:13] <FillaMent> yo yo [22:13] <jrand0m> oie, FillaMent [22:14] <jrand0m> ok, 2) i2ptunnel / tunnelmanager / i2pmgr [22:14] * TC entrou em #i2p [22:15] <human> fiz um pequeno hack para fazer o TunnelManager retornar os ids dos jobs quando os comandos "openclient" ou "openserver" são chamados [22:16] <jrand0m> irado :) [22:16] <human> assim, apps usando o TunnelManager sabem qual job fechar depois, sem analisar o output do "list" [22:16] <jrand0m> é, eu não estava muito confortável usando o list e o close do tunnelmanager, já que múltiplos clientes podem se b0rkar desse jeito [22:17] <jrand0m> vamos colocar esse patch logo depois da reunião. gracias, human :) [22:17] <human> isso envolveu fazer I2PTunnel.runCommand retornar algumas coisas (atualmente uma Property) [22:17] <human> s/Property/Properties/ [22:17] <jrand0m> ah certo, há algumas coisas para modificar nisso antes de entrar no código [22:18] <human> mas o mihi preferiria adicionar alguns callbacks assíncronos à classe Logging, pelo que entendo... [22:19] <jrand0m> certo — para que as coisas possam obter informações das tarefas imediatamente, sem esperar elas terminarem [22:20] * mihi saiu do IRC (EOF From client) [22:20] <human> jrand0m: a ideia é: deixar I2PTunnel.runCommand() retornar imediatamente e, eventualmente, usar callbacks para obter mais info, certo? [22:21] <jrand0m> certo [22:21] <jrand0m> então as tarefas disparam callbacks sempre que houver dados a distribuir [22:21] * mihi entrou em #i2p [22:21] <human> bem, IMHO há outra questão: «quantas apps Java (vão) usar I2PTunnel.runCommand() de forma assíncrona?» As apps que atualmente usam I2PTunnel (mesmo via o TunnelManager) estão perfeitamente bem com chamadas .runCommand() síncronas (mesmo que longas), e tornar tudo assíncrono só deixaria as coisas mais complicadas (IMHO) [22:22] * mihi usa via a GUI [22:22] <human> (bem, "todas" significa o TunnelManager e apps que analisam o output do Tunnel manager) [22:22] <jrand0m> certo, a GUI vai travar enquanto o comando é executado [22:22] <mihi> e digitar os próximos 3 comandos de abrir tunnel fica bloqueado enquanto o primeiro está rodando [22:23] <human> mihi: ok, eu não sabia sobre o seu app... então precisamos de alguma solução :-) [22:24] <human> mihi: comportamento assíncrono de .runCommand() exigiria revisar o TunnelManager [22:24] <mihi> human: quando (na sua opinião) o runCommand deve terminar? quando o tunnel é construído, quando a conexão passou? [22:25] <mihi> "destination unreachable" será conhecido *depois* que a primeira tentativa de conexão for feita. [22:25] <jrand0m> o padrão Command teria o execute() retornando apenas após estar completo. [22:26] <mihi> o que *completo* significa? [22:26] <jrand0m> (então, se estivermos seguindo o padrão Command, runCommand bloquearia até que tudo necessário para fazer aquele comando estivesse completo) [22:26] <human> mihi: eheh, essa é a pergunta :-) [22:26] <jrand0m> completo para "server 1234 privkeys" seria quando o servidor puder aceitar conexões na porta 1234 [22:26] <human> mihi: bem, para TunnelServer, IMHO deveria retornar após a criação do tunnel [22:27] <jrand0m> completo para "client 234 peer" seria quando uma conexão à porta 234 alcançasse com sucesso peer [22:27] <jrand0m> pelo menos, é assim que vejo [22:27] <mihi> como você determina o último? [22:27] <jrand0m> eu realmente não tenho opinião forte de um jeito ou de outro [22:27] <jrand0m> talvez um ping? [22:27] * Sciatica entrou em #i2p [22:28] <mihi> e se o peer cair logo após o ping? [22:28] <mihi> na minha opinião é impossível fazer apps de rede sem callbacks [22:28] <jrand0m> certo [22:28] <mihi> ou um monte de threads, e eu prefiro callbacks a threads sincronizadas até a morte [22:29] <jrand0m> talvez deva retornar apenas depois que conseguir /tentar/ conectar? [22:29] <jrand0m> ou talvez o padrão Command não seja o padrão desejado [22:29] <mihi> é isso que faz agora. e que resultado deveria retornar então? [22:30] <mihi> o ponto é que você quer ter um resultado (diferente de um int para o id da conexão) [22:30] <jrand0m> certo, para o comando client, quer-se o job (para que possa ser fechado depois), mas para o comando genkey, quer-se a chave pública e a chave privada [22:30] * mihi não consegue pensar em qualquer outra info que seja conhecida nesse ponto. [22:30] <jrand0m> concordo, eu também não. [22:31] <dup> 0! [22:31] <mihi> e genkey deve esperar? ok, se você acha. [22:31] <human> mihi: bem, algo como um status ("ok" ou "error") e mensagens de erro... [22:31] <mihi> human: mensagens de erro serão "tarde demais" IMO [22:31] <mihi> mas façam como quiserem... [22:32] <mihi> contanto que façam funcionar com a streaming API depois também... [22:32] <jrand0m> os pontos doloridos que o human está abordando são as gambiarras no TunnelManager que analisam as mensagens de logging. mas eu concordo, contanto que possamos expor essa informação via a interface de logging, tudo bem [22:32] <dup> mihi é sábio. [22:32] <human> human: algumas podem ser comunicadas imediatamente (por exemplo, quando a porta do tunnel ainda está em uso) [22:32] <mihi> human está falando consigo mesmo ;) [22:32] <human> opa! :-) [22:35] <human> talvez devêssemos ver que tipo de aplicações estão sendo construídas sobre o I2PTunnel [22:35] <human> a interface assíncrona é a Right Thing(TM), mas é mais complicada de usar [22:35] <jrand0m> Acho melhor se pudermos manter a mesma funcionalidade para o software atual — incluindo a GUI. [22:35] <FillaMent> talvez eu esteja entrando ignorantemente, mas talvez um método como se encontra em muitos que lidam com HTTP: getHeader(String headerName) [22:35] <FillaMent> me smake conforme necessário [22:35] <FillaMent> smack [22:36] * jrand0m smake'a o FillaMent [22:36] <human> e o TunnelManager não precisa disso (já que ele *nunca* será capaz de suportar adequadamente eventos assíncronos, devido à sua natureza) [22:36] * kaji tem uma ideia completamente off-topic [22:36] * FillaMent resigna-se à militância =) [22:37] <human> mas se a aplicação do mihi precisa monitorar o estado dos tunnels, então a interface assíncrona é um Must(TM) [22:37] <jrand0m> human> java -jar lib/I2PTunnel.jar\n. Precisamos suportar async. [22:37] <kaji> i2p como um applet Java para você poder rodar de computadores estranhos rapidamente indo a um website [22:37] * Sciatica saiu do IRC (EOF From client) [22:37] <human> jrand0m: sim, então precisamos refazer o TunnelManager :-) [22:37] <jrand0m> kaji> i2p 3.0 :) [22:38] <jrand0m> concordo, human, a implementação do tunnelmanager foi uma implementação rápida e suja [22:38] <jrand0m> você acha que poderia ver como isso precisaria prosseguir? [22:38] * human pode se voluntariar para adaptar o TunnelManager à interface assíncrona, quando estiver pronta [22:38] <jrand0m> w00t :) [22:40] <jrand0m> ok, estamos prontos para o item 3) I2COCP [22:40] <human> caso contrário, seria possível criar métodos síncronos e assíncronos para o I2PTunnel [22:40] <jrand0m> verdade [22:40] <jrand0m> mas duplicação pode ser exagero quando um pouco de refatoração serviria ao propósito [22:41] * baffled saiu do IRC (Leaving) [22:41] <duck> preocupação pessoal sobre os tunnels: apps não os fechando, então todo o seu tunnelmanager fica inundado [22:41] <human> jrand0m: sim, devemos escolher a solução mais fácil entre refazer o TunnelManager ou adicionar novas APIs ao I2PTunnel :-) [22:42] <jrand0m> é um bom ponto, duck. atualmente não há timeouts/expirações, e assume-se que os apps usando o tunnelManager se comportem bem (e que o tunnelManager não tenha bugs [hah!]) [22:43] <mihi> a propósito de novas APIs: as classes da Streaming API devem "substituir" as antigas ou deve ser possível usar ambas (com comandos diferentes?) [22:43] <jrand0m> mihi> acho que as de streaming vão querer substituir, já que quando a streaming API estiver sólida o mode=GUARANTEED vai sumir [22:43] <jrand0m> (e portanto as antigas não funcionarão) [22:44] * MrEcho 's email sent [22:46] <jrand0m> mais algo para a discussão de tunnels? (obviamente isso não é o fim das discussões de tunnels no geral ;) [22:47] * dup agora é conhecido como dm [22:47] <jrand0m> ok, I2COCP [22:47] <jrand0m> isso foi algo que o human sugeriu outro dia e parece preencher uma lacuna que não é atendida atualmente. mas acho que queremos adiar a implementação até termos algo que queira usá-la :) [22:48] <wiht> Esse é um nome um tanto longo, mesmo abreviado. [22:48] * jrand0m agora chama I2COCP de "Wilma" [22:48] <human> jrand0m: bem, eu ia escrever as mesmas palavras :-) [22:48] <jrand0m> hehe, legal [22:49] <jrand0m> ok, pulando para 4) roadmap [22:49] <human> jrand0m: IMHO, em geral, deveria haver uma forma de apps não-Java terem acesso razoavelmente completo à rede I2P [22:49] <jrand0m> concordo [22:49] <jrand0m> a intenção é que elas usem I2CP [22:50] <jrand0m> (como todas as apps Java, incluindo i2ptunnel e a biblioteca de streaming, usam isso) [22:50] <human> jrand0m: sim [22:50] <MrEcho> I2PDNS "Janessa" [22:50] <jrand0m> mas você está certo, elas também vão querer streaming, então ou tunnelmanager->i2ptunnel ou i2cocp->biblioteca de streaming [22:50] * jrand0m nunca conheceu uma Janessa [22:51] * Sciatica entrou em #i2p [22:51] <jrand0m> ok, então, sim, o roadmap foi atualizado. sem mudanças muito grandes além de adiar 0.3 e 0.3.1 por 2 semanas, adicionar info da 2.0 e alguns critérios a mais da 1.0 [22:51] <human> jrand0m: sim, deveria haver protocolos tipo "TCP" e "UDP" para I2P, com relatório completo de eventos de protocolo, acessíveis por apps não-Java [22:52] <MrEcho> human, parece bom [22:52] <jrand0m> Quero que haja toda interface possível, mas não quero me comprometer demais com interfaces demais para suportar [22:52] * human queria I2COCP (ou o que for) para seu transporte do I2P para Twisted (veja http://www.twistedmatrix.com/), mas por ora vai feliz fazer uma gambiarra em volta do TunnelManager :-) [22:53] * w0rmus saiu do IRC (Lost terminal) [22:53] <jrand0m> isso aí. seria o melhor por enquanto [22:54] <jrand0m> ok, algum comentário sobre o roadmap? [22:55] <jrand0m> [nada a ver aqui, la la] [22:55] <jrand0m> ok, 5) i2pIM [22:55] <jrand0m> thecrypto não está aqui, então podemos só esperar um post para i2p@ com atualizações :) [22:55] <wiht> Temos Jabber agora, se não me engano. Ainda precisamos do i2pIM? [22:55] <jrand0m> sim [22:55] <jrand0m> jabber tem um servidor que recebe texto plano. [22:56] <wiht> Ah. Muito bem, então; eu não sabia disso. [22:56] <jrand0m> são duas faltas (um servidor e texto plano) [22:56] <jrand0m> é uma boa solução para algumas coisas, certamente [22:56] <jrand0m> na verdade, uma coisa em que pensei hoje de manhã foi se poderíamos juntar i2pIM e i2psnark, isso seria Bom. [22:57] <jrand0m> (mas uma coisa de cada vez) [22:57] <jrand0m> falando no diabo, 6) i2psnark :) [22:57] <human> jrand0m: às vezes usei jabber com gnupg... [22:57] <jrand0m> para chats com >2 pessoas? [22:58] <jrand0m> para um a um, concordo totalmente que existem soluções [23:01] <jrand0m> ok, vamos a uma divertida, 7) apresentando I.Toopie :) [23:01] <human> como você implementaria chats criptografados com >2 pessoas? uma chave privada compartilhada? [23:01] <jrand0m> sim, human [23:01] <jrand0m> ou através de n! chaves compartilhadas no grupo [23:02] <human> bem, talvez pudesse ser feito acima do protocolo jabber existente... [23:02] <mihi> human: uma chave simétrica compartilhada enviada a todos os participantes [23:02] <jrand0m> a parte difícil é lidar com entradas & saídas — rotação de chaves /etc [23:03] * Sciatica saiu do IRC (Ping timeout) [23:03] <jrand0m> não é de forma alguma trivial. é muito, muito, muito difícil. [23:03] * mihi reconhece [23:03] * human concorda [23:04] <jrand0m> (por isso ter um app projetado para isso em vez de tentar uma gambiarra em cima de outro protocolo pode valer a pena) [23:04] <jrand0m> mas o thecrypto pode descrever melhor seus planos [23:04] <jrand0m> (embora pelo que entendo ele ainda esteja aberto a ideias de como lidar com grupos) [23:05] * Sciatica entrou em #i2p [23:06] <jrand0m> ok, seguindo :) [mais discussão em i2p@, etc] [23:06] <wiht> O que é I.Toopee, afinal? [23:06] <lucky> o mascote... [23:06] <jrand0m> I.Toopie é um cara segurando uma máscara amarela na frente do rosto [23:06] * lucky estremece. [23:07] <lucky> aham. [23:07] <lucky> posso ver? [23:07] <jrand0m> http://wiki.invisiblenet.net/iip-wiki?I2PLogo [23:07] * mihi_backup saiu do IRC (EOF From client) [23:07] <lucky> adicionei Java à minha fila de compilação... [23:07] <lucky> mas.. lol [23:07] <lucky> já tenho 7 coisas rodando [23:07] <lucky> vai demorar. [23:08] <lucky> aw, fofo :P [23:08] <MrEcho> lol [23:08] <jrand0m> houve muitos logos legais (não acredito que estamos com o concurso de logo há 3 meses!), e parece que temos um potencial forte com o I.Toopie. na sua simplicidade, sua concepção e sua versatilidade. [23:08] <jrand0m> e, sim, é fofo ;) [23:08] <mihi> algumas imgs estão quebradas ou meu navegador está bugado? [23:08] <jrand0m> sim, algumas estão quebradas [23:09] <jrand0m> (foram colocadas em hospedagens temporárias 3 meses atrás) [23:09] <MrEcho> o bastão do I.Toopie agora é todo amarelo ... [23:09] <MrEcho> mudei ontem à noite [23:09] <jrand0m> é mesmo? [23:09] <jrand0m> as pessoas deveriam ATUALIZAR A WIKI então [23:09] <jrand0m> ;) [23:09] <MrEcho> hehe [23:09] <MrEcho> não tenho mais a foto .. sorry [23:10] <wiht> Vejo as imagens com o Opera, mas não com o Mozilla, por algum motivo. [23:10] <jrand0m> você consegue ver http://img.villagephotos.com/p/2003-10/437060/badass.webp ? [23:10] <jrand0m> (essa é uma das imagens naquela página) [23:11] <duck> Access Denied (User Account Disabled) [23:11] <jrand0m> sim, aqui também. [23:11] <MrEcho> eu consigo ver [23:11] <jrand0m> mas sim, DrWoo fez umas paradas iradas com o I.Toopie [23:11] <MrEcho> moz 1.5 [23:11] * soros saiu do IRC (EOF From client) [23:11] * mihi_away entrou em #i2p [23:11] * lucky saiu do IRC (EOF From client) [23:12] <jrand0m> aqui também, MrEcho. estranho. [23:12] <wiht> MrEcho: Estou usando Mozilla 1.4. [23:12] <jrand0m> (mesmo no sentido de que estou no moz 1.5 e estou recebendo acesso negado) [23:13] * jrand0m aguarda ansioso por um ícone de tray com o i.toopie :) [23:13] <jrand0m> ok, passando para 8) servidor de xadrez [23:14] * Sciatica saiu do IRC (Ping timeout) [23:14] * ion saiu do IRC (Ping timeout) [23:14] <jrand0m> o hosts.txt mais recente (http://i2p.dnsalias.net/i2p/hosts.txt) contém a referência para chess.fillament.i2p [23:14] <jrand0m> você pode usar qualquer cliente FICS antigo ou apenas telnet para lá e jogar :) [23:14] <jrand0m> (yay) [23:15] <kaji> existe um bom cliente fics para windows? [23:15] <jrand0m> não sei, acabei usando telnet [23:15] <wiht> eboard funciona? [23:15] <jrand0m> (o que teve uma curva de aprendizado bem difícil para aprender os comandos) [23:15] * ion entrou em #i2p [23:16] <jrand0m> não sei [23:16] * BpX entrou em #i2p [23:16] <wiht> Vou testar mais tarde. [23:16] <jrand0m> legal, se você puder postar o que encontrar, seria ótimo [23:17] <jrand0m> ok, 9) DHT [23:17] * wilde saiu do IRC (Ping timeout) [23:17] <jrand0m> ainda não temos uma dht, mas talvez isso seja uma pista de algo que podemos começar a portar [23:18] <jrand0m> (usa UDP, então fazer usar I2CP não seria difícil) [23:18] <MrEcho> dht??? [23:18] <MrEcho> deu branco nessa [23:18] <jrand0m> MrEcho> veja [10] no e-mail ;) [23:18] <jrand0m> http://wiki.invisiblenet.net/iip-wiki?DHT [23:18] <Nightblade> entropy é bom o suficiente como solução temporária [23:18] <jrand0m> concordo [23:19] <jrand0m> embora eu ache que precisamos olhar também para uma solução de longo prazo [23:19] * soros entrou em #i2p [23:19] * lucky entrou em #i2p [23:20] * human está preocupado com compatibilidade gcj/kaffe com DHTs como Bamboo (http://bamboo-dht.org/) [23:20] <jrand0m> sim, bamboo é 1.4 [23:20] <MrEcho> afk [23:20] <jrand0m> essa é a glória do i2cp — o router & tunnels podem ser compilados com gcj, enquanto as coisas que os acessam podem ser qualquer coisa [23:21] <jrand0m> é /puramente/ para um app, porém — não como parte do core [23:21] <jrand0m> só estou tentando pensar em coisas que ajudariam os usuários finais que acabam baixando i2p a fazer algo útil logo de cara [23:22] <jrand0m> (poder publicar conteúdo incensurável anonimamente seria algo útil) [23:22] <jrand0m> s/uncensorable/very censorship resistant/ [23:23] <human> jrand0m: ah, ok - achei que bamboo iria substituir Kademlia para o NetworkDB :-) [23:23] <Nightblade> o proxy squid é algo que eles podem fazer... para usuários por exemplo na China isso seria uma coisa muito legal de ter [23:23] <jrand0m> Nightblade> certo, mas o squid não é escalável [23:24] <Nightblade> sim, acho que seria interessante ter uma espécie de JAP distribuído [23:24] <jrand0m> concordo [23:24] <jrand0m> então isso também é outra coisa que seria ótimo se as pessoas pudessem averiguar :) [23:24] <mihi> Nightblade: o problema é lidar com abuso — eu não vou abrir minha máquina para qualquer HTTP de saída [23:24] <jrand0m> tenho certeza que algumas pessoas vão [23:25] <Nightblade> com uma parte adicional onde um nó individual possa escolher quais sites quer fazer proxy para as pessoas... um cliente poderia enviar uma requisição para "whitehouse.com" e então um dos nós que faz o proxy e permite essa url pode responder [23:25] <Nightblade> sim, acho que teria que ter algum tipo de controle de acesso [23:25] <Nightblade> blacklist ou whitelist [23:25] <jrand0m> certo [23:25] <Nightblade> de nomes de domínio [23:26] <jrand0m> é o sistema de "exit policy". embora isso seja um projeto inteiro por si só [23:27] <MrEcho> poderia andar sobre o sistema de DNS... acho [23:27] <jrand0m> certamente [23:27] <wiht> mihi: E se você limitar a largura de banda usada? Ou são os websites acessados que poderiam te causar problemas? [23:27] <MrEcho> numa data bem depois lol [23:27] <jrand0m> wiht> muitos provedores proíbem explicitamente rodar servidores de qualquer tipo [23:28] <MrEcho> a verizon fode com a porta 21 com certeza... [23:28] <wiht> jrand0m: Ah. Sim, isso é um problema. [23:28] <Nightblade> teria que haver alguma forma para clientes solicitarem os sites que querem baixados para eles.. Broadcast de requisições não é uma solução muito boa, especialmente no i2p [23:29] <mihi> wiht: o problema são os websites que podem ser acessados. compare com o processo do JAP algum tempo atrás. /me mora no mesmo país [23:29] <jrand0m> concordo. embora broadcast não seja possível sem forçar à bruta um espaço de chaves de ~2^2300 ;) [23:30] <jrand0m> certo, mihi, pessoas em regimes opressores não conseguiriam rodar outproxies com segurança [23:30] <wiht> mihi: Qual foi o processo? Não me lembro. [23:30] * dm saiu do IRC (Ping timeout) [23:30] <Nightblade> quero dizer, mesmo que você tivesse uma lista de destinos que fornecem proxy web, você não iria querer ter que fazer broadcast para todos [23:30] <jrand0m> certo, Nightblade [23:30] <Nightblade> broadcast de requisições, quero dizer [23:31] <mihi> o problema foi que alguém acessou um site de pornografia infantil e foi por um proxy do JAP e não podiam dizer de onde veio a requisição. isso foi interpretado como atrapalhar o trabalho da polícia [23:31] <jrand0m> talvez o pessoal queira ver crowds ou rewebber para ver outros projetos que trabalharam nessa mesma tarefa [23:31] <wiht> mihi: Ah. Obrigado pela explicação. Entendo por que você está preocupado agora. [23:31] * mihi_away saiu do IRC (Ping timeout) [23:31] <mihi> e fizeram aquela mudança no software do jap que torna possível pegar pessoas. que foi removida depois [23:32] <wiht> Er, entendo por que você está preocupado. [23:32] <mihi> no fim saiu que o JAP não teria que divulgar os dados, mas eu não quero saber quanto custaram os advogados... [23:32] <Nightblade> sim, mas a polícia não apreendeu a informação de qualquer jeito? [23:32] <jrand0m> sim [23:33] <mihi> eles apreenderam... [23:33] <jrand0m> mas enfim, sim, tanto uma DHT escalável quanto um proxy web escalável seriam Coisas Realmente Boas de ter até a 1.0 [23:34] <mihi> e eles não podem devolver, podem? [23:34] * BpX saiu do IRC (Ping timeout) [23:36] * Sciatica entrou em #i2p [23:36] <jrand0m> ok, mais algo para o ponto 9? ou vamos para 10/11) NS/DNS? [23:36] <wiht> Gostaria de fazer um comentário breve sobre o instalador depois do tópico 10. [23:37] <jrand0m> 'k talvez vamos a isso agora, já que NS/DNS pode não ser super breve? ;) [23:37] <wiht> Tudo bem. O router tem um script de start e um script de stop. [23:37] <jrand0m> certo [23:37] <wiht> Eu gostaria que todos os serviços fossem feitos desse jeito — tivessem um script de start e um de stop. [23:37] <jrand0m> a maioria tem [23:37] <jrand0m> não tem? [23:38] <jrand0m> ah, não scripts de stop [23:38] <wiht> Não, só o router. [23:38] <wiht> Assim, serviços desejados poderiam ser iniciados na inicialização do computador, como o router. Eu fiz um post nesse sentido na lista. [23:38] <jrand0m> aum está trabalhando no i2pmgr, que vai ser tanto um centro de controle em console quanto baseado em GUI para os serviços e para o próprio router [23:38] <wiht> Digamos que eu quero iniciar o eep e o nntp na inicialização. Atualmente, não posso fazer isso. [23:39] <jrand0m> certo, você precisaria fazer nohup startEepProxy.sh & [23:39] <wiht> Certo. A propósito, onde estão esses scripts no CVS? [23:39] <MrEcho> ok voltei [23:39] * mihi_away entrou em #i2p [23:39] <jrand0m> wiht> os scripts estão no Install.java (vulgo hackeado) [23:39] <wiht> jrand0m: Obrigado./ [23:40] <jrand0m> mas bom ponto, queremos que seja o mais simples possível iniciar na inicialização, assim como iniciar sob demanda [23:41] <jrand0m> ok, para 10/11) ns/dns [23:41] <MrEcho> bem, confiram meu e-mail [23:41] <MrEcho> tem algumas coisas que esqueci de colocar lá [23:41] <jrand0m> infelizmente seu e-mail não ficou legal na interface web :/ [23:41] <MrEcho> tipo nomes "temporários" [23:41] <MrEcho> ?? [23:42] * Sciatica saiu do IRC (Ping timeout) [23:42] * ion saiu do IRC (Ping timeout) [23:42] <jrand0m> MrEcho> http://i2p.dnsalias.net/pipermail/i2p/2004-January/000072.html [23:42] <MrEcho> por causa do gif ou algo assim [23:42] <MrEcho> merda .. eu assinei [23:43] <MrEcho> desculpa [23:43] <jrand0m> a lista é realmente destinada a ser apenas texto. assinaturas pgp são ok (outros já postaram coisas assinadas) [23:43] <kaji> qual é um bom antivírus gratuito e pequeno? [23:43] * ion entrou em #i2p [23:43] <jrand0m> kaji> linux [23:43] * Sciatica entrou em #i2p [23:43] <wiht> LOL. [23:43] <kaji> que rode com meu hardware [23:43] <wiht> kaji: Tente AVG Antivirus para Windows. [23:44] * MrEcho_ entrou em #i2p [23:44] * MrEcho saiu do IRC (EOF From client) [23:44] <MrEcho_> porra de iip [23:44] <jrand0m> MrEcho / (e qualquer outra pessoa interessada em NS/DNS)> você leu http://zooko.com/distnames.html ? [23:44] <MrEcho_> j, devo reenviar o e-mail? [23:44] <jrand0m> ele chegou à lista, só não foi arquivado na web corretamente [23:44] <MrEcho_> ya [23:45] <wiht> jrand0m: Eu ainda não li. [23:45] <MrEcho_> vou dar uma olhada mais tarde [23:45] * mrflibble entrou em #i2p [23:45] <jrand0m> para quem não está na lista, eu salvei o e-mail do MrEcho_ em http://i2p.dnsalias.net/~jrandom/mrecho_dns.txt [23:46] <MrEcho_> valeu, J [23:46] <kaji> é chato, ele quer um endereço de email [23:46] <jrand0m> minha preocupação é com a segurança e a escalabilidade do serviço de nomes. quando encontrarmos uma solução que atenda a essas necessidades, fantástico, mas até lá, devemos ter cuidado com soluções intermediárias. [23:47] <jrand0m> kaji> listas de e-mail geralmente querem um endereço de email, sim ;) [23:47] <kaji> quero dizer o AVG Antivirus [23:47] <jrand0m> ah ;) [23:48] <wiht> MrEcho tem várias boas ideias que eu não tinha na minha especificação, como uma lista de banimento para clientes ruins. [23:49] <MrEcho_> não exatamente uma lista de banimento [23:49] <jrand0m> quando houver 1000 clientes, isso significa que levaria 125 buscas para encontrar um valor? [23:49] <MrEcho_> não [23:49] <wiht> Não uma lista, mas banir clientes ruins é algo que eu não tinha. [23:50] <MrEcho_> 2-4 clientes para verificação [23:50] <jrand0m> então todo cliente terá 250 entradas? [23:50] * mihi_away agora é conhecido como mihi_backup [23:50] <MrEcho_> não [23:50] <wiht> Com o que eu tenho, seria uma busca, possivelmente encaminhada algumas vezes para chegar a um servidor autoritativo. [23:50] <MrEcho_> clientes só terão o que precisam [23:51] <MrEcho_> ele continuará consultando outros Clientes até obter dados que correspondam para a verificação [23:51] <jrand0m> então com 4 pares, faria uma busca aleatória e, em média, levaria 125 buscas [23:51] <jrand0m> (1000/4/2) [23:51] <jrand0m> ou os pares formam uma DHT? [23:52] <jrand0m> (com algum protocolo de manutenção?) [23:52] <jrand0m> ou uma árvore de busca? [23:52] <MrEcho_> de certo modo sim [23:52] <MrEcho_> vou ter um limite nas buscas de cliente, ele vai apenas consultar o MS [23:53] <jrand0m> nomeação distribuída segura é um problema bastante estudado — o que tornaria sua proposta mais fácil de analisar quanto à segurança e escalabilidade seria se você pudesse fazer comparações e validar variações de outras abordagens, talvez? [23:54] <MrEcho_> se não encontrar / ou não obtiver dados suficientes dos Clientes dentro de um intervalo definido, então apenas consultará o MS. [23:54] <jrand0m> do jeito que está, não há detalhes suficientes para que eu tenha confiança na escalabilidade ou segurança da arquitetura. não quer dizer que não possa dar certo, só não consigo ver isso ainda. [23:54] <MrEcho_> pode parar de digitar um segundo [23:54] * jrand0m para de digitar. [23:55] <MrEcho_> vai funcionar .. vai ter escalabilidade, vai ter segurança [23:56] <MrEcho_> quanto mais usuários, melhor vai ficar [23:56] <jrand0m> então é "confia em mim", é? [23:56] <MrEcho_> você confia no sistema de DNS da Internet? [23:56] <jrand0m> para algumas tarefas. [23:57] <jrand0m> para muitas, não. [23:57] <jrand0m> (é bem fácil para governos / etc fazerem registros mudarem — processos judiciais ordenam registrars a atualizar o tempo todo) [23:58] <MrEcho_> a única outra forma de fazer é ter listas enormes de Nomes e muita cripto em cada cliente [23:58] <MrEcho_> e ser dinâmico... esquece [23:59] * mrflibble saiu do IRC (EOF From client) [23:59] <jrand0m> sugiro revisar o paper do zooko antes de prosseguir, e responder ao ponto final 5 dele ("why I'm wrong") Session Time: Wed Jan 07 00:00:00 2004 [00:01] <jrand0m> ok, isso provavelmente é tudo para o ponto 10/11 (muita discussão futura ainda restando sobre isso, claro) [00:02] <jrand0m> alguém tem outros pensamentos, etc? [00:02] <wiht> Sim. [00:03] <jrand0m> quer compartilhar com a turma? :) [00:03] <wiht> Vou reescrever a especificação que escrevi. Gostaria de usar um servidor SQL local para armazenar dados, não arquivos. [00:03] <jrand0m> ah, legal [00:03] <jrand0m> (as mesmas preocupações valem para a spec que você escreveu também — se puder responder à última pergunta do zooko, seria fundamental :) [00:03] * mrflibble entrou em #i2p [00:03] <wiht> Deixe o MySQL ou um servidor similar gerenciar o armazenamento de dados, e deixe o Java consultar esse servidor. [00:04] <duck> hein? especificações do zooko? [00:04] <wiht> Acho que será mais fácil de implementar. [00:04] <jrand0m> duck> não, só estou apontando as pessoas para o artigo antigo dele "Names: Decentralized, Secure, Human-Meaningful: Choose Two" [00:04] <duck> ah, esse [00:04] <Nightblade> wiht: qual especificação é essa (perdi boa parte da reunião)? [00:04] * MrEcho entrou em #i2p [00:04] <jrand0m> (bem mais fácil do que refazer por que supernode/servidores centralizados são questões assustadoras de segurança ;) [00:05] * MrEcho_ saiu do IRC (EOF From client) [00:05] * mihi teria algo para o log também ;) [00:05] <mihi> algo mais longo ;) [00:05] <mihi> *** I2Ping resultados: [00:05] <mihi> + + + eco.i2p [00:05] <mihi> + - - jabber.duck.i2p [00:05] <mihi> - + + i2pcvs.i2p [00:05] <mihi> - + + duck.i2p [00:05] <mihi> - + - jap.eco.i2p [00:05] <jrand0m> Nightblade> foi postado no iip-dev lá em... agosto? [00:05] <mihi> - + + irc.duck.i2p [00:05] <mihi> - + + human.i2p [00:06] <mihi> - - + nntp.duck.i2p [00:06] <mihi> - - - tc.i2p [00:06] <mihi> - - - dyad.i2p [00:06] <mihi> - - - bozo.i2p [00:06] <mihi> - - - ogg.aum.i2p [00:06] <mihi> - - - fcp.entropy.i2p [00:06] <mihi> - - - http.entropy.i2p [00:06] <Nightblade> jrandom: oh, antes do meu tempo.. :) [00:06] <mihi> - - - www.mail.i2p [00:06] <mihi> - - - mp3.aum.i2p [00:06] <mihi> - - - smtp.mail.i2p [00:06] <wiht> Nightblade: Eu postei em 15 de setembro. [00:06] <mihi> - - - pop.mail.i2p [00:06] <mihi> - - - mp3.tc.i2p [00:06] <mihi> - - - lp.i2p [00:06] <mihi> - - - kaji.i2p [00:06] <mihi> - - - nm.i2p [00:06] <mihi> - - - squid.i2p [00:06] <mihi> - - - chess.fillament.i2p [00:06] <mihi> - - - mesh.firerabbit.i2p [00:06] <mihi> - - - nightblade.i2p [00:06] <mihi> - - - aum.i2p [00:06] <MrEcho> puxa, alguém está de pé e rodando? [00:06] <mihi> - - - fillament.i2p [00:06] <mihi> *** Terminado. [00:06] <mihi> por que tantos hosts estão fora...? [00:06] * jrand0m não está rodando meus servidores no momento [00:07] <FillaMent> Consigo conectar a mim mesmo tanto no eep quanto no chess [00:07] * mrflibble saiu do IRC (Ping timeout) [00:07] <jrand0m> ah espere, i2pcvs está no ar, bacana [00:07] <Nightblade> mihi: o meu não está no ar porque o i2ptunnel trava para mim depois de algumas horas [00:07] <mihi> então meu router está quebrado (ou são os problemas usuais do I2P...) [00:08] <jrand0m> sério, Nightblade? por favor reporte travamentos do i2ptunnel (bugzilla seria legal) [00:08] <Nightblade> está no bugzilla [00:08] <lucky> oi [00:08] <Nightblade> segura.. [00:08] <FillaMent> Nightblade: qual JVM? [00:08] <Nightblade> #39 [00:08] <wiht> Meu router está rodando há mais de 12 horas agora, embora tenha tido um problema ao se registrar. [00:09] <Nightblade> java version "1.4.2-p5" [00:09] <Nightblade> no freebsd... pode ser problema da jvm, não sei. suporte a java não é muito bom no freebsd [00:09] <jrand0m> você tem razão, Nightblade, minha culpa [00:09] <jrand0m> esse é o bug de i2cp relativamente infrequente [00:09] <jrand0m> isso é consistente pra você? [00:09] <Nightblade> o router é bem estável pra mim, só o tunnel server do i2ptunnel me dá problemas [00:09] <Nightblade> sim, aconteceu várias vezes [00:10] <Nightblade> não testei recentemente, porém [00:10] * jrand0m acabou de puxar o eepsite do fillament [00:10] <jrand0m> (primeira tentativa, acabei de notar que a janela completou) [00:10] <FillaMent> É,, acabei de jabberar com o duck, o wiht está tentando acessar o chess [00:10] <jrand0m> ah legal [00:10] <jrand0m> mas sim, ainda há problemas de confiabilidade a serem tratados na rede. [00:10] * FillaMent cutuca as pessoas com o incluso piscadela, "Ele provavelmente vai querer jogar." [00:10] * human 's eepsite ainda está no ar - significa que 'killall java' ajudou mesmo... :-) [00:10] <wiht> Acabei de conectar com sucesso ao servidor de xadrez. [00:10] <duck> é? [00:11] <jrand0m> lol FillaMent [00:11] * mrflibble entrou em #i2p [00:12] <Nightblade> é seguro rodar a versão cvs do i2p [00:12] <jrand0m> /me buscou com sucesso o 1984-2004: vinte anos de GNU! do human :-) [00:12] <jrand0m> sim, Nightblade [00:12] <FillaMent> não consegui pegar eco... [00:12] <Nightblade> ok talvez eu tente isso [00:12] <duck> com freenet você deve sempre rodar a última versão cvs! [00:13] <duck> só então não tem bugs [00:13] <duck> s/freenet/i2p/ [00:13] * jrand0m puxou eco.i2p [00:13] <FillaMent> acabei de pegar duck [00:13] <jrand0m> "Jan 4: First field test of I2PSnark. Pretty catastrophic: no transfer at all. Guess my single router test environment wasn't very representative :-) Back to the drawing board... " [00:13] <jrand0m> d'oh [00:13] <duck> bem, na verdade funcionou [00:13] <duck> ardvark conseguiu snarkar algo de mim [00:14] <jrand0m> bt pré-cria os arquivos — os arquivos estavam realmente válidos? [00:14] <duck> mas descobriu no dia seguinte [00:14] <duck> porque estava obscurecido nos logs [00:14] <jrand0m> o quê, você quer dizer que os logs que o i2p gera são bem insanos? naaaaooo [00:14] <duck> não [00:14] <duck> o output do i2psnark [00:14] <jrand0m> ah [00:15] <duck> além disso, suspeito que o snark faz churning demais (sp?) [00:15] <duck> o cliente bittorrent normal parece ser mais leve [00:15] <duck> também os altos atrasos no i2p podem causar blocos prematuros [00:16] * mrflibble saiu do IRC (Ping timeout) [00:16] <duck> última coisa é que tivemos que reiniciar o i2ptunnel algumas vezes :/ [00:16] <jrand0m> concordo [00:16] <human> pergunta final sobre I2PTunnel / I2PTunnelManager (sim, eu sei, sou chato): e o meu patch para fazer "openclient" e "openserver" retornarem um jobId significativo? [00:16] <jrand0m> então, sim, muito trabalho a fazer [00:16] <human> 1. vamos aceitar para fazer o TunnelManager funcionar até que a nova arquitetura assíncrona esteja ficando foda [00:17] <human> 2. seu patch é uma merda, vai se foder, e foda-se o TunnelManager [00:17] <human> 3. ... [00:17] * MrEcho_ entrou em #i2p [00:17] * mihi é pelo 3 ;) [00:17] * MrEcho saiu do IRC (EOF From client) [00:17] <jrand0m> 4. vamos ver como podemos atualizar o tunnel manager para ficar async? não deve ser muito difícil [00:17] <jrand0m> o patch é bom, mas o mihi tem um ponto [00:18] <human> jrand0m: sim, concordo [00:18] <jrand0m> ainda temos 1+ semanas até a 0.3, então temos tempo até o próximo release completo [00:18] <human> jrand0m: mas minha dúvida é: quanto tempo vai levar para ter a interface async implementada no TunnelManager? [00:18] <jrand0m> o próprio tunnelmanager levou 2 horas, eu poderia adicionar async hoje à noite [00:19] <jrand0m> (tudo que precisa acontecer é uma atualização no BufferedLogging para aceitar chamadas .set) [00:19] <human> jrand0m: (com "ter" eu também quero dizer "ter implementado até no I2PTunnel) [00:19] <jrand0m> (ou .nofity/etc) [00:19] <jrand0m> certo [00:19] * mrflibble entrou em #i2p [00:20] <jrand0m> se você preferir, eu poderia começar com seu patch (que adiciona o job id) e mesclar com as atualizações para async [00:21] <human> jrand0m: eu poderia adicionar a interface async ao TunnelManager eu mesmo, mas a interface ainda não existe :-) [00:22] <jrand0m> certo, só adicione public void notifyEvent(String eventName, Object value); ao Logging.java [00:22] <human> jrand0m: eu sugeriria "vamos mesclar a gambiarra para fazer os job ids na release 0.3 funcionarem de algum modo, e depois trabalhar na interface async" [00:23] <jrand0m> 0.3 ainda está um pouco longe [00:23] <mihi> 0.3 deveria ter a streaming API de qualquer forma, não deveria? [00:23] <human> jrand0m: estou falando do pior caso [00:23] <wiht> jrand0m: Talvez devesse haver outra versão antes da 3.0 para acertar essas questões? [00:23] <jrand0m> sim, mihi [00:23] <mihi> human: o pior caso é "cvs rollback && patch -p0 your.patch" [00:24] <jrand0m> ok, que tal isso. Vou implementar e fazer commit do async hoje à noite, se você puder olhar amanhã, human, e ver o que precisa ser feito para colocar sua atualização lá? [00:26] <FillaMent> jrand0m: você tem um emprego? [00:27] <jrand0m> i2p [00:27] <duck> faça a 1.0! [00:27] <FillaMent> Quero dizer uma fonte de renda [00:27] <jrand0m> :) [00:27] <FillaMent> pela qual você tenha que trabalhar [00:27] <jrand0m> renda é superestimada. [00:27] * jrand0m demitiu meu chefe [00:27] <Nightblade> "programo por comida" - esse é meu lema [00:27] <Nightblade> lol [00:27] <human> mihi: bem, mas eu e aum (que está trabalhando em um app Python para o TunnelManager) gostaríamos de ter jobIds o quanto antes... [00:28] <human> jrand0m: ok, vou trabalhar nas suas mudanças mais tarde/amanhã [00:28] <FillaMent> Emprego/Dinheiro, sono/higiene, comida, projetos paralelos, vida social: Escolha quaisquer 3 [00:29] * jrand0m só escolhe um. [00:29] <jrand0m> valeu, human [00:30] <FillaMent> Alguém tem outras ideias de serviços "só tunelar para" que seria legal ter na rede? [00:30] * jrand0m ainda quer um Adventure via telnet :) [00:30] <jrand0m> ou uma waffle BBS [00:30] * duck agora é conhecido como enduser [00:30] * jrand0m chuta o enduser [00:31] <jrand0m> (droga, sem ops) [00:31] <FillaMent> Para OS/2 havia um driver de comunicação que podia mapear uma porta COM para uma porta TCP =) [00:31] <enduser> que diferença eu verei como enduser quando I2PTunnel usar a SteamingAPI? [00:31] * enduser agora é conhecido como duck [00:31] <jrand0m> nenhuma [00:31] <human> lol [00:31] <FillaMent> FillaMent: um amigo meu rodou uma BBS assim por um tempo [00:31] <jrand0m> desempenho, e talvez anonimato [00:31] * human gostaria de um I2P tunnel para um rootshell [00:32] <human> voluntários? :-) [00:32] <duck> rootshell em um UML [00:32] <jrand0m> rootshells em chroot seriam bons [00:32] <jrand0m> ou em UML :) [00:32] <FillaMent> human: se eu tivesse um boxen sobrando, eu faria [00:32] <jrand0m> hehe FillaMent [00:32] <duck> conexão vnc para meu vmware win98? [00:32] <FillaMent> falando sério, galera... [00:32] <wiht> Servidor de e-mail também seria bom. Ou já temos isso? [00:32] <FillaMent> wiht: acho que o TC tem pop e SMTP [00:33] <jrand0m> esse é o aum, mas estão offline, pois a máquina dele está offline [00:33] * human poderia oferecer contas de telnet no seu sistema GNU/Hurd... [00:33] <jrand0m> ooOOoo [00:33] <FillaMent> bem, não estou muito a fim de configurar SMTP aberto ainda [00:33] <jrand0m> compreensível [00:34] <FillaMent> talvez quando a rede estiver mais estável e eu tiver dinheiro para aumentar minha banda [00:34] <wiht> E quanto a um servidor de chaves PGP? [00:34] <mihi> FillaMent: você poderia configurar um tunnel apontando para um remailer em claro [00:34] <FillaMent> wiht: agora ISSO é uma ótima ideia =) [00:35] <FillaMent> mihi heh... eu poderia apenas apontar o tunnel para o meu servidor SMTP do ISP =) [00:35] <mihi> FillaMent: isso tornaria *você* responsável por abuso... [00:35] <mihi> s/be// [00:35] <duck> http://www.mit.edu/people/marc/pks/pks.html [00:36] <duck> falando sério, a duck enterprises deveria considerar rodar um servidor de chaves pgp? [00:37] <FillaMent> duck: eu estava fuçando nisso também... quer cuidar disso? [00:37] <duck> temos sido um dos provedores de serviço mais estáveis de acordo com os logs de ping independentes do mihi [00:37] <jrand0m> hehe [00:37] <wiht> duck: Sim, por favor considere. [00:37] <jrand0m> a propósito, duck, como você faz isso? você reinicia periodicamente ou apenas roda em um SO e JVM confiáveis? [00:38] <FillaMent> pergunta: a JVM faz cache de resoluções de DNS? [00:38] <duck> reiniciar é para atualizações de kernel [00:38] <jrand0m> sim, mas dá para fazer umas malandragens para evitar, FillaMent [00:38] * wiht observa que a reunião já dura 2h40m. [00:38] <jrand0m> ah é, [00:39] * mrflibble levanta a mão [00:39] <jrand0m> hum, o log desta reunião vai ficar enorme. e eu aqui pensando que postar as coisas de antemão iria /encurtar/ a reunião [00:39] <jrand0m> diga, mrflibble? [00:39] <FillaMent> jrand0m: ok... porque estou sem quedas mas meu IP muda periodicamente... meu script de atualização do dyndns roda todo hora então no máximo 60+~10min do meu addy nomeado não apontando para meu IP... [00:39] <FillaMent> como isso afetaria a presença do meu router na rede? [00:40] <mrflibble> minha máquina poderia ficar disponível para algum tipo de coisa daemony [00:40] <jrand0m> legal, FillaMent, não deve ser muito problema, desde que você aponte para seu dyndns [00:40] <wiht> mrflibble: demony? [00:40] <mrflibble> acho que depende de quanta banda a coisa usaria [00:40] <mrflibble> daemony [00:40] <jrand0m> w3rd mrflibble — o router tem funcionado de forma confiável para você, ou você está apenas sendo um bom samaritano? :) [00:41] <mrflibble> não muito, mas é porque minha banda local está saturada no momento [00:41] <mrflibble> não estou rodando no meu colo ainda [00:41] <mrflibble> quero brincar localmente primeiro [00:41] <jrand0m> ah legal. sim, i2p ainda não está pronto para implantação ampla, ainda é principalmente para testes [00:42] <FillaMent> Heh.. vou apontar um tunnel para meu servidor CUPS e vocês podem ter impressão anônima =) [00:42] <jrand0m> rofl [00:42] <mrflibble> se tiver algo que você quer que eu rode que use <40gb de banda por mês, avisa [00:42] <FillaMent> só incluir uma página de banner para eu saber para onde enviar a cópia impressa =) [00:42] <mrflibble> hehe [00:43] <jrand0m> massa, mrflibble, tenho certeza de que vamos aceitar essa oferta :) [00:43] <mihi> banner | lpr ? ;) [00:43] <FillaMent> mihi você pode configurar o CUPS com uma página de banner [00:43] <mrflibble> oky doky! [00:43] <mihi> banner provavelmente vai criar muitas páginas ;) [00:43] <jrand0m> ok, antes de chegarmos à discussão de gateway mixminion->impressora->correios, vamos encerrar esta reunião ;) [00:44] * jrand0m prepara o *baf*'er [00:44] * jrand0m *baf* encerra a reunião.