Reunião de Desenvolvedores do I2P - 07 de setembro de 2004

14:09 <jrandom> 0) oi 14:09 <jrandom> 1) 0.4 14:09 <jrandom> 2) Capacidade e sobrecarga 14:09 * cervantes puxa um banquinho de bar 14:09 <jrandom> 3) Atualizações do site 14:09 <jrandom> 4) Interface web do I2PTunnel 14:09 <jrandom> 5) Roadmap e tarefas 14:09 <jrandom> 6) ??? 14:09 <jrandom> 0) oi 14:09 <nicktastic> ugha, Ah, -x nem é necessário para ver o que está sendo resolvido - bobeira minha 14:09 <cervantes> olá 14:09 * nicktastic volta a ficar só observando 14:10 <jrandom> olá a todos, desculpem o atraso nas notas - http://dev.i2p.net/pipermail/i2p/2004-September/000437.html 14:10 * jrandom só tive que responder ao post E do Derick :) 14:10 <deer> <ugha2p> nicktastic: Certo. Mas a reunião já começou. :) 14:10 <luckypunk> h uau, não perdi. 14:10 <jrandom> !hi5 14:10 <jrandom> ok, vamos passar para 1) 0.4 14:11 <jrandom> finalmente lançamos, e não parece ter nos mordido muito 14:12 <jrandom> a rede está maior do que nunca (contei 60 conexões TCP algumas horas atrás), eepsites estão acessíveis, e o irc é frequentemente utilizável 14:12 <dm> ei!! reunião? 14:12 <jrandom> hypercubus fez um ótimo trabalho com a nova instalação, systray e o service manager, o que eu sei que ajudou bastante 14:13 <modulus> yay 14:13 <hypercubus> ainda há um caminho pela frente 14:13 <hypercubus> mas acho que estamos chegando a algum lugar agora 14:13 <jrandom> concordo, sempre em frente :) 14:14 <jrandom> esta versão também tem a implantação ampla do ?i2paddresshelper do oOo 14:14 <jrandom> falamos disso um pouco na outra semana [http://dev.i2p.net/pipermail/i2p/2004-August/000419.html item 2.3], mas agora provavelmente é uma boa ideia o pessoal considerar usar isso nos seus links 14:15 <hypercubus> funciona com vhosts baseados em nome? 14:15 <jrandom> o i2ptunnel httpclient ainda envia corretamente Host: $base64dest 14:17 <jrandom> nesse sentido, tem havido mais conversa sobre usar o servidor web embutido para servir alguns eepsites, e acho que se alguém tiver um tempo para descobrir a configuração necessária, seria muito foda (nos salvando dos problemas de configuração de vhost / apache) 14:18 <jrandom> ok, mais alguém tem algo para levantar sobre a 0.4? 14:18 <deer> <baffled> este servidor web está no cvs? 14:18 <demonic_1> ? 14:18 <hypercubus> o servidor web está na 0.4 14:18 <demonic_1> o que eu perdi 14:18 <deer> <ugha2p> baffled: Vai estar. 14:18 <hypercubus> portanto, CVS 14:18 <jrandom> baffled: sim, está tudo no cvs (lib/org.mortbay.*) 14:18 <cervantes> btw eu experimentei os URL protocol handlers do Windows... é muito fácil configurar o registro para que "i2p://base64" abra no navegador com um http://site.i2p?i2paddresshelper=base64 ... 14:19 <deer> <ugha2p> Ah, já está. 14:19 <dm> isso é tudo muito, muito legal 14:19 <hypercubus> eu já escrevi código para interfacear com o registro 14:19 <hypercubus> podemos usar isso para configurar uma associação .i2p 14:19 <fvw> cervantes: i2p:// não seria exatamente certo, acho. Afinal, é http sobre i2p; assim como você poderia ter irc:// sobre i2p. 14:19 <cervantes> você também pode especificar configurações de segurança e proxy por protocolo 14:19 <jrandom> cervantes: o firefox/etc respeitam isso? 14:19 <cervantes> sim 14:20 -!- shardy_ agora é conhecido como shardy 14:20 <jrandom> uau, oi shardy_ 14:20 <shardy> oi jrandom, há quanto tempo 14:20 <cervantes> embora, admito, eu precise de mais testes... 14:20 <nicktastic> o konqueror também deve 14:20 <cervantes> eu só estava brincando num momento livre ;-) 14:20 <deer> <ugha2p> O Opera não. 14:20 <cervantes> embora eu duvide que o firefox dê atenção às configurações de proxy e segurança do Windows 14:20 <hypercubus> você pode definir isso no arquivo ini do Opera 14:21 <hypercubus> eu fiz isso no opera para o ed2k:// funcionar 14:21 <deer> <ugha2p> hypercubus: Ah, legal. 14:21 <fvw> só até certo ponto. Você não consegue transformar manipuladores de URL em http:// manipulados pelo próprio opera, infelizmente. 14:21 <hypercubus> embora eles não documentem isso muito bem 14:21 <deer> <duck> sério, que benefício i2p:// traz? 14:22 <fvw> hypercube: Você está repassando para um app auxiliar, suponho? Eu fiz algo parecido, mas não consegui um jeito de fazer o opera exibir uma página "download iniciado". 14:22 <hypercubus> sim, é repassado para o eMule 14:22 <dm> sim, quem quer fazer xixi em público mesmo? 14:22 <hypercubus> poderíamos repassar i2p:// para o eeproxy (proxy HTTP do I2P) 14:22 <hypercubus> daí vocês, pessoal da web, dão um jeito no resto ;-) 14:22 <Sciatica> https não é http sobre, uh, "s"? 14:23 <jrandom> mas, como acho que o duck está sugerindo, já estaremos amarrados ao eepproxy de qualquer maneira? 14:23 <deer> <ugha2p> Sciatica: É HTTP sobre SSL, sim. :) 14:23 <jrandom> Sciatica: http sobre i2p (bem, qualquer coisa sobre i2p) é seguro e autenticado. o que acontece depois que chega do outro lado está fora do escopo do i2p 14:23 <deer> <ugha2p> Mas isso é uma convenção estabelecida. 14:24 <Sciatica> sim, eu sabia. Só estou dizendo que o argumento contra i2p:// não é tão claro quanto "não é só http _sobre_ i2p?" 14:24 <dm> htt2p 14:24 <hypercubus> não sei se i2p:// é necessário, mas acredito que seja possível fazer os principais navegadores pelo menos trabalharem com isso 14:24 <deer> <ugha2p> jrandom: Acho que ele só se referiu ao prefixo 'https://'. 14:24 <jrandom> ah, foi mal. 14:24 <deer> <duck> precisamos de um filtro de anonimização mais http://127.0.0.1:7657/www.duck.i2p/ de qualquer forma 14:25 <deer> <duck> com esses você não precisa mexer nas configurações do navegador 14:25 <jrandom> mas sim, concordo com o fvw, isso parece uma sobrecarga excessiva do protocolo de URL 14:25 <demonic_1> não aqui>> como um uso bobo eu acho que links i2p:// seriam demais <<não aqui 14:25 <jrandom> isso mesmo, duck 14:25 <jrandom> hehe 14:25 <cervantes> talvez i2p:// pudesse operar como um árbitro de protocolo: i2p://irc/base64 14:26 <fvw> ungh, isso é feio e abusa das URLs da pior maneira possível. 14:26 <deer> <ugha2p> cervantes: Como isso funcionaria no caso do IRC? 14:26 <deer> <duck> URIs :) 14:26 <cervantes> assim você pode abrir apps diferentes com base num único padrão de url 14:26 <fvw> (não que haja algo de errado com isso) 14:26 <jrandom> a modificação de URL mais apropriada não seria irc://i2p/base64/#i2p ? 14:27 <jrandom> mas, ok, estamos saindo um pouco do tema.. 14:27 <jrandom> mais algo sobre a 0.4? :) 14:28 <fvw> Não acho que URIs permitam especificar o mecanismo de transporte separadamente do protocolo, o que é uma pena mesmo. 14:28 <dm> você pode usar o sistema de arquivos 14:28 <fvw> Sim, de certo modo: *aplausos* 14:28 <dm> c:\i2p\irc #i2p 14:29 <dm> ha! Confundi todos vocês 14:29 <deer> * mule_iip concorda com fvw 14:29 <fvw> dm: Vou te machucar seriamente. Talvez não hoje, talvez não amanhã, mas em breve e pelo resto da sua vida. 14:29 <jrandom> :) valeu, fazemos o melhor 14:29 <fvw> </pinky and the brain> 14:29 <jrandom> heh 14:29 <jrandom> ok, pulando para 2) Capacidade e sobrecarga 14:30 <deer> <DrVince> Oi pessoal 14:30 <jrandom> prefiro não apenas copiar o que foi postado nas notas, então revejam o que está lá :) 14:30 <dm> oi 14:30 <hypercubus> bem-vindo à nossa reunião, DrVince ;-) 14:30 <deer> <ugha2p> Oi, DrVince. 14:31 <jrandom> uma coisa que eu gostaria de mencionar em relação a 2) foi algo que algumas pessoas viram - desbalanceamento severo nos tunnels participantes 14:31 <jrandom> por exemplo, alguém com DSL tinha 300+ tunnels outro dia 14:31 <dm> eu 14:31 <modulus> sim 14:31 <jrandom> (e quando caem, isso quebra um monte de tunnels) 14:31 <jrandom> o problema é que tunnels são muito leves - 2-20bps em média 14:31 <cervantes> e meu OC3 tem praticamente nada 14:31 <hypercubus> eu só tenho 8 no momento 14:32 <dm> eu tinha 270+, e estou em 150kbps 14:32 <jrandom> no geral, a rede tem ~ 20*n tunnels em média a qualquer momento 14:32 <jrandom> (onde n = # de nós na rede) 14:32 <jrandom> com uma média de 2 saltos por nó, isso significa que cada nó participa em uma média de 40 tunnels 14:33 <hypercubus> idealmente ;-) 14:33 <jrandom> bem, essa é a questão, equilibrar assim não é ideal 14:33 <jrandom> já que nem todos os nós são tão rápidos ou têm tanta largura de banda 14:33 <jrandom> por outro lado, equilibrar os tunnels para que todos passem por 2 ou 3 peers muito rápidos também é péssimo 14:33 <jrandom> porque se um desses cai, boom 14:34 <hypercubus> certo, então por que a conexão DSL inferior do dm está tão sobrecarregada, enquanto a minha DSL muito mais rápida está subutilizada? 14:34 <Sciatica> esse problema vai sumir à medida que o # de nós na rede crescer além de 100, 200, etc.? 14:34 <dm> inferior? :'( 14:34 <jrandom> hypercubus: porque o i2p atualmente não reage à largura de banda disponível, a menos que as pessoas ativem a limitação de largura de banda 14:34 <hypercubus> dm: tecnicamente falando ;-) 14:34 <hypercubus> ok, eu tenho a limitação de largura de banda ativada... dm não deve ter? 14:35 <Sciatica> (em algum ponto o número de nós que um servidor pode hospedar não será muito pequeno comparado ao número total de nós [ex., tunnels]? 14:35 <ugha_node> Arrr! 14:35 <ugha_node> '(the local message processing time exceeds 1s)' -- Não acho que devamos programar constantes assim no router. Acho que todos esses valores deveriam ser obtidos do ambiente (da rede I2P), assim ainda funcionaria caso o router caia num ambiente inesperado. 14:35 <dm> sim, eu não tenho, também meu uplink é decente: 256kbps (downlink 150kbps) 14:35 <Sciatica> terminologia ruim -- eu digito muito devagar para essas questões :-) 14:35 <jrandom> Sciatica: não é um problema, é apenas uma realidade. se cada nó mantém 20 tunnels a qualquer momento, com cada tunnel em média com 2 saltos, não importa quão grande a rede seja, isso se equilibra 14:36 <jrandom> ugha_node: concordo - o negócio de 1s é número aleatório, mas como podemos derivar o valor "certo"? qual quantidade de atraso é "muita"? 14:37 <jrandom> temos algum código no RouterThrottleImpl que acompanha "quanta largura de banda concordamos em alocar" 14:37 <jrandom> mas no momento, ele não limita com base nisso 14:37 <dm> hmmmm eu não gosto dessas discussões de sobrecarga... lembranças do freenet. 14:37 <jrandom> (largura de banda acordada == # de tunnels participantes * # de mensagens por tunnel em média * # de bytes por mensagem em média) 14:37 <dm> Talvez devêssemos usar estimadores? 14:38 * jrandom dá um chute no dm 14:38 <hypercubus> dm: você está usando a limitação de largura de banda no seu router? 14:38 <dm> hypercubus: não 14:38 <hypercubus> dm: eu recomendo fortemente usar ;-) 14:38 <dm> jrandom: três palavras... NGR 14:38 <fvw> Depende mesmo do nó que pediu o tunnel, certo? Quanto de lag ele está disposto a aguentar? Seria viável tornar isso um dos parâmetros do tunnel? 14:39 * fvw se pergunta se dm está tentando nos assustar ou se é apenas um benefício extra. 14:39 <jrandom> hmm, isso tem potencial 14:39 <dm> errr.. isso não vai só mover o limite arbitrário para o router que solicita? ;) 14:39 <dm> eu não quero escolher, você escolhe! 14:40 <jrandom> sim dm, mas o router solicitante sabe para quê o tunnel vai ser usado (irc com pouco lag vs bulk com alto lag e alta vazão) 14:40 <fvw> sim, mas para algumas coisas 10s de lag não é problema (pense em transferências de arquivos), enquanto outras (irc) precisam de baixa latência. 14:40 <dm> sim, então você tem a camada de app decidindo o limite? 14:40 <jrandom> isso, porém, é perigoso 14:40 <fvw> o único problema é que usar links de alta latência não aumenta a capacidade, então no fim as transferências de arquivo ficam com todos os recursos. 14:41 <cat-a-puss> dá para confiar mesmo em quaisquer alegações de carga feitas pelo router? caso contrário, uma pessoa maliciosa poderia tentar fazer o tráfego de outro nó passar por todos os routers dela 14:41 <jrandom> cat-a-puss: isso é usado apenas para rejeitar pedidos para participar, não para solicitar 14:41 <ugha_node> Você não pode. 14:41 <cat-a-puss> ok 14:42 <jrandom> um usuário malicioso pode, claro, aceitar tunnels quando está totalmente sobrecarregado, mas vamos detectar isso quando o tunnel falhar 14:42 <jrandom> (e o aproveitador pode rejeitar o tunnel quando não está carregado, mas, c'est la vie) 14:43 <jrandom> a limitação com base na sobrecarga local é bem eficaz. no entanto, isso não é suficiente 14:43 <dm> bastardo ganancioso 14:43 <jrandom> tenho tentado achar uma forma ideal de decidir aceitar ou não, e acho que há potencial para rejeitar probabilisticamente pedidos que de outra forma aceitaríamos, com base em quantos tunnels já estamos 14:44 <jrandom> a ideia é que o peer quer que outras pessoas assumam alguma carga 14:44 <cat-a-puss> devemos rodar tantos routers virtuais quanto a largura de banda disponível? 14:44 <jrandom> (para distribuir a falha) 14:44 <jrandom> hmm cat-a-puss? 14:44 <jrandom> você está rodando a simulação na rede real? 14:45 <jrandom> de qualquer forma, não, um único router deveria conseguir atender a capacidade local 14:46 <deer> <mule_iip> o problema é que a largura de banda usada num tunnel pode mudar significativamente ao longo do tempo, certo? 14:46 <cervantes> o que não está acontecendo atualmente... pelo menos não para mim 14:46 <cat-a-puss> bem, se é tudo aleatório como você aproveita um oc3 mais do que um coitado num 56k? Ou você tem que anunciar: problemático, ou rodar routers virtuais, de qualquer forma acho que uma parte maliciosa poderia tentar cercar um nó para algum tipo de ataque estatístico 14:46 <jrandom> certo, mule_i2p. precisamos monitorar mais a atividade dos tunnels 14:46 <cervantes> 14 participantes cada um com 11,5mbit ... isso é um pouco de desperdício :) 14:47 <jrandom> cat-a-puss: probabilístico != aleatório :) 14:47 <jrandom> heh cervantes 14:48 <jrandom> a ideia básica por trás da rejeição probabilística seria espalhar a carga para outros peers. no entanto, se a rede realmente estiver saturada, a probabilidade não será um problema pois as pessoas vão apenas pedir de novo 14:48 <jrandom> a questão é que atualmente temos um enorme excesso de capacidade 14:48 <Sugadude> Pobre i2p, com capacidade demais. Não se preocupem, vou dar um jeito. ;) 14:49 <fvw> assumindo que todos se comportam bem, talvez você pudesse não rejeitar de pessoas que voltam dentro de um curto intervalo após serem rejeitadas probabilisticamente? 14:49 <deer> <mule_iip> então preencha qualquer tunnel com algum tráfego de cobertura 14:49 <jrandom> heh Sugadude :) 14:49 <cervantes> isso é porque os pedidos de todo mundo estão sendo tratados pelo router do dm ;-) 14:49 <jrandom> fvw: não sabemos quem pede um tunnel 14:49 <fvw> hmm, bom ponto. *rosca a cabeça de volta* 14:50 <jrandom> fvw: probabilisticamente, pedidos subsequentes seriam aceitos - queremos que o fator de 'rejeição' permaneça baixo o suficiente 14:50 <deer> <mule_iip> o que aumentará o anonimato e tornará o cálculo de carga mais fácil 14:51 <jrandom> verdade, mule_iip, mas seria bom a rede operar efetivamente sem exigir alta carga :) 14:51 <jrandom> mas isso é definitivamente um cenário válido para a simulação 14:51 <deer> <mule_iip> efetivamente fazer o i2p usar uma taxa de bits constante com tráfego de cobertura. mas isso seria para uma versão futura, imagino :) 14:52 <jrandom> poderíamos usar alocação estilo ATM 14:52 <fvw> O uso de banda não varia demais para isso ser viável? 14:52 <jrandom> por exemplo, assumir 5 mensagens por minuto por tunnel @ 32KB cada, e comparar isso com os limites de banda, e rejeitar de acordo 14:52 <cervantes> o hyper tem um pouco de ASCII que podemos usar para preencher as mensagens 14:52 <hypercubus> hmmmm, não gosto dessa ideia de taxa de bits constante... i2p seria filtrado pelos ISPs muito rapidamente se isso fosse implementado 14:53 <jrandom> heh cervantes 14:53 <deer> <kaji> sim 14:53 * hypercubus não sabe do que o cervantes está falando 14:53 * hypercubus esconde seu disquete 14:53 <jrandom> fvw: padding? ou alocação? 14:53 <fvw> alocação 14:53 <cervantes> ah sim, negabilidade plausível né 14:54 <jrandom> hmm fvw. talvez, mas acho que podemos monitorar estatisticamente e compensar 14:54 <deer> <kaji> taxa de bits constante soa como Waste 14:54 <jrandom> por exemplo, http://localhost:7657/oldstats.jsp#tunnel.bytesAllocatedAtAccept 14:54 <hypercubus> daí o nome ;-) 14:55 <jrandom> essa estatística monitora quanta largura de banda concordamos em repassar para os tunnels de outras pessoas 14:55 <jrandom> (usando os últimos 10 minutos como guia) 14:56 <jrandom> então meu peer com 85 tunnels diz que vai transferir 3,676,945.65 bytes nos próximos 10 minutos para todos esses tunnels, combinados 14:56 <deer> <mule_iip> kaji: é waste, e provavelmente deveríamos usar apenas para modelos de ameaça mais severos. mas seria bom para baixa latência como irc. 14:56 <jrandom> isso dá 72bps cada, mas não tenho certeza do quão enviesado isso está (provavelmente muito) 14:57 <jrandom> no entanto, se todos esses tunnels começassem a usar muita, muita largura de banda, o valor total dispararia, e poderíamos limitar 14:57 * fvw concorda com a cabeça. 14:57 * fvw observa que isso é de fato um problema selvagemente interessante, teoricamente falando. 14:57 <fvw> (mas talvez seja só eu sendo esquisito) 14:57 <jrandom> concordo 14:58 <jrandom> (com ambos ;) 14:58 <jrandom> mas é, ainda não temos a Resposta Certa. mas é algo a ser trabalhado 14:59 <jrandom> ok, a menos que haja mais algo nisso, passando para 3) Atualizações do site 14:59 <fvw> Poderíamos, claro, ir totalmente com perdas e simplesmente descartar datagramas quando estivermos sobrecarregados, e fazer as pessoas rodarem algo como tcp em cima disso. 14:59 <jrandom> tentamos isso, e muitos e muitos e muitos tunnels falharam 15:00 <jrandom> (já que se um tunnel deixa cair 1 mensagem, marcamos como falho) 15:00 <fvw> sim, você não deveria fazer isso se seguir essa abordagem. 15:00 <jrandom> ((e quando tentamos não ser tão fascistas, não percebemos quando um tunnel realmente falha)) 15:00 * fvw concorda e acaricia a barba. Bom ponto. (nota mental: deixar a barba crescer para acariciar em situações como esta) 15:01 <jrandom> heh 15:01 <jrandom> ok, de qualquer forma, como todos viram, nosso novo instalador e a nova interface web são completamente diferentes do jeito antigo de fazer as coisas 15:01 * hypercubus dá sua barba ao fvw 15:02 <jrandom> embora isso seja Bom, já que o jeito antigo era Doloroso, toda a nossa documentação antiga agora está completamente incorreta 15:02 <fvw> podemos ficar no 2) mais alguns minutos? Ainda tenho algumas ideias ruins que quero que vocês detonem. 15:02 <jrandom> claro 15:02 <dm> não consigo usar a internet... 15:02 <dm> Largura de banda entrando/saindo 15:02 <dm> 1m: 13.32/11.98KBps 15:02 <dm> 5m: 10.74/9.46KBps 15:02 <jrandom> quantos tunnels dm? 15:02 <hypercubus> dm: é por isso que sugeri que você ativasse a limitação de largura de banda do i2p ;-) 15:02 <dm> só 166 15:02 <jrandom> sim, limita para 6KBps 15:02 <jrandom> lol 15:03 <dm> (participating) 15:03 <jrandom> (ou talvez 8KBps se for legal) 15:03 <dm> vou deixar como está, só preciso ver esta página 15:03 <jrandom> a propósito, os 13.32 vs 11.98 nos informam que você está baixando aproximadamente 1KBps localmente 15:03 <jrandom> (pelo i2p) 15:03 <fvw> O que acontece se simplesmente dermos timeout nos tunnels em um tempo de inatividade razoavelmente grande? Digamos 30 min ou algo assim. O próximo protocolo acima teria que fazer keepalives, mas isso não resolveria o problema de não detectar tunnels mortos? 15:03 <hypercubus> ele está baixando bem mais do que isso na verdade 15:04 <jrandom> ((embora esse 1KBps possa ser pequeno o suficiente para ser netDb)) 15:04 <dm> hypercubus: nossa transferência está travando feio, na verdade. 15:04 <jrandom> fvw: tunnels expiram após 10 minutos 15:04 <deer> <kaji> pera, a largura de banda funciona agora? se sim para quanto devo ajustar? 15:04 <dm> decepcionado com a combinação getright/i2p 15:04 <jrandom> eles não são de vida longa fvw, ao contrário do TOR 15:04 <fvw> e isso fez a maioria dos tunnels falharem, mesmo com keepalives? 15:04 <hypercubus> dm: periodicamente sim... acho que a solução seria limitar seu upstream para cerca de 8KB/s 15:04 <jrandom> kaji: http://localhost:7657/ 15:05 <hypercubus> já que parece que você está saturado 15:05 <jrandom> er, /config.jsp 15:05 <fvw> ok, mas você não quer que eles desapareçam em rajadas de perda de pacotes. 15:05 <jrandom> a cada minuto (em média) cada par testa cada tunnel para garantir que está vivo (para que outras pessoas possam nos enviar dados - sem tunnels, estamos ferrados) 15:06 <fvw> Ok. Eu preciso ler mais sobre como o i2p funciona atualmente. Vamos para o 3) por mim. 15:06 <deer> <kaji> agora está no padrão -1 mas não sei no que uma conexão 1.5/750@1.2ghz se traduz em participação máxima em tunnel 15:07 <deer> <kaji> parece que estou participando em 166 15:07 <jrandom> kaji: seu router nunca vai pegar tantos tunnels a ponto de ficar congestionado de CPU ;) 15:07 <deer> <mule_iip> off-topic: você não precisa de um tunnel para ser fodido :) 15:07 <deer> <kaji> *ing 15:07 <jrandom> heh 15:07 * fvw vota "não" 15:08 <deer> <kaji> jrandom, acabei de terminar de ler a carta sobre tunnels sem largura de banda, só não sabia para quanto definir o limite 15:08 <jrandom> ok, concordo, há muito mais a fazer para descobrir essas coisas 15:08 <jrandom> ok legal kaji, só ative seu limitador de largura de banda para algo como 8KBps 15:08 <jrandom> (ou 12 se for legal :) 15:09 <deer> <kaji> </oftopic> 15:09 <jrandom> ok, para 3) atualizações do site 15:09 <deer> <kaji> entrada e saída? 15:09 <jrandom> sim kaji 15:09 <jrandom> ok, como eu disse, precisamos de ajuda com a documentação 15:09 <jrandom> (ajuuuuuuuda!) 15:09 <hypercubus> proponho preencher as posições, há muito vagas, de Webmaster e Editor Web 15:10 * jrandom apoia essa moção 15:10 <jrandom> (agora só falta alguém se voluntariar ;) 15:10 <hypercubus> eu sei que o cervantes é um cara ocupado 15:10 <jrandom> está mais para o indivíduo se voluntariar /si mesmo(a)/, hyper ;) 15:10 <hypercubus> eu indico a Curiosity para Webmaster ou Editora Web, ou ambos se ela topar ;-) 15:11 <deer> <ugha2p> Uhh. 15:11 <dm> Cara, até meu CPU está começando a ficar no máximo por causa do I2P... 15:11 <dm> Vocês me amam, vocês REALMENTE me amam :'( 15:11 <dm> ops, :') 15:12 * cervantes sente alguém o empurrando para a arena de touros 15:12 <jrandom> acho que podemos usar toda a ajuda possível, e se ela topar ajudar, adoraríamos 15:13 <hypercubus> eu vi os designs web dela e posso atestar o trabalho dela 15:13 <hypercubus> e ela demonstrou interesse, não sei o que decidiu no fim porém 15:13 <jrandom> ok, ótimo 15:13 <dm> ela? 15:13 <cervantes> Tenho certeza de que ela pode dedicar muito mais cuidado e atenção do que eu jamais conseguiria 15:14 <dm> essa palavra não deve ser usada no nosso mundo 15:14 <fvw> esquece isso, ele disse 'cuidado e atenção'. 15:15 * jrandom geme 15:15 <fvw> presentes excluídos, claro. 15:15 <jrandom> ok, de qualquer forma, vamos precisar de algumas pessoas para ajudar na documentação - gerando novos tutoriais passo a passo, docs introdutórias, etc 15:16 <jrandom> vamos conversar com a Curiosity sobre no que podemos botá-la para hackear :) 15:16 <hypercubus> eu posso assumir as coisas relacionadas à instalação 15:16 <hypercubus> s/on/of/ 15:16 <hypercubus> eu sei como todo mundo adora ler esses tutoriais barrocos que eu escrevo ;-) 15:16 <jrandom> :) 15:17 <jrandom> um guia de instalação / walkthrough ia ser demais 15:17 <fvw> não é assim que se escreve 'broke'. 15:17 <jrandom> heh 15:17 * hypercubus dá uma risadinha, depois rouba a carteira do fvw 15:17 <hypercubus> é assim que se escreve "broke" ;-) 15:17 <deer> <kaji> hyper, em que sistema você está? eu posso tentar a versão winxp mas não sou muito confiável, posso ver algo brilhante e desistir 15:17 <deer> * Curiosity está ausente por um tempo... 15:18 <hypercubus> kaji: ? 15:18 <deer> <kaji> hyper, eu estava perguntando qual SO você está usando 15:18 <hypercubus> SOs 15:18 <deer> <kaji> SOSS 15:19 <hypercubus> eu tenho vmware, então posso rodar todos os windows e freebsd e tal 15:19 <hypercubus> também tenho pearpc, então posso rodar OS X 15:20 <jrandom> ok, se não houver mais nada no lado web 15:20 <jrandom> passando para * 4) Interface web do I2PTunnel 15:21 * jrandom declara a interface web do i2ptunnel uma merda. funcional. mas uma merda. 15:21 <deer> <DrVince> Eu poderia me dedicar à tradução para francês se houver interesse 15:21 <jrandom> o duck teve algumas ideias para melhorar isso, mas ele teve que sair, então vou colar algumas linhas 15:21 <hypercubus> de novo, precisamos de mais devs web ;-) 15:21 <jrandom> ah, traduzir páginas web para francês seria demais 15:22 <jrandom> s/french/french and other langs/ 15:22 <jrandom> aqui vão alguns duck-ismos: 15:22 <jrandom> <duck> reduzir carga de dados na página geral; usar tables/div para ordenar as coisas 15:22 <jrandom> <duck> fornecer uma página de edição/detalhes com info que a maioria não liga, tunnels, dest hash, chave completa 15:22 <jrandom> <duck> feedback após clicar botões, 'item salvo' etc. dar o dest como saída quando um novo for criado 15:22 <jrandom> <duck> (esconder sob editar/detalhes caso contrário) 15:22 <jrandom> <duck> marcar as mensagens do topo como sendo 'log'; às vezes confunde 15:22 <jrandom> <duck> deixar claro que 'confirmar' só é necessário para remover, não para salvar 15:22 * jrandom concorda com o que ele diz 15:23 <jrandom> também houve uma porção de correções de bugs nos bastidores na interface web do /i2ptunnel/ desde a 0.4, então os percalços funcionais devem estar resolvidos 15:24 <jrandom> o código que implementa essas páginas está bem feio, porém 15:24 <jrandom> provavelmente a melhor abordagem seria escrever as telas em html / css / imagens / etc simples, depois passar para um dos devs Java integrar 15:25 <hypercubus> o que aconteceu com os tempos em que havia um excesso de devs web? ;-) 15:25 <jrandom> estão todos trabalhando no mcdonalds 15:25 <hypercubus> ah é 15:25 <deer> * Curiosity voltou :) 15:25 <jrandom> de qualquer forma, se alguém estiver interessado em ajudar, ou tiver mais sugestões, por favor entre em contato 15:25 <jrandom> bem-vinda de volta Curiosity 15:26 <deer> <Curiosity> devo levantar a ideia que te falei, jrandom? 15:26 <cat-a-puss> Eu conheço alguém que talvez possa ajudar com a parte web 15:26 <jrandom> ah, o live cd? 15:27 <jrandom> ótimo, cat-a-puss, precisamos de toda ajuda possível 15:27 <deer> <Curiosity> teah :) 15:27 <deer> <Curiosity> err sim 15:27 <jrandom> Curiosity: sim, por favor traga isso quando chegarmos ao item 6) ??? 15:28 <deer> <Curiosity> ok :) 15:28 <cat-a-puss> ok, vou colocá-los na lista, e passar o e-mail do jrandom (curiosity não sei seu email) 15:28 <jrandom> ok, alguém tem mais algo a mencionar sobre a interface web do I2PTunnel? 15:28 <jrandom> r0x0r cat-a-puss 15:29 <deer> <Curiosity> também não me importo de ajudar com a edição web, etc. também :) 15:29 <jrandom> ok, se não houver mais nada, 5) Roadmap e tarefas 15:30 <jrandom> sensacional, Curiosity, obrigado! podemos bater um papo depois da reunião sobre dominar o mundo^W^W^W^Was coisas da web 15:30 <deer> <Curiosity> okies :) 15:30 <jrandom> como vocês provavelmente viram, tem uma nova página grande e assustadora no site (http://www.i2p.net/todo) 15:31 <jrandom> ela cobre os grandes e assustadores problemas que temos pela frente (e nem toca em todos os apps cliente que precisamos, etc) 15:31 <jrandom> como podem ver, temos uma porrada de coisas a fazer, mas a boa notícia é que não precisamos ter tudo pronto na hora. 15:32 <jrandom> na verdade, essas coisas são basicamente os itens com marcadores da página do roadmap (com um monte de texto introduzindo cada um) 15:33 <jrandom> apesar de eu saber que há muito para peneirar, seria ótimo se o pessoal pudesse me avisar se depararem com algo que vamos precisar tratar e que não esteja naquela página 15:34 <jrandom> não é necessário hoje ou mesmo nesta semana, só um geral "ei, nos avise" 15:35 <jrandom> com a sugestão do mule (http://www.i2p.net/todo#nat) tenho feito muita introspecção, e o roadmap provavelmente vai ser reorganizado um pouco 15:35 <jrandom> mas vamos ver. 15:36 <jrandom> se vocês têm sentimentos fortes sobre certos assuntos ("omg nós NÃO podemos funcionar sem X, Y e Z!"), por favor me avisem ou postem na lista 15:36 <jrandom> embora eu não seja um campeão da democracia, estou aberto à razão :) 15:37 <jrandom> ok, isso é tudo o que eu tinha a dizer sobre isso.. alguém tem algo a jogar na mesa? 15:37 <deer> <Curiosity> ditadura benevolente :) 15:37 -!- Sonium_ agora é conhecido como Sonium 15:37 <jrandom> bah, não sou ditador - não controlo o que as outras pessoas codam :) 15:37 <cervantes> hegemonia tranquila 15:37 <cat-a-puss> Consegui mais dois desenvolvedores 15:37 <jrandom> w00t! 15:38 <cat-a-puss> e tenho grandes planos para um motor de busca distribuído 15:38 <jrandom> oh, do caralho 15:38 <jrandom> isso seria algo com o qual o http://files.i2p/ poderia se integrar? 15:38 <jrandom> ou, bem, deixa eu só dizer, oh, do caralho :) 15:38 <cat-a-puss> er: não consigo chegar lá (ambiente hostil) 15:39 <jrandom> ah 'k 15:39 <cat-a-puss> de qualquer forma, um espaço no CVS seria bom, quando chegarmos lá 15:40 <jrandom> certamente, há espaço disponível no cvs.i2p 15:40 <jrandom> ou dentro do diretório i2p/apps/ ou seu próprio módulo, se preferir 15:40 <jrandom> (cvs.i2p == cvs.i2p.net) 15:40 <cat-a-puss> Eu provavelmente deveria falar com o pessoal que trabalha no dht, né? 15:41 <cat-a-puss> qual é o status disso até agora 15:41 <jrandom> :) 15:41 <jrandom> não ouvi atualizações de status do aum nos últimos dias, mas tenho certeza de que ele está mandando ver 15:42 <jrandom> a última atualização foi em http://dev.i2p.net/pipermail/i2p/2004-August/000425.html 15:43 <jrandom> ok, acho que isso nos leva a * 6) ??? 15:44 <jrandom> a Curiosity estava jogando a ideia de um 'live cd' com i2p 15:44 <jrandom> que eu acho bem legal, e algo que vamos querer 15:44 <deer> <Curiosity> massa :) 15:44 <jrandom> embora não estejamos realmente estáveis o suficiente para isso ainda, com um lançamento a cada 2 semanas mais ou menos 15:44 <hypercubus> concordo... poderia até ser integrado numa ISO do Knoppix 15:45 <deer> <Curiosity> ? 15:45 <hypercubus> Knoppix, uma distro linux livecd 15:45 <hypercubus> muito amigável 15:45 <deer> <Curiosity> k 15:45 <jrandom> embora, quando tivermos a funcionalidade Really Simple Update que é um download com um clique de http://dev.i2p/i2p/i2pupdate.tar.bz2, pode não ser tão ruim 15:46 <jrandom> Curiosity: você tem mais algo que queira discutir sobre isso? 15:46 <fvw> ...e assim que se tornar amplamente usado, qualquer um que controle o dev.i2p pode comprometer a rede. 15:47 <jrandom> contanto que as pessoas usem aquela funcionalidade Really Simple Update 15:47 * fvw concorda. 15:47 <deer> <Curiosity> eu só queria uma maneira das pessoas rodarem sem ter que baixar um monte de coisa no computador delas 15:47 <jrandom> (e se dev.i2p for comprometido, colocamos uma nova entrada no hosts.txt para dev.i2p) 15:48 <hypercubus> um livecd i2p knoppix seria perfeito para uso em cybercafé 15:48 <deer> <mule_iip> jarndom: um usuário real de i2p não pegaria o código-fonte, estudaria o diff contra a última versão revisada por pares e compilaria do fonte? :) 15:48 <fvw> sim, mas as pessoas vão simplesmente clicar em 'update'; Elas não vão ouvir discussões sobre se a nova versão pode ter vulnerabilidades... 15:48 <demonic_1> tem como não precisar de arquivo hosts. sabe, tipo um servidor dns? 15:48 <deer> <Curiosity> sim... aham mule_iip. lol 15:49 <fvw> mas enfim, vou ficar muito feliz quando chegarmos ao ponto em que isso vire um problema. 15:49 <fvw> demonic_l: É possível, mas ainda haveria uma autoridade central. 15:49 <hypercubus> demonic_1: há atualmente algumas propostas para tal funcionalidade, mas nomes globais foram descartados 15:49 <jrandom> demonic_1: sim, veja a lista de emails (discussões recentes em http://dev.i2p.net/pipermail/i2p/2004-September/000432.html ) 15:49 <jrandom> (e minha visão em http://dev.i2p.net/pipermail/i2p/2004-September/000435.html :) 15:50 <hypercubus> *nomes globalmente únicos 15:50 <demonic_1> k 15:51 <jrandom> ok, alguém tem mais algo que queira levantar? 15:52 <deer> <Curiosity> Eu também gostaria de sugerir colocar itens apenas do serviço em uma pasta service... eu estava tentando desinstalar o i2p (uma das muitas vezes) e estava clicando na coisa errada de desinstalar 15:52 <hypercubus> Curiosity: isso está sendo feito 15:52 <jrandom> w3rd 15:52 <hypercubus> o instalador vai instalar atalhos do i2p no menu Iniciar no Windows 15:52 <hypercubus> e opcionalmente no seu desktop 15:52 <deer> <Curiosity> ok :) 15:52 <hypercubus> entre eles estará "uninstall" 15:53 <deer> <Curiosity> eu estava falando quando eu entro em program files/i2p 15:53 <hypercubus> você não precisa a partir de lá 15:54 <hypercubus> Usuários Windows nunca entram nas pastas de programas ;-) 15:54 <demonic_1> :/ 15:54 <deer> <Curiosity> eu entro! :P 15:54 <jrandom> talvez possamos adicionar um dir bin/ com todos os scripts 15:54 <jrandom> er, deixa pra lá 15:54 <hypercubus> então você teria visto a pasta chamada "Uninstall" ;-) 15:54 * jrandom lembra dos caminhos 15:54 <hypercubus> que é onde o desinstalador fica 15:54 <jrandom> podemos mover os scripts de serviço para lib, porém 15:54 <hypercubus> não tenho certeza se dá 15:55 <cervantes> você poderia ir pelo método do 'doze e ter a opção "uninstall" no instalador ;-) 15:55 <hypercubus> o wrapper é muito exigente quanto a onde você põe esses 15:55 <jrandom> pelo menos eles podem dar um "cd .." primeiro 15:55 <hypercubus> vou ver sobre mudar a localização deles 15:55 <hypercubus> mas pode não ser viável 15:55 <jrandom> legal, obrigado. seria bom remover um pouco da bagunça no dir de instalação 15:55 <hypercubus> concordo 15:55 <jrandom> (a maior parte é culpa minha com todos aqueles arquivos .config :) 15:56 <hypercubus> poderíamos ter um dir config, acho 15:56 <cervantes> ./conf ? 15:56 <jrandom> qualé, somos geeks. etc/ :) 15:56 <jrandom> isso seria Muito Fácil porém 15:56 <jrandom> (só alguns parâmetros -D na CLI) 15:56 <hypercubus> então teremos que lidar com perguntas de usuários Windows de que "etc" não é óbvio o suficiente ;-) 15:56 <jrandom> as pessoas não deveriam precisar mexer na sua config 15:57 <jrandom> para isso serve a web 15:57 <cervantes> eu sempre fui pelo explícito: ./configuration/ 15:57 <hypercubus> certo, mas usuários Windows também não deveriam precisar abrir o desinstalador a partir da pasta de programas heheh 15:57 <jrandom> ./thesefilestellstufftodothings/ 15:57 <cervantes> ./scripts/ 15:57 <cervantes> ./asciipr0n 15:57 <jrandom> ok, mas sim, algum trabalho que podemos detalhar 15:57 <deer> <Curiosity> lol 15:58 <jrandom> alguém tem mais algo para trazer para a reunião? 15:58 <jrandom> se não 15:58 * jrandom se prepara 15:59 * jrandom *baf*s encerra a reunião