Reunião de Desenvolvedores do I2P - 06 de fevereiro de 2007

15:02 <jrandom> 0) oi 15:02 <jrandom> 1) Status da rede 15:02 <jrandom> 2) Status de desenvolvimento do Syndie 15:02 <jrandom> 3) Vencedores do concurso de coleta de bugs de janeiro! 15:02 <jrandom> 4) ??? 15:02 <jrandom> 0) oi 15:02 * jrandom acena 15:02 <jrandom> notas semanais de status publicadas em http://dev.i2p.net/pipermail/i2p/2007-February/001333.html 15:03 <jrandom> pulando para 1) Status da rede 15:03 <jrandom> Não tenho muito a acrescentar aqui (como você provavelmente percebe ;) 15:03 <jrandom> alguém tem algo para levantar a respeito do status da rede? 15:04 <+void> já foi melhor, de algum modo... 15:04 <+void> mas não está ruim 15:05 <jrandom> é estranho, na última semana ou algo assim nossas taxas de construção (build) voltaram a subir, segundo o stats.i2p 15:05 <tethrage> há um padrão de longo prazo? 15:06 <tethrage> (na mudança da taxa de construção) 15:07 <jrandom> afaics, os padrões têm sido associados à capacidade de routers de alto desempenho, mas isso oferece apenas uma visão muito limitada da rede (já que eu só sei o que está publicamente disponível, basicamente) 15:07 <tethrage> entendi 15:08 <tethrage> há alguma informação que poderia ser fornecida para ajudar? 15:08 <tethrage> de routers normais, quero dizer 15:08 <jrandom> na verdade não, do meu ponto de vista 15:09 <tethrage> entendi 15:09 <jrandom> (basicamente só precisamos implementar algumas mudanças no código antes de avançar) 15:10 <tethrage> entendi 15:11 <jrandom> ok, alguém tem mais alguma coisa para 1) Status da rede? 15:12 <jrandom> se não, vamos pular para 2) Status de desenvolvimento do Syndie 15:14 <jrandom> muita coisa acontecendo aqui, como vocês podem ler 15:14 <+fox> <mk> menor: talvez mudar 'signed by' para 'authorization'? Estou um pouco nervoso com as linhas borradas entre fóruns, identidades, assinaturas e por aí vai 15:14 <+fox> <mk> -d 15:15 <jrandom> ah, é uma boa ideia 15:16 <+void> mk: um fórum é uma identidade :) 15:16 <+void> e vice-versa 15:17 <jrandom> sim, embora não queiramos confundir demais as pessoas tornando essa dualidade estranha visível 15:17 <+fox> <mk> Estou ciente, mas ainda é confuso. Eu entendo bem agora, mas me preocupo que novos usuários possam ficar confusos pela falta de diferenciação 15:18 <+void> ah 15:18 <jrandom> certo - as pessoas pensam em fóruns de maneira diferente do que pensam em identidades, então precisamos garantir que nos comportamos como esperado 15:18 <+fox> <mk> Outra coisa que pode valer a pena implementar no fórum ou no gerenciamento de identidades é algo explícito como 'post to this forum only under author x authorization y', o que eliminaria confusões. Você nem precisaria de um dropdown nas mensagens de novo post 15:19 <+fox> <mk> (um dropdown para chaves) 15:20 <+void> eu preferiria um dropdown global de identidade visível o tempo todo 15:20 <+fox> <mk> tipo, sob quem você está postando? 15:20 <jrandom> hmm 15:21 <+fox> <mk> talvez, mas realmente não há muita diferença, acho, entre tê-lo sempre no topo e fazê-lo aparecer apenas nos posts 15:22 <jrandom> ok, antes de mergulharmos demais nisso, há um canal lateral que o Syndie não trata atualmente que pode vincular múltiplas identidades 15:22 <+void> embora sua identidade não seja usada em nenhum outro lugar além de postar 15:22 <+fox> <mk> o que você quer dizer? 15:23 <+void> fazer push de novos posts? 15:23 <jrandom> se você precisa ter identidades completamente impossíveis de vincular, você precisa executar instâncias separadas do Syndie - você pode sincronizá-las entre si e usar apenas uma para fazer pull/push para outros arquivos, mas o arquivo local contém informações às quais apenas algumas das identidades têm acesso 15:23 <+fox> <mk> (Concordo que provavelmente devemos deixar as grandes discussões para o fórum de desenvolvimento, mas é bom ter um monte de gente falando sobre isso de uma vez) 15:24 <+void> verdade 15:24 <jrandom> entretanto, todas as identidades no arquivo local podem acessar essa informação e, se agirem com base nela (postarem com aquelas chaves, etc.), vão vazar a possibilidade de vinculação 15:25 <jrandom> talvez possamos encontrar uma maneira de realizar tudo isso de forma transparente pela GUI 15:26 <jrandom> (rodar com múltiplos arquivos localmente sem ter que iniciar o Syndie duas vezes) 15:26 <+fox> <mk> há muitos outros pontos - como marcar certos arquivos como exclusivos entre si - que poderiam ajudar com o anonimato. Devemos tentar definir todos esses cenários e encontrar uma forma de lidar com eles de maneira bem utilizável 15:27 <tethrage> Syndie não visa anonimato, só segurança 15:27 <tethrage> é a camada de transporte sobre a qual ele roda que deveria lidar com isso, certo? :/ 15:27 <jrandom> Syndie visa o anonimato 15:27 <tethrage> (corrija-me se eu estiver errado) 15:28 <jrandom> a camada de transporte lida apenas com uma pequena parte do anonimato - precisamos lidar com o resto 15:28 <jrandom> s/small// 15:28 <tethrage> é mesmo? :/ 15:28 <+fox> <mk> sim, isso mesmo. Syndie lida especialmente com vazamentos de informação 15:29 <jadeSerpent> anonimato de endereço IP vs. anonimato de identidade 15:29 <tethrage> entendi. Achei que você tinha dito há um tempo que o Syndie era para ser um app seguro que empregava cripto, mas não estritamente anônimo? 15:29 <tethrage> (não do mesmo jeito que o I2P etc., de qualquer forma) 15:29 <+fox> <mk> a segurança da informação é tratada pela redundância dos arquivos 15:29 <jrandom> mk: não tenho certeza do que você quer dizer com marcar os arquivos, mas eu adoraria um post no fórum de desenvolvimento do Syndie discutindo isso :) 15:29 <jrandom> tethra: Syndie pode ser usado para coisas que não exigem anonimato 15:30 <jrandom> mas Syndie precisa ser utilizável para coisas que exigem 15:30 <jrandom> (caso contrário, não faz sentido implementá-lo como parte do projeto I2P) 15:31 <tethrage> é 15:31 <+void> jrandom: bem, para ser justo, ainda haveria sentido se o Syndie fornecesse anonimato utilizando o I2P 15:31 <+void> mas deixa pra lá 15:31 <+void> c 15:31 <tethrage> o que, além de segurança contra vazamentos de informação e código duvidoso, o Syndie faz para manter as pessoas anônimas? :/ 15:32 <tethrage> certamente, a menos que especificado, você acessa os arquivos diretamente etc.? 15:32 <+fox> <mk> tethrage, vazamentos de informação de todos os tipos. Se quiser, podemos entrar em mais detalhes daqui a pouco 15:33 <jrandom> tethra: por exemplo, alguém acessando um eepsite com JavaScript habilitado 15:33 <jadeSerpent> tethrage: não há garantia de que os posts que você faz push para um arquivo se originaram de você, alguém pode ter feito push deles para o seu arquivo 15:34 <tethrage> jrandom: sim, o JS pode revelar coisas e tal. Mas certamente isso é mais uma questão de segurança do que de anonimato se você não está usando alguma rede anônima? 15:34 <tethrage> por outro lado, acho que estou discutindo semântica, então vou parar 15:34 <tethrage> :/ 15:34 <jadeSerpent> eu diria que rodar seu próprio arquivo publicamente acessível aumenta seu anonimato nesse aspecto 15:34 <+fox> <mk> jrandom, vou fazer esse post. Além disso, tenho brincado com um design para um navegador (não gosto de abrir novas abas para novas seções), então vou tentar fazer um protótipo e talvez postar alguns rabiscos no dev 15:34 <jrandom> “segurança contra vazamentos de informação” é o cerne do anonimato - controlar quem sabe fatos sobre sua identidade 15:35 <jrandom> ah, demais, mk, obrigado! 15:35 <jrandom> jadeSerpent: certamente 15:35 <tethrage> entendi 15:35 <tethrage> ponto entendido 15:36 <jrandom> mk: se houver melhores maneiras de apresentar a UI do Syndie, estou 100% a favor (apenas uma porção muito pequena do código está vinculada a esses componentes baseados em abas) 15:36 <jrandom> e estamos em alpha, afinal 15:38 <+void> jrandom: não creio que seja difícil transformar a interface com abas em uma interface com janelas? 15:38 <+fox> <mk> sim. E se algumas pessoas preferirem a abordagem de abas para tudo, então não há problema em usar isso 15:38 <+fox> <mk> (junto da aba do navegador) 15:39 <jadeSerpent> por favor, nada de MDI; sugiro algo no meio do caminho entre abas e MDI, as perspectivas do Eclipse 15:39 <+void> MDI é ruim, concordo 15:40 <jadeSerpent> o NetBeans tem algo assim também, esqueci como se chama 15:40 <jadeSerpent> views ou workbenches ou algo assim, já faz um tempo 15:41 <jrandom> esboços .webp são bem-vindos :) 15:41 * jrandom foi com o estilo de abas-para-tudo porque todo mundo ama o Firefox (/etc) 15:42 <jadeSerpent> quando eu terminar os ícones, talvez eu faça uns hacks nisso 15:42 <+fox> <mk> o ciclo de lançamentos de 2 semanas é uma coisa boa. Gosto de ver essas metas explícitas, mas também gostaria de ver algumas metas ‘mais suaves’ listadas - documentação para dev e, mais tarde, para usuários, diagramas e por aí vai 15:42 <jrandom> maneiro 15:42 <jadeSerpent> abas estão ok por enquanto imo, são utilizáveis 15:42 <jrandom> mk: http://syndie.i2p.net/roadmap.html ? 15:42 <jrandom> (embora não haja datas no roadmap) 15:43 <+fox> <hottuna> legal :=) ... acabei de postar sobre isso nas tarefas pendentes :P 15:44 <+fox> <mk> sim, embora eu esteja me referindo a metas menores. "documentar as interações gerais entre classes em syndie.gui", ou "escrever um doc sobre banimento" etc. 15:44 <jrandom> ah, bom ponto 15:45 <jrandom> eu estava querendo reunir novamente todos os itens de todo de baixo/médio/alto nível 15:45 * jrandom adiciona isso à lista de todo 15:47 <jrandom> ok, alguém tem mais algo para levantar em 2) Status de desenvolvimento do Syndie? 15:48 <jrandom> (claro, sempre temos os fóruns de dev no Syndie, mas o IRC é útil para um vai-e-vem rápido) 15:49 <jrandom> se não, vamos pular para 3) Vencedores do concurso de coleta de bugs de janeiro! 15:50 <jrandom> parabéns Darn, voyde, mk e Anonymous, e obrigado a todos que ajudaram 15:51 * jrandom percebe que o concurso era originalmente para os 3 primeiros, mas a contagem ficou tão próxima 15:51 <jrandom> há um novo concurso neste mês também, mesmas regras de antes 15:51 <jadeSerpent> como você sabe que “Anonymous” era apenas uma pessoa? ;) 15:51 <+fox> <mk> 225 (pela minha contagem) bugs no total - impressionante 15:51 <+void> :) 15:52 <+fox> <mk> jade, a chave, eu diria :) 15:52 <jrandom> jadeSerpent: urn:syndie:meta:d7:channel44:Ffn4RhCunO6gwMfAYfOoPY7FGwPNDy65dS4DyuyorME=e :) 15:53 <jrandom> poderiam ser cinco pessoas compartilhando essa chave, porém 15:53 <jrandom> mas então eles terão que compartilhar os $50USD ;) 15:53 <jrandom> (o primeiro com a chave privada que assinar uma mensagem para mim especificando para qual conta no egold enviar, ganha ;) 15:53 <jadeSerpent> a menos que um mate os outros 15:54 <jadeSerpent> mas esse tipo de coisa só aconteceria na Romênia 15:54 <tethrage> e na Rússia 15:54 <jrandom> (e na Grã-Bretanha, e na Austrália, e...) 15:55 <+fox> <mk> 50usd é uma grana e tanto... 15:55 <jadeSerpent> na Rússia todos seriam mortos, e o senhorio pegaria o dinheiro e passaria para a máfia como taxa de proteção 15:55 <tethrage> não em GBP ;p 15:55 <+fox> <mk> Eu sei que *eu* mataria por isso 15:55 <tethrage> imagino que perguntar de onde você é não renderia uma resposta, mk? 15:55 <tethrage> :/ 15:56 <+fox> <dw_g> ok, eu aceito ;) 15:56 <+fox> <mk> Rússia originalmente :D agora Canadá 15:56 <jadeSerpent> 225 bugs é impressionante, quantos desses foram fechados? 15:56 <tethrage> ice. 15:56 <tethrage> +n 15:57 <jrandom> jadeSerpent: eu chutaria que talvez 75-80% foram tratados 15:57 <jadeSerpent> legal 15:58 <jrandom> (com talvez mais 5-10% inválidos/wontfix) 15:58 <jrandom> mas na verdade, esse é um dos itens de todo de nível mais alto - conseguir uma UI de gerenciamento de verdade para o bugtracking 15:58 * jadeSerpent recomenda o Trac 15:58 <jrandom> (demorei um pouco para percorrer todos os posts e contá-los manualmente) 15:58 <+fox> <mk> externo ao Syndie? 15:59 <jrandom> hmm, com um sistema de exportação de syndie-->track? 15:59 <jrandom> s/ck// 15:59 <+fox> <mk> um projeto legal seria integrar o Syndie a um rastreador de bugs 15:59 <jadeSerpent> sim 15:59 * jrandom aposta que algumas consultas SQL & inserts resolveriam 16:00 <jrandom> seria bem válido, pelo menos de uma perspectiva de trac somente leitura 16:00 <+void> mas sincronizar atualizações feitas no Trac de volta para o Syndie deve ser complicado, acho 16:00 <jrandom> integração de ciclo completo é muito difícil 16:00 <jrandom> certo 16:00 <+fox> <mk> em algum momento pode valer considerar um sistema do tipo 'revision' 16:00 <jrandom> mas poder consultar e detalhar no Trac, e gerar relatórios, etc 16:01 <+fox> <mk> onde posts substituem os mais antigos 16:01 <jrandom> ah, sim, há ganchos para isso, mas os cabeçalhos Overwrite* não são atualmente respeitados 16:02 <jrandom> não seria tão difícil, porém, apenas um toggle na UI para navegar para revisões anteriores do mesmo post, além de algumas linhas de código para verificar se o post está autorizado a sobrescrever o post antigo 16:03 <jadeSerpent> entendo o desejo de usar o próprio Syndie para relatar bugs, mas seu design não envolve rastreamento de issues e sempre será subótimo para essa tarefa; na minha opinião, vocês deveriam usar um rastreador de issues de verdade 16:04 <+fox> <mk> vendo o número de bugs registrados, concordo com o jadeSerpent 16:05 <jrandom> embora, por outro lado, quantos bugs foram descobertos por aqueles que usaram o Syndie para registrar os bugs? 16:05 * jrandom não é totalmente contrário a um Trac ou outro sistema de rastreamento de bugs 16:05 <jadeSerpent> esse tipo de bug vai ser descoberto de qualquer forma 16:05 <+void> bem, severidades, componentes, versões e fechar/abrir/reabrir bugs podem ser feitos com tags do Syndie 16:05 <jrandom> certo 16:06 <+void> (e a maioria disso já é) 16:06 <jadeSerpent> como no outro dia quando travou com alguém que estava postando um relatório de bug; teria travado com ela se estivesse postando sobre qualquer assunto, não importava que fosse um relatório de bug 16:06 <jrandom> se pudermos alimentar um rastreador de issues real via mensagens pseudônimas (e autênticas), seria ótimo 16:06 * jrandom também recebeu alguns relatórios de bug privados, que incluem informações sensíveis - estes são protegidos pela criptografia do Syndie 16:07 <+fox> <mk> bem, por que não manter ambos? 16:08 <jadeSerpent> concordo que, no entanto, não há rastreador de issues projetado com anonimato ou confidencialidade mais do que trivial em mente 16:09 <+fox> <mk> seria bom que o Syndie tivesse esse tipo de rastreador de bugs, mas anonimato não é um problema tão grande ao enviar a maioria dos relatórios de bug 16:10 <jadeSerpent> talvez o Trac pudesse ser modificado para aproveitar os recursos do Syndie nisso 16:10 <+fox> <mk> jade, seria difícil. navegadores não implementam assinatura 16:12 <jrandom> hmm. o que temos é originalmente baseado em: http://syndiemedia.i2p.net:8000/blog.jsp?blog=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=&entry=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800003 16:12 <jrandom> além de http://dev.i2p.net/~jrandom/bugsp1.txt e http://dev.i2p.net/~jrandom/bugsp2.txt 16:13 <jrandom> concordo que precisamos de algo melhor do que o que temos para rastrear essas issues, e estou aberto a qualquer coisa que melhor nos faça avançar 16:13 <jrandom> mas eu gostaria de manter o que quer que seja minimalista, se possível, porque estamos construindo o Syndie, não um rastreador de bugs :) 16:14 <jadeSerpent> bem, você parece estar gerenciando por enquanto sem um ;) 16:14 <jrandom> mas tenho certeza de que alguns vão cair pelas frestas, e outros terão mais dificuldade em encontrar o que é conhecido/etc. e em contribuir com correções 16:15 <+fox> <mk> provavelmente nem precisamos implementar isso via Syndie. É útil ali até certo ponto, mas 200+ bugs é realmente muito. Devemos decidir por um tracker e disponibilizá-lo pela web e pelo I2P 16:16 <+fox> <mk> fornecer um link para ele no topo da tela de registrar bug do Syndie, e assim teremos ambas as opções. Uma implementação de rastreador de bugs no Syndie não é algo em que devamos usar recursos agora 16:17 * jrandom adora ter o rastreamento de bugs integrado (assim as pessoas não precisam criar contas no rastreador de bugs, usar e-mails falsos, etc.), mas estou aberto a propostas sobre qual solução devemos usar 16:17 <+fox> <mk> acho que devemos manter isso, mas também ter esse rastreador de bugs 16:18 <jadeSerpent> acesso somente leitura no curto prazo seria bom 16:18 <jadeSerpent> eu prefiro uma interface de busca mais orientada a bugs 16:18 <jrandom> não seria tão ruim, talvez pudéssemos escrever também uma exportação unidirecional de syndie-->issue tracker sem muito problema, para aqueles que não podem/ não querem usar a baseada na web 16:19 <jrandom> s/of r/for/ 16:19 <+fox> <mk> o envio de bugs integrado é uma ótima coisa para ter, mas não devemos usar o arquivo do Syndie para rastrear 200+ bugs 16:20 <jrandom> embora seja ótimo para testar nossas capacidades de busca :) [sim, ok, estou convencido] 16:20 <jrandom> então, um voto para o Trac. mais algum voto? por favor, postem no fórum de desenvolvimento do Syndie, com justificativa, claro 16:21 <jadeSerpent> dois votos para o Trac, a menos que você já tenha contado o meu ;) 16:21 <jrandom> sim, era isso que eu estava contando ;) 16:21 <+fox> <mk> quais são as opções? Eu não sei nada sobre trackers 16:21 <jadeSerpent> eu esperava que esse fosse seu próprio voto, mas ok 16:22 <jadeSerpent> já trabalhei com Trac, ótimo suporte de terceiros 16:22 <jadeSerpent> bugzilla eu diria bleh 16:22 <jrandom> embora, de lado, se alguém for bem familiar com um rastreador de issues, isso ajudaria a aprontar uma exportação de syndie-->issue tracker 16:22 <jrandom> sim, o Bugzilla é uma besta 16:22 <jadeSerpent> JIRA também é bom, como o Trac 16:23 <+void> Trac provavelmente também é familiar para muita gente 16:23 <jrandom> sim, e são gente boa também (eles deram ao I2P uma licença, embora ainda não a tenhamos usado) 16:23 <jadeSerpent> vocês têm uma licença do JIRA? 16:23 <jrandom> sim, JIRA e Fisheye 16:24 <jadeSerpent> legal, vale a pena tentar 16:24 <jadeSerpent> aliás, o plugin mylar do Eclipse integra-se completamente ao Bugzilla, Trac e JIRA 16:24 <jadeSerpent> altos elogios para sua interface 16:25 <jrandom> maldita essa batalha NetBeans/Eclipse 16:25 <bar> (bugs são relatados automaticamente quando criados? ;) 16:25 <tethrage> (haha) 16:26 <+fox> <mk> hah, legal 16:26 <jadeSerpent> jrandom: suporte ao NetBeans está no roadmap do mylar iirc 16:26 <jrandom> legal 16:26 <+fox> <modulus> é isso que vem para quem apoia fanaticamente a Sun :-) 16:27 * jrandom bombardeia modulus com javabeans 16:27 <jadeSerpent> embora o mylar esteja oficialmente sob a égide da Eclipse Foundation 16:27 <+fox> * mk não consegue encontrar um site ao vivo do Trac 16:27 <+fox> <modulus> http://trac.wordpress.org/ 16:27 <jrandom> mk: http://feedspace.i2p/ atm 16:28 <+void> http://trac.edgewall.com/ 16:29 * jrandom não quer gastar muito tempo avaliando muitos sistemas diferentes, então se alguém quiser defender um sistema específico, por favor faça isso no fórum de desenvolvimento do Syndie 16:29 <jadeSerpent> http://overlays.gentoo.org/proj/alt/wiki 16:29 <+void> (^ meta-trac oficial) 16:29 <+fox> <mk> sim, para mim dá no mesmo 16:30 * jrandom vai assumir que é isso para * 3) Vencedores do concurso de coleta de bugs de janeiro! e nos levar para 4) ??? 16:30 <jrandom> alguém tem mais alguma coisa para a reunião? 16:30 <+fox> <mk> 'melhor' é superestimado. quem tiver mais experiência com essas coisas provavelmente deveria jogar uma moeda 16:32 * jrandom não está realmente procurando um sistema de planejamento de projeto/planejamento de releases, ou um navegador de código-fonte (um wiki gratuito não faz mal, mas também temos o ugha.i2p) 16:32 <jrandom> rastrear issues é a única funcionalidade que me importa nisso 16:37 <jrandom> ok, se não há mais nada para a reunião... 16:37 * jrandom encerra 16:37 * void entrega a jrandom o baffer 16:37 * jrandom *baf*s a reunião encerrada