Reunião de Desenvolvedores do I2P - 8 de março de 2005

13:06 <@jrandom> 0) oi 13:06 <@jrandom> 1) 0.5.0.2 13:06 <@jrandom> 2) atualizações do mail.i2p 13:06 <@jrandom> 3) atualizações do i2p-bt 13:06 <legion> então isso é relacionado aos servidores de IRC? 13:06 <@jrandom> 4) ??? 13:06 <@jrandom> 0) oi 13:06 <@jrandom> notas semanais de status no ar @ http://dev.i2p.net/pipermail/i2p/2005-March/000633.html 13:07 <fedo> oi 13:07 <+postman> oi 13:07 <frosk> bom dia 13:07 <@jrandom> legion: não, relacionado a bugs do I2P, estão sendo trabalhados 13:07 <bla> oi 13:07 <legion> ok 13:07 <@jrandom> falando em bugs em que estamos trabalhando, vamos direto para 1) 0.5.0.2 :) 13:07 <cervantes> olá 13:07 <cervantes> -- Desconectado 13:08 <@jrandom> hehe 13:08 <ant> <mihi> oi, pessoal 13:08 <@jrandom> 0.5.0.2 saiu e, embora sua conexão de IRC possa ter lag às vezes, ela se recupera ;) 13:08 <@jrandom> uau, e aí, mihi 13:09 <cervantes> e aí, mihi 13:09 <@jrandom> as notas de status dão uma visão geral de como estão as coisas e das prioridades mais imediatas 13:10 <@jrandom> a coisa assustadora que estou tentando rastrear pode ser vista em http://localhost:7657/oldstats.jsp#router.invalidMessageTime 13:10 <bla> Quanto a mim, posso dizer que a 0.5.0.2 já melhorou a confiabilidade _vastamente_ em comparação com a 0.5.0.1: erros em que destinos não podiam ser contatados quase não ocorrem mais 13:10 <@jrandom> esses números deveriam ser muito, muito pequenos, mas não são, infelizmente 13:10 <@jrandom> irado, bla 13:11 <@jrandom> sim, a 0.5.0.2 é definitivamente uma melhoria, e todos deveriam atualizar o quanto antes 13:11 <bla> 375,932.22 nos últimos 10 minutos aqui.... 13:11 <@jrandom> bem, o valor em si não é realmente o problema, é a frequência deles 13:11 <@jrandom> (eventos por período) 13:12 <@jrandom> essas mensagens provavelmente podem ser atribuídas a routers 0.5, e parte delas a routers 0.5.0.1, por isso quero que as pessoas atualizem o quanto antes 13:12 <@jrandom> pode ser que seja outra coisa, porém eu gostaria de descartar isso 13:12 <bla> jrandom: eu tenho cerca de 200 por hora aqui 13:13 <@jrandom> bla: atualmente tenho 93 nesta hora, mas o pico foi bem maior (milhares) 13:13 <@jrandom> de qualquer forma, essa estatística em particular é publicada no netdb 13:13 <bla> jrandom: que tal excluir 0.5-0 da rede via software ao lançar a 0.5.0.3? 13:14 <@jrandom> assim podemos todos olhar em volta e ver que valores outras pessoas têm ;) 13:14 <@duck> 309,854.24 pico 5,473,314.59 13:15 <@duck> colei o errado, né 13:15 <@jrandom> bla: com certeza. Eu adicionei algum código na revisão 0.5.0.2 para fazer uma certa compatibilidade futura que a 0.5.0.1 e a 0.5 não têm 13:16 <@jrandom> duck: é difícil ter um número não inteiro de eventos ;) 13:16 <bla> jrandom: Bom. Pelo menos isso permite testar sua hipótese de que mensagens inválidas são devidas ao 0.5-0 de forma controlada 13:16 <@jrandom> bla: pois é, embora seria ótimo se as pessoas atualizassem antes disso ;) 13:17 <@jrandom> (então, para quem está lendo em casa: http://www.i2p.net/download é seu amigo ;) 13:17 <maestro^> jr: esses números de desvios de router.invalidMessageTime em ms? 13:17 <@jrandom> maestro^: sim 13:18 <@jrandom> (também conhecido como alguns valores absurdamente distorcidos) 13:18 <legion> Aqui vai um pequeno relatório da rede [versão|Número de nós][0.5|6][0.5.0.1|39][0.5.0.2|107] 13:18 <@jrandom> sim, vocês têm sido ótimos em atualizar 13:18 <legion> Então ainda há algumas pessoas rodando 0.5 e muitas rodando 0.5.0.1 13:18 <maestro^> então alguma ideia de onde eles podem estar com lag? 13:18 <bla> jrandom: o Freenet tem um flag em cada release que especifica a versão mínima do nó com a qual vai se comunicar. O novo código de compatibilidade futura é algo assim? 13:19 <@jrandom> maestro^: muitas, muitas ideias do porquê usuários 0.5 e 0.5.0.1 estão com lag. 13:19 <@jrandom> bla: semelhante 13:19 <maestro^> ou é desvio de relógio nos nós? 13:20 <@jrandom> maestro^: desvio de relógio, alguns bugs de serialização, o bug de CPU a 100% 13:20 <@jrandom> ok, esse é geralmente meu foco no momento, tentando recuperar a confiabilidade das mensagens 13:21 <@jrandom> alguém tem perguntas/comentários/preocupações sobre a 0.5.0.2? 13:21 <ant> * mihi tem um router 0.4.2.5 aqui no hd que não é iniciado desde 22 de dez... mas ele acha melhor deletar... 13:21 <@jrandom> hehe 13:21 <@jrandom> sim, isso não vai conversar com muitos routers ;) 13:21 * postman tem uma cópia de backup da última instalação 0.4 :) 13:21 <ant> <mihi> a pergunta pra mim seria atualizar ou deletar. 13:22 <@jrandom> deletar 13:22 <@jrandom> (fazendo backup de quaisquer destination keys) 13:22 <@jrandom> não há mais procedimento de upgrade a partir de pré-0.5 13:22 <legion> Talvez lançar outra atualização, digamos 0.5.0.2-1, que só permita conexões de 0.5.0.2 ou mais novo, seria bom? 13:22 <@jrandom> legion: isso segmentaria a rede 13:22 <@jrandom> as pessoas deveriam apenas atualizar. 13:23 <@jrandom> (e devemos contornar aqueles que não o fazem) 13:24 <legion> sim, até que as pessoas rodando nós desatualizados atualizem ;) 13:24 <@jrandom> segmentar a rede prejudica a todos nós, não apenas eles 13:25 <legion> Talvez se houvesse uma notificação de atualização no console do router ou algo que os avisasse que estão rodando versões desatualizadas? 13:25 <@jrandom> sim, isso certamente seria bem legal 13:25 <@jrandom> com sorte isso pode ser integrado ao atualizador também 13:26 <legion> sim, eu sei, segmentação é ruim... 13:26 <@jrandom> smeghead está trabalhando em alguns dos componentes-chave disso, embora não tenha certeza se isso inclui a notificação / download 13:26 <@jrandom> (então, se alguém quiser ajudar nisso, entre em contato!) 13:27 <@jrandom> ok, seguindo para 2) atualizações do mail.i2p 13:27 <@jrandom> postman: ping 13:27 <+postman> sim 13:27 <bla> jrandom: o smeghead estava fazendo umas coisas relacionadas a assinatura, se bem me lembro (para que, quando você receber um aviso de atualização, pelo menos saiba que é real, e não uma coisa de phishing/spyware/lixo) 13:28 * postman assume o microfone 13:28 <legion> hmm, talvez se houvesse um recurso de atualização automática embutido, onde as atualizações fossem baixadas pelo I2P e os nós simplesmente baixassem a atualização e então fizessem um reinício suave. 13:28 <@jrandom> isso aí, bla 13:28 <ant> <Gatak> Ah, a propósito. O I2P funcionaria atrás de NAT mesmo se você não puder abrir uma porta? 13:28 <@jrandom> Gatak: ainda não. algumas pessoas vão conseguir na 0.6, outras na 2.0 13:29 <@jrandom> legion: patches são bem-vindos 13:29 <ant> <Gatak> 2.0 poxa, isso está bem no futuro =) 13:29 <@jrandom> (http://www.i2p.net/roadmap#2.0 ;) 13:29 <+postman> erm, devo começar agora? 13:29 <aum> bom dia a todos 13:30 <@jrandom> o microfone é todo seu, postman (foi mal ;) 13:30 <@jrandom> olá, aum, conseguiu chegar para a reunião 13:30 <@jrandom> (d'oh! /me fica quieto de novo) 13:30 <cervantes> Gatek: http://www.i2p.net/roadmap 13:30 <+postman> primeiro, eu queria dizer que já chegamos a 300 contas registradas no postman.i2p 13:30 <@jrandom> w00t 13:30 <+postman> o número de e-mails de/para a Internet está crescendo de forma constante e mais uma vez prova que precisamos avançar 13:31 <cervantes> *iiiiii* 13:31 <+postman> depois de falar com o jr algumas semanas atrás, concordamos em lançar o v2mail junto com o I2P 1.0 13:31 <+postman> o status recente é: o proxy SMTP baseado em Java projetado para rodar em todo nó está pronto 13:31 <@jrandom> legal! 13:32 <+postman> o proxy POP3 baseado em Java está em 80%, faltando apenas o motor de maildir 13:32 <+postman> haverá um gerenciador via web que ainda precisa de bastante ajuste (15% concluído) 13:32 <+postman> a comunicação entre nós está em 40% - testamos alguma troca de registros de dados com HTTP/XML 13:33 <+postman> parece funcionar muito bem e até rápido 13:33 <+postman> mesmo se um relay node falhar/ficar desligado por alguns dias, ele será sincronizado em poucos minutos após voltar online novamente 13:33 <@jrandom> irado 13:33 <+postman> acho que estamos bem no caminho 13:34 <+postman> uma coisa é digna de nota 13:34 <bla> postman: Bom trabalho, cara! Uma pergunta: muitos nós não podem receber ou enviar dados na porta 25 (pelo menos não diretamente). Os donos dos nós poderão especificar isso (ou isso será autodetectado)? 13:34 <cervantes> massa 13:34 <+postman> bla: depois 13:34 <+postman> no v2mail haverá um webapp rodando localmente 13:34 <+postman> com isso você pode gerenciar seus proxies locais E solicitar uma "relayaccount" 13:35 <+postman> essa relayaccount será então usada para associar seu endereço/domínio aos relays 13:35 <+postman> os relays irão sincronizar as informações automaticamente 13:35 <@jrandom> legal 13:35 <+postman> até recursos como o catálogo de endereços / chaves públicas e afins vão funcionar com a interface LOCAL 13:36 <+postman> então a ideia é ter um gerenciador centralizado onde você pode fazer todas as suas coisas de e-mail 13:36 <+postman> os dados relevantes são transferidos para UM dos relays e então sincronizados entre os relays 13:36 <+postman> e esse gerenciador baseado na web vai rodar no seu próprio nó 13:37 <+postman> quando seu nó estiver online, os relays entregarão os e-mails em fila para seu destino/domínio/endereço 13:37 <+postman> ele será entregue ao seu proxy SMTP local 13:37 <+postman> você pode até acionar tudo com ETRN :) 13:37 <aum> oi de novo 13:37 <aum> eu gostaria de levantar um ponto de discussão nesta reunião, se estiver ok 13:37 <+postman> era isso sobre o futuro, pessoal :) 13:37 <+postman> . 13:38 <@jrandom> parece animal, postman 13:38 * postman devolve o microfone 13:38 <@jrandom> aum: ótimo, deve haver tempo em 4) 13:38 <+postman> sim, estou em êxtase :) 13:38 <@jrandom> postman: então, para o usuário normal, o proxy SMTP terá o maildir local, e o proxy POP3 vai ler/etc., certo? 13:39 <+postman> sim, o proxy SMTP tem um MDA 13:39 <+postman> e vai entregar o e-mail em maildirs locais 13:39 <+postman> várias contas/usuários podem até ser criados localmente 13:39 <cervantes> postman: os relays vão acompanhar suas cotas etc. e propagar essas informações entre si? 13:39 <+postman> e mapeados para contas do seu domínio 13:39 <+postman> cervantes: sim, vão 13:39 <septu_ssh> desculpe, posso perguntar ao postman sobre mecanismos de pagamento/anti-spam no novo modelo? 13:40 <+postman> septu_ssh: você leu algum dos documentos na página? 13:40 <+postman> cervantes: não é em tempo real perfeito 13:40 <+postman> cervantes: mas eu fico satisfeito com uma atualização em alguns minutos na troca de informações de cota 13:40 <septu_ssh> postman: está na fila para leitura :/ 13:40 <septu_ssh> mas se está documentado, então tudo bem 13:40 <cervantes> postman: sim, imaginei 13:41 <+postman> septu_ssh: www.postman.i2p/inout.html 13:41 <+postman> septu_ssh: www.postman.i2p/mailv2.html 13:41 <+postman> cervantes: isso não é drama, de verdade — a cota é um limite sensato 13:41 <cervantes> postman: mesmo alguém podendo enviar para nrelays * quota destinatários não é algo ruim 13:41 * septu_ssh é bungle 13:41 <+postman> cervantes: isso 13:42 <+postman> o objetivo é apenas impedir que alguém abuse de verdade do serviço 13:42 <+postman> nos testes em que tive 3 relays, foi realmente rápido 13:42 <@jrandom> postman: esqueci, isso terá suporte para o SMTP relay local falar diretamente com o SMTP relay de outra pessoa, em vez de passar pelos seus nós? 13:42 <+postman> cervantes: em 10 segundos eles foram sincronizados :) 13:43 <@jrandom> (ou talvez isso fique para depois) 13:43 <+postman> jrandom: os i2p mail relays serão operados por várias pessoas e são os destinos preferidos para rotear e-mail 13:43 <cervantes> postman: você poderia introduzir um atraso exponencial na fila de envio 13:43 <cervantes> se isso virar um problema 13:43 <+postman> jrandom: então enviar para outros destinos pode ser útil em certas circunstâncias 13:44 <@jrandom> sim, embora perigoso em outras 13:44 <cervantes> então quanto mais e-mail você envia, maior o tempo que o e-mail fica na fila... deve dar tempo para os relays alcançarem 13:44 <+postman> jrandom: mas se o dono de um nó divulgar seu destino IMIO ele pode ser spammado sem controle :) 13:44 <@jrandom> exatamente 13:44 <@jrandom> por outro lado, o mesmo vale se os i2p mail relays forem hostis 13:45 <+postman> jrandom: de fato, é uma construção tipo WOT (web of trust) 13:45 <@jrandom> </tinFoil> 13:45 <+postman> jrandom: eu não posso impedir um operador de relay de distribuir uma cota de 0 para o seu endereço 13:45 <@jrandom> 'k ótimo. sim, não há necessidade de se preocupar com isso por enquanto 13:45 <+postman> :) 13:46 <+postman> ok 13:46 <+postman> . 13:46 <@jrandom> ok, legal, obrigado pela atualização. coisas realmente empolgantes 13:46 <@jrandom> ok, passando para 3) atualizações do i2p-bt 13:46 <@jrandom> duck: ping 13:46 <@duck> oi 13:47 <@duck> Ontem o BitTorren 4.0.0 foi lançado 13:47 <ant> <dm> parece alemão 13:47 <@duck> que nós mais ou menos estávamos esperando antes de começar a 0.2 13:47 <@duck> escrevi uma tasklist / todo: http://pastebin.ca/raw/7037 13:47 <@duck> (desculpem, meu www está fora do ar no momento) 13:48 <@jrandom> legal 13:48 <legion> de que tipo de cronograma estamos falando para a 0.2? 13:48 <@duck> a meta era 4 semanas 13:49 <legion> legal 13:49 <@duck> como você pode ver, o RawServer (a parte que se comunica com o i2p) é a maior tarefa 13:50 <@duck> . 13:50 <@duck> uma enquete rápida: 13:50 <legion> sim, estou bem ciente disso :) 13:50 <@duck> quem está planejando criar um fork do i2p-bt? 13:50 <@jrandom> legal, há algo que as pessoas possam fazer para ajudar? 13:50 <@jrandom> hehe 13:51 <ant> <dm> eu 13:51 * jrandom pega uma colher 13:51 <ant> <dm> tô disposto a ajudar 13:51 <legion> eu 13:51 <ant> <dm> sou gay 13:51 <legion> estou trabalhando em um fork 13:52 <@duck> bom, então eu sei quem não levar a sério. 13:52 <@duck> sério, acho isso bobo; somar recursos pode levar vocês muito mais longe 13:53 <@jrandom> ou talvez, se houver maneiras melhores de fazer, vocês possam convencer o duck a trabalhar assim? 13:53 <named> Vou escrever um fork em qbasic, por favor me levem a sério. 13:53 <@duck> vou tentar deixar o processo mais aberto, para que outros possam ver o que está planejado etc. 13:53 <ant> <dm> sua abertura não está nos convencendo. FORK! FORK! FORK! FORK! 13:53 <@duck> se vocês tiverem outras sugestões 13:54 <ant> * dm ergue o legion nos ombros. 13:54 <legion> hmm, isso pode ser verdade, embora com o que estou fazendo eu duvido que vocês queiram que eu polua o processo principal de desenvolvimento do i2p-bt ;) 13:54 <ant> <dm> FORK! FORK! FORK! FORK! 13:54 <@jrandom> legion: o que você está fazendo que o duck não iria querer suportar? 13:55 <@duck> legion: parabéns, se você procurar no Google por 'i2p bittorrent', então um anúncio de "Windows I2P Bittorrent Version 1.0" é o #1 13:55 <@jrandom> jesus 13:56 <bla> jrandom: Sim? 13:56 <+postman> jrandom: sim, eles vão arregaçar essa rede em breve :) 13:56 <bla> ;) 13:56 <named> 1.0? Puxa, estou usando 0.1.8! 13:56 <Ragnarok> ei 13:57 <legion> omfg, sério?! Não posso acreditar... isso é insano. 13:57 <@duck> de qualquer forma, não acho que haja muito novo a dizer sobre isso 13:57 <legion> minha release 1.0 é baseada na 0.1.8; se você está rodando 0.1.8 está de boa. 13:58 <@jrandom> (e a release 1.0 é um .exe que ninguém revisou, o resultado pode variar) 13:58 <legion> Eu nomeei e numerei mal, desculpem, novamente por isso. 13:58 <ant> <dm> 1.0>> 0.1.8 13:58 <ant> <dm> qualquer dia da semana 13:59 <@duck> levemente relacionado: 13:59 <@jrandom> ok, mais algo em 3) i2p-bt, ou vamos para 4) ??? 13:59 <+postman> legion: quando haverá código-fonte para download? 13:59 <frosk> "I2P-BT 0.1.8 funciona muito bem e estável até agora. Pessoalmente não vejo razão para atualizar para I2P-BT 1.0" (visto no fórum) 13:59 * jrandom suspira 13:59 <@duck> no mês passado o Bram Cohen fez uma palestra sobre bittorrent em alguma universidade 14:00 <@duck> bem interessante: http://netnews.nctu.edu.tw/~gslin/tmp/050216-ee380-100.wmv.torrent 14:00 <@duck> (lições aprendidas sobre grandes programas p2p, além de alguns detalhes do bittorrent explicados) 14:00 <@duck> . 14:01 <@jrandom> certo 14:01 <@duck> postman: o legion lançou algum código-fonte 14:01 <ant> <dm> ele é o inventor do BT? 14:01 <@duck> mas de acordo com o smeghead não é o mesmo que o .exe 14:01 <@jrandom> dm: sim 14:01 <legion> Há um código-fonte para desenvolvedores que você pode baixar em http://legion.i2p/archives/Itorrent_1_x_Developer_Source.zip.bz2 14:02 <+postman> ok, vou dar uma olhada 14:02 <ant> <dm> o exe é uma compilação direta desse fonte? 14:03 <legion> embora, na verdade, o fonte 1.0 seja basicamente a 0.1.8 com um patch do smeghead, compilado e bem empacotado. 14:04 * cervantes vai até 4)??? e espera todos alcançarem 14:04 <ant> <dm> a pergunta permanece sem resposta 14:04 <ant> <dm> Legion, você ordenou ou não um código vermelho??? 14:04 <@jrandom> *cof* 14:04 <legion> Talvez devêssemos voltar ao tópico, minha discussão do cliente bt foi para #itorrent 14:05 <@jrandom> ok, 4) ??? 14:05 <@jrandom> mais alguma coisa que as pessoas queiram levantar? 14:05 <@jrandom> aum: você tinha algo? 14:06 <ant> <dm> stasher está de volta? 14:06 <legion> estou apenas vendo um comportamento estranho com a 0.5.0.2 em períodos de tráfego pesado... 14:06 <aum> sim 14:06 <aum> eu gostaria de levantar a questão da criação/gestão automatizada de tunnel 14:07 <ant> <dm> continue 14:07 <+detonate> há uma null pointer exception na coisa da bandeja do sistema no Windows, acabei de perceber 14:07 <aum> é 1337 que o console web agora permita que humanos criem/deletem/gerenciem tunnels manualmente 14:07 <@jrandom> detonate: você poderia jogar isso no bugzilla? 14:07 <aum> mas também acredito fortemente que deveria sempre haver uma maneira confiável e conveniente para programas gerenciarem tunnels também 14:08 <@jrandom> aum: ninguém discorda. precisamos disso e teremos. só ainda não. 14:08 <ant> <dm> você não pode fazer isso via SAM? 14:08 <aum> notei no meu retorno recente ao i2p que a biblioteca pysam não está mais funcionando 14:08 <septu_ssh> eu tenho uma pergunta rápida também depois do aum 14:08 <aum> o que foi decepcionante 14:08 <@jrandom> o protocolo SAM funciona, o pysam não 14:08 <Ragnarok> isso funcionou alguma vez? 14:09 <aum> correto 14:09 <aum> pysam costumava funcionar brilhantemente 14:09 <legion> Durante esses períodos há 1000+ tunnels dos quais meu nó participa e vários segundos de lag e atraso. 14:09 <@jrandom> legion: sim, o número de tunnels é por causa de builds mais antigas 14:09 <cervantes> ah mymodesty 14:09 <cervantes> eerm pymodesty 14:09 <aum> no momento estou escrevendo um módulo 'i2ptunnel.py', que define classes permitindo gerenciar tunnel facilmente 14:10 <legion> então, se builds mais antigas não estivessem sendo conectadas, a rede estaria muito mais suave? 14:10 <@jrandom> 'k, não sei se essa é a solução certa de longo prazo, mas se isso cobre a lacuna pra você agora, legal 14:10 <@jrandom> legion: esses tunnels não são o problema 14:11 <aum> bem, as interfaces de classe podem permanecer mesmo que o mecanismo subjacente mude 14:11 <@jrandom> 'k 14:11 <legion> não são? 14:12 <legion> Quando há poucos tunnels, há muito pouco lag e atraso... 14:12 <cervantes> legion: desculpe, o aum está apenas levantando algumas questões, se você puder esperar um minuto 14:12 <legion> só me parece estranho. 14:13 <legion> ok 14:13 <@jrandom> só me preocupo que precisamos levar em consideração o que funcionou no passado — a configuração via web funciona e é mantida porque todo mundo usa. talvez seja melhor fazer o que quer que seja que você esteja desenvolvendo funcionar com criação manual de tunnel *primeiro*, isso seria mais eficiente? 14:13 <@jrandom> só para que sempre haja algo usando i2ptunnel.py, para estressar 14:13 <aum> parece que estamos entrando em deadlock 14:13 <+detonate> jrandom:claro 14:14 <ant> <dm> então vamos em frente 14:14 <aum> não quero investir tempo desenvolvendo meu app até ter uma API de gerenciamento de tunnel em que eu possa confiar 14:14 <septu_ssh> \o. - ponto a levantar 14:14 <cervantes> realisticamente não consigo imaginar que a interface de tunnel será reformulada nos próximos meses... 14:14 <@jrandom> mas certamente você vê que podemos adicionar uma de forma trivial 14:14 <cervantes> então uma solução paliativa é viável 14:15 <named_> A configuração web não poderia ter algum tipo de API que o programa do aum manipulasse? 14:15 <@jrandom> named_: sim 14:16 <@jrandom> é trivial adicionar algo para permitir controle seguro via URLs, mas só faz sentido se houver algo que precise disso 14:16 <@jrandom> caso contrário, só vai apodrecer 14:16 <aum> named_: seria bom, e poderia funcionar se houvesse uma senha hardcoded na config que programas clientes precisassem fazer POST junto com os campos de controle de tunnel 14:16 <cervantes> pessoalmente eu gostaria de ver todo o sistema de tunnel completamente reformulado; se você incluir uma interface de gerenciamento de tunnel desde o início, então não terá que se preocupar com o esforço extra necessário para manter uma interface separada 14:17 <@jrandom> sim, os proxies realmente precisam de bastante trabalho, do qual eu tenho me escondido o máximo possível :) 14:17 <aum> SAM é bom para algumas situações, ruim para outras 14:17 <cervantes> mas isso é mais pra frente... 14:17 <fedo> ( 14:18 <@jrandom> aum: mas como paliativo, você não poderia usar um dos três métodos disponíveis? 14:18 <cervantes> ou seja, se a própria interface web usar a API, então não há sobrecarga de manutenção 14:18 <@jrandom> certo. a interface web usa o TunnelControllerGroup 14:19 <aum> o uso do SAM fica difícil quando se quer usar libs existentes que são extensivamente dependentes de sockets TCP padrão 14:19 <aum> jrandom: o I2PTunnel CLI não funciona para abrir server tunnels, então no momento estou escrevendo código para usar o TunnelControllerGroup 14:19 <@jrandom> aum: libs existentes precisam ser cuidadosamente auditadas. por exemplo, a própria ferramenta gzip expõe dados sensíveis 14:19 <aum> codificando enquanto falamos 14:21 <@jrandom> tenho certeza de que o CLI funciona para server tunnels, mas usar o TunnelControllerGroup é preferível, se você precisar assim 14:21 <@jrandom> ok, mais alguém tem algo para levantar? 14:22 <septu_ssh> Minha pergunta diz respeito a uma versão distribuída do hosts.txt; uma tabela DHT é usada atualmente para routerInfo, isso não poderia ser estendido para uma versão distribuída do DNS? A DHT do DNS poderia conter mapeamentos de www.bla.i2p para o SHA do eepsite, e as entradas seriam assinadas por um 'I2P registrar'... comentários? refutações? 14:22 <mancom> uma pergunta sobre o roadmap: a 0.6 ainda está programada para abril? 14:22 <@jrandom> septu_ssh: dados que não são de roteamento vão para o netDb só por cima do meu cadáver ;) 14:23 <septu_ssh> jrandom: não o mesmo db 14:23 <septu_ssh> um db distribuído diferente 14:23 <aum> jrandom: você viu meu relatório de bug? o comando do CLI 'server' /não funciona/ 14:23 <maestro^> septu_ssh: não existe nenhum i2p registrar 14:23 <@jrandom> septu_ssh: há muitos aspectos perigosos na nomenclatura, com alguns trade-offs importantes. você viu a discussão sobre nomenclatura no ugha.i2p? 14:24 <@jrandom> septu_ssh: ah, uma DHT sobre o I2P certamente poderia ser usada para distribuir entradas, embora esses nomes não seriam seguros, se fossem tratados como entradas globais 14:26 <@jrandom> aum: eu usei isso diariamente até algumas semanas atrás, você viu minha resposta? 14:26 <@jrandom> maestro^: esse é o plano 14:26 <@jrandom> er, mancom: 14:26 <cervantes> aum: eu tenho uma resposta daquele e-mail na i2plist do jr, ainda não chegou para você, ou o problema permanece? 14:26 <septu_ssh> a única razão pela qual sugiro um 'registrar' é porque colisões podem acontecer do contrário 14:26 <@jrandom> septu_ssh: abrace as colisões :) 14:26 <@jrandom> nomenclatura única globalmente, legível por humanos, distribuída e segura não existe 14:27 <septu_ssh> isso também pode acontecer no host.txt se ele for editado manualmente, mas o problema permanece o mesmo 14:27 <@jrandom> abandone o primeiro parâmetro e você está feito 14:27 <aum> jrandom: eu vi sua resposta — e eu /tenho/ o streaming.jar no meu cp 14:27 <septu_ssh> o postman gerencia um nó central para e-mail, então há algum elemento de confiança dentro da rede; certamente alguém confiaria em um registrar para gerenciar o namespace? 14:27 <@jrandom> ok, legal, e ainda retorna aquele stack trace, aum? 14:28 <aum> sim 14:28 <@jrandom> septu_ssh: o postman só atua como um elemento central para os outproxies e inproxies do postman 14:28 * Ragnarok realmente precisa arranjar tempo para escrever aquela documentação do catálogo de endereços... 14:28 <aum> isso é quando eu executo manualmente o CLI, faço um genkeys, depois faço um 'server' usando o privkeyfile gerado pelo genkeys 14:28 <@jrandom> septu_ssh: ninguém vai confiar em ninguém para gerenciar um namespace. censura == exercer pressão sobre esse registrar. 14:28 <maestro^> na verdade, cada um é seu próprio registrar 14:29 <maestro^> você confia nos seus amigos e eles confiam em você 14:29 <aum> ah droga, peguei um classpath antigo 14:29 * aum testa novamente 14:30 <ant> <dm> ok, eu serei o registrar. 14:31 <ant> <dm> serei o mais imparcial possível... fechado? 14:31 <septu_ssh> hmmm, ok, de volta à prancheta então... 14:31 <@jrandom> septu_ssh: um bom lugar para revisar é http://zooko.com/distnames.html :) 14:32 <@jrandom> todo mundo quer isso, mas o que querem simplesmente não é seguro. nós temos uma solução que é, mas abrimos mão da unicidade global 14:33 <septu_ssh> hmmm, ok 14:33 <@jrandom> ok, mais alguém tem algo a acrescentar para a reunião? 14:33 <cervantes> septu_ssh: http://forum.i2p.net/viewtopic.php?t=134 14:33 <aum> jrandom - ok, o CLI 'server' agora funciona, mas eu nunca recebi um 'job number' para o tunnel 14:34 <@jrandom> hmm, certo, ele roda para sempre 14:34 <aum> ah, tenho que fazer 'list' para obter o número da tarefa 14:36 <@jrandom> ok, legal, se não há mais nada... 14:36 * jrandom se prepara 14:36 * jrandom *baf* encerra a reunião