Reunião de Desenvolvimento do I2P - 18 de janeiro de 2005

13:04 <jrandom> 0) oi 13:04 <jrandom> 1) Status da rede 13:04 <jrandom> 2) 0.5 13:04 <jrandom> 3) i2pmail.v2 13:04 <jrandom> 4) azneti2p_0.2 13:04 <jrandom> 5) ??? 13:04 <ant> <duck> (o som da conversa sobre criptografia passando voando pelos meus ouvidos) 13:04 <jrandom> :) 13:04 * jrandom acena 13:04 <cervantes> olá 13:04 <jrandom> você também pode ouvir o som da conversa sobre criptografia passando voando pelos seus ouvidos! nota semanal de status publicada em http://dev.i2p.net/pipermail/i2p/2005-January/000559.html 13:05 <bla> oi 13:05 <jrandom> vamos entrar no assunto, já que estamos interrompendo uma discussão interessante de qualquer jeito... 1) status da rede 13:05 <jrandom> na verdade não tenho nada a acrescentar além do que está no e-mail - alguém tem algo que queira levantar com relação ao status da rede? 13:06 <bla> Além de termos visto, pela primeira vez, nós em *todos* os continentes, exceto a Antártida, não. 13:06 <jrandom> w00t! 13:07 <jrandom> ok, passando para 2) coisas da 0.5 13:07 <mule> ei, meu pai está a caminho da Antártida, devia ter dado a ele um nó 13:07 <ant> <duck> malditos antárticos 13:07 <Xan> sem antárticos? :( 13:07 <jrandom> hah legal 13:07 <jrandom> embora eu ache que não haja um conjunto de anonimato muito grande por lá 13:07 <Frooze> culpem a Antártida 13:08 * cervantes monta uma plataforma de petróleo na Antártida para poder financiar um nó lá 13:09 <jrandom> ok ok, tem muita coisa da 0.5, então podemos dividir em partes 13:09 <jrandom> primeiro, obrigado ao pessoal que reuniu um dia de estatísticas - muitos dados interessantes em http://dev.i2p.net/~jrandom/messageSizes/ 13:09 <postman> foi um prazer :) 13:10 <cervantes> quanto ao status da rede... tenho visto bastante gente com dificuldade para colocar o I2P de pé e rodando ultimamente (nos fóruns etc) - não sei se é só por aumento de volume de usuários ou talvez mais apps baseadas em i2p para as coisas darem errado 13:10 <+protokol> jrandom: MENTIROSO! você disse que os dados eram interessantes! 13:10 * jrandom joga lama no protokol 13:11 <ant> <duck> cervantes: também vi relatos de pessoas conseguindo colocar para rodar em poucos minutos 13:11 <ant> <duck> acho que o NAT está causando a maioria dos problemas 13:11 <cervantes> duck: verdade... 13:11 <ant> <dmdm> quem é o NAT? 13:11 <jrandom> cervantes: ainda há algumas questões feias, com certeza. o problema com NAT e com o OS X tem sido um pouco doloroso ultimamente, mas a ajuda do Jhor com este último deve melhorar a situação 13:12 <cervantes> sim 13:12 <cervantes> *cof* então... 0.5 13:13 <Xan> dmdm: network address translation (tradução de endereços de rede) 13:13 <jrandom> heh, ok. basicamente, o objetivo com aquelas estatísticas de tamanho de mensagens é explorar as questões de padding (preenchimento) 13:14 <jrandom> infelizmente, a estratégia que eu montei escolhendo números a dedo ficou uma droga, dando 25% de overhead só com dados de padding 13:14 <jrandom> se formos com uma das propostas para a criptografia da 0.5 (tunnels-alt.html), não teremos esse problema 13:15 <jrandom> (já que vai forçar tamanhos pequenos fixos com fragmentação) 13:15 <mule> que tipo de mensagens você quer aplicar padding, as que um router vê ou as que um observador externo vê? 13:15 <jrandom> mule: pergunta importante 13:15 <jrandom> se estivermos preocupados apenas com o observador externo, podemos deixar as mensagens sem padding, fazendo qualquer chaff generation (geração de ruído/enchimento) na camada de transporte 13:16 <Teal`c> http://microsoft.i2p/david_hasselhoff_05_christmas_album__silent_night.mp3 13:16 <jrandom> por outro lado, se estivermos preocupados com participantes do tunnel fazendo análise de fluxo, precisamos nos preocupar com padding ao longo do tunnel 13:16 <@duck> com 5-6 saltos, quão grande é o risco de um router fazer análise de tráfego? 13:16 <cervantes> Teal`c: reunião agora... pode usar #i2p-chat para anunciar mp3 ;-) 13:17 <Teal`c> desculpa 13:17 <cervantes> :) para o David Hasselhoff? 13:18 <jrandom> depende de qual nível de análise, duck. se de alguma forma eles rastrearam em qual tunnel estão (por exemplo, são o gateway do inbound tunnel e coletaram o netDb, correlacionando isso com um destino), isso é um dado não trivial. por outro lado não é uma exposição direta, mas dá alguma informação 13:18 <jrandom> mais importante que o padding no tunnel, porém, é o padding fim a fim, ocultando dados de fluxo de mensagens de gateways e endpoints. 13:19 <jrandom> se formos loucos/estúpidos, poderíamos ir até uma pipenet (rede com taxa constante), usando taxa de bits constante em todo lugar 13:19 <+polecat> saquei! 13:19 <jrandom> (e acabar sem usuários rodando i2p) 13:19 <+polecat> O que precisamos fazer é encapsular o i2p via e-mail! 13:19 <cervantes> qual a probabilidade de routers conluiados acabarem no mesmo tunnel em uma rede suficientemente grande? 13:19 <+polecat> Nenhum ISP seria burro o bastante para bloquear e-mail! 13:20 * jrandom aguarda a implementação net.i2p.router.transport.gmail 13:20 <postman> polecat: puxa, isso é bobo 13:20 <postman> :) 13:20 <bla> cervantes: N^(-h) (N é o nº de nós rápidos, h = nº de saltos). Ao que parece 13:20 <+polecat> =3 Eu sei. 13:21 <cervantes> isso é muito? :) 13:21 <jrandom> não é o nº de nós rápidos, pois pessoas externas não vão conhecer seus perfis 13:21 <+polecat> Mas falando sério, abusando sem vergonha dos serviços IP existentes, poderíamos encapsular o i2p de inúmeras maneiras engenhosas. 13:21 <jrandom> c^2/N^h para colocar dois pares no mesmo tunnel 13:21 <jrandom> concordo, polecat. essa é uma das razões pelas quais não temos tunnels bidirecionais 13:22 <jrandom> alguns transports (por exemplo, e-mail) são péssimos para comunicação bidirecional 13:22 <bla> jrandom: c = ? 13:22 <jrandom> c== nº de pares em conluio 13:23 <+polecat> Hum, ponto interessante. 13:23 <ant> <duck> pensando no roadmap, qual é o impacto de o i2p seguir na direção errada e escolher uma solução de criptografia errada? 13:23 <+polecat> Ou protocolo de pombo-correio, nada bidirecional. 13:23 <+polecat> a criptografia já é modular, não é? 13:23 <jrandom> duck: é só um item dentro da 0.5, e uma subseção do documento tunnels*.html. há muito mais no roteamento de tunnel do que apenas como empacotamos os dados 13:24 <bla> jrandom: Por outro lado, esse é o prob. de colocá-los no tunnel *agora*. Contudo, ao longo de T renovações de tunnel (a cada tantos minutos), isso fica como P = 1 - (1 - c^2/N^h)^T 13:24 <jrandom> por outro lado, a diferença entre "blocos fixos de 1KB" e "blocos de 0-40KB" tem impacto substancial 13:24 <+polecat> Eu odiaria ver esta rede seguir o caminho do Entropy, presa no McEliece. 13:24 <jrandom> polecat: leia http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD 13:24 <bla> jrandom: E assim tende a zero para um tempo suficientemente grande. Ou seja: para tempo suficientemente grande, os atacantes estarão no mesmo tunnel pelo menos uma vez 13:25 <jrandom> o plano é AES256/CBC padrão 13:25 <+protokol> ouvi dizer que DNS é bom para tunelar coisas, a maioria das pessoas não bloqueia 13:25 <jrandom> certamente, bla, embora não seja tão direto assim (para tunnels exploratórios é, mas não para tunnels de cliente) 13:26 <+polecat> E se de alguma forma até o AES for quebrado, algum cifra simétrica equivalente. 13:27 <jrandom> bla: não acho que isso seja uma preocupação prática grande o suficiente na maioria dos casos nesse grau, mas quando você monta isso como parte de um predecessor attack (ataque do predecessor), a questão fica em grande parte irrelevante 13:28 <jrandom> (por causa da forma como fazemos o restante do roteamento de tunnel) 13:28 <bla> jrandom: k 13:28 <jrandom> certo, polecat 13:29 <jrandom> duck: se formos com a segunda opção, mudar para outra depois provavelmente será fácil. 13:29 <jrandom> por outro lado, a segunda opção vai exigir um ajuste de desempenho pesado para Não Ser Ruim 13:29 <jrandom> mas tenho certeza de que conseguimos fazer acontecer 13:31 <jrandom> de qualquer forma, acho que o acima cobre onde estamos agora em relação ao trabalho da 0.5 13:31 <jrandom> alguém tem mais perguntas/comentários/preocupações? 13:31 <bla> jrandom: Uma 13:32 <bla> jrandom: acho que devemos valorizar o anon. um pouco mais do que o desempenho no momento: então sim, as opções com PRNG (gerador pseudo-aleatório) parecem boas 13:33 <jrandom> concordo. o desempenho pode ser ajustado depois; porém, "adicionar" melhor anonimato é muito mais difícil 13:33 <jrandom> (mas, claro, desempenho /é/ um parâmetro de segurança. se Fica Ruim, ninguém usa) 13:33 <bla> Sim. 13:33 <bla> jrandom: 13:33 <bla> foi mal 13:33 <@duck> certo, /me vira o bit mágico de desempenho do Freenet 13:33 <cervantes> talvez isso desanime todos aqueles leechers fãs de torrent a ficarem longe por mais um tempo ;-) 13:34 <jrandom> heh 13:34 <cervantes> <-- conexão reiniciada 13:34 <bla> cervantes: Não, eu não! :) 13:34 <cervantes> :) 13:35 <jrandom> eu realmente acho que podemos fazer otimizações bem legais, e parece que muito do nosso gargalo não está relacionado à seleção de peers, mas apenas (heh) a bugs na jobqueue 13:36 <jrandom> mas, enfim, mais alguma coisa para 2) 0.5? 13:36 <ant> <BS314159> você poderia postar uma explicação para esse loop attack (ataque de loop)? 13:37 <ant> <BS314159> parece mais perigoso do que o seu tratamento implica 13:37 <jrandom> loop: construa um tunnel contendo A-->B-->C-->D-->C, envie 10 mensagens. 13:37 <jrandom> sem os PRNGs, você pode adicionar quantas mensagens quiser naquele loop C<-->D 13:38 <ant> <BS314159> ok 13:38 <jrandom> fazendo efetivamente DoS em quaisquer routers com apenas algumas mensagens 13:38 <ant> <BS314159> mas só o A pode fazer isso 13:38 <jrandom> com os PRNGs, isso limita o número de mensagens que podem entrar no loop 13:38 <ant> <BS314159> então não há perigo de um atacante encurtar meus tunnels introduzindo loops 13:38 <jrandom> não, ninguém pode encurtar seus tunnels 13:39 <jrandom> a única coisa para a qual isso é útil é um DoS 13:39 <jrandom> (um DoS muito barato) 13:39 <jrandom> (mas quando você pode fazer DoS seletivamente em pares sem muito custo, dá para fazer coisas muuuito feias) 13:40 <ant> <BS314159> entendi 13:40 <+protokol> e certificados de hashcash vão ajudar nisso? 13:40 <jrandom> protokol: hashcash aborda a questão de um par construir tunnels demais e, talvez, saltos demais 13:41 <jrandom> protokol: isso não ajuda com loops. as duas maneiras que eu encontrei que /ajudam/ foram os PRNGs (tunnel-alt.html) ou verificar a cada passo (tunnel.html) 13:42 <jrandom> verificar a cada passo tem perigos, então a inclinação atual é em direção aos PRNGs 13:42 <+Ragnarok> quão eficaz será o método com PRNG? 13:42 <Xan> A-->B-->C-->D-->C - cada salto não deveria receber um id diferente ou algo assim, para que as mensagens saiam do tunnel na segunda vez que chegam a C em vez de ficarem em loop? 13:43 <jrandom> Xan: recebem, mas sem verificar a cada passo, você não consegue dizer se é ruim ou não 13:44 <jrandom> Ragnarok: acho que será muito eficaz em minimizar o dano causado 13:45 <jrandom> pelo menos, pelo que consigo ver até agora 13:45 <jrandom> se alguém vir algum problema/questão com isso, ou sugestões de melhoria, por favor entre em contato :) 13:46 <Xan> ou talvez eu esteja perdendo o ponto 13:46 <Xan> já volto 13:46 <jrandom> 'k até mais, vou atualizar o doc para ficar mais claro 13:47 <jrandom> ok, a menos que haja mais alguma coisa, vamos passar para 3) i2pmail.v2? 13:47 <jrandom> postman: você por aí? 13:48 <postman> sim 13:49 <postman> :) 13:49 <jrandom> algo a acrescentar do seu post no fórum? parece bem legal 13:49 <postman> bem, alguns de vocês talvez já tenham lido o rascunho do i2pmail.v2 13:50 <bla> wtf está acontecendo? Desconexões massivas. Estou com dificuldade para alcançar sites (tipo orion, library) aqui também 13:50 <postman> ele mira em uma infraestrutura de e-mail totalmente descentralizada no futuro 13:50 <postman> mas precisa de software de proxy nos nós bem como um conjunto de relays dedicados 13:51 <postman> todos estão convidados a contribuir com ideias / conceitos / desabafos 13:51 <postman> o desenvolvimento já começou - não esperem nada antes do fim da primavera :) 13:51 <jrandom> w00t 13:51 <kaji> hmm, a polícia acabou de aparecer na minha porta 13:52 <bla> kaji: ? 13:52 <jrandom> rápido, detona o seu disco rígido 13:52 <postman> jrandom: bem, isso é tudo que tenho a dizer por enquanto :) 13:52 <cervantes> esconda a mesa de blackjack! 13:52 <jrandom> irado, valeu, postman 13:52 <kaji> disseram que eu disquei 911, mas tenho certeza de que nem eu nem meu irmão fizemos isso 13:53 <+protokol> kaji: eles só estão checando o i2p 13:53 <jrandom> ok, a menos que haja mais alguma coisa em 3) i2pmail, vamos passar para 4) azneti2p_0.2 13:53 <+protokol> <música sinistra> 13:53 <jrandom> como mencionado no e-mail, houve alguns progressos importantes recentemente 13:53 <kaji> depois disseram que telefones sem fio podem pirar quando ficam fora do gancho, mas todos os meus sem fio estão no carregador -> #i2p-chat 13:55 <jrandom> o pessoal do Azureus tem sido muito solícito em preparar uma atualização (oba!), mas as pessoas também devem ficar atentas a problemas 13:55 <jrandom> (se você não lê a mailing list do i2p e usa o azneti2p, leia a mailing list do i2p) 13:55 <jrandom> ((ou mesmo se você não usa azneti2p, leia a lista, pois é lá que anunciamos coisas importantes ;) 13:56 <jrandom> duck e orion também têm feito muitas atualizações para acomodar o novo cliente de bt e a formatação 13:56 <jrandom> (oba!) 13:56 * orion sorri 13:57 <orion> ainda há um caminho a percorrer, mas por enquanto, funciona. 13:57 <jrandom> (na medida em que o i2p permite ;) 13:58 <orion> hehe, sim. ;) 13:58 <jrandom> mais alguém tem algo a levantar com relação ao azneti2p ou i2p-bt? 13:58 <jrandom> (ou bytemonsoon2p ;) 14:00 <jrandom> ok, se não, seguindo em frente para 5) ??? 14:00 <jrandom> pauta aberta - mais alguém tem algo a trazer? 14:00 <postman> jrandom: por que o addressbook publica entradas do userhosts? 14:01 <jrandom> postman: bug. 14:01 <postman> então isso não foi um comportamento planejado e será mudado? 14:01 <cervantes> só uma coisa... 14:01 <jrandom> postman: correto, e será mudado 14:02 <jrandom> (certo, Ragnarok? :) 14:02 <+Ragnarok> depende exatamente do que o postman quer dizer... 14:03 <jrandom> Ragnarok: novas entradas adicionadas pelo usuário local aos seus próprios hosts privados não deveriam ser propagadas para os hosts publicados 14:03 <jrandom> (por exemplo, userhosts.txt é privado, hosts.txt é sincronizado com outras pessoas e é público) 14:03 <cervantes> Como parte de um espaço semi-regular no fórum, haverá reconhecimento e prêmios para aqueles que contribuíram coisas boas para o I2P, seja recentemente ou ao longo da vida do projeto 14:03 <postman> Ragnarok: após atualizar para 0.4.2.6 encontrei entradas do meu userhosts.txt no addressbook publicado na minha pasta eepsite 14:03 <ant> <BS314159> hmm 14:04 <postman> Ragnarok: eram chaves adicionadas manualmente, que não deveriam ser publicadas 14:04 <cervantes> esta semana reconhecemos o duck pela excelência geral como provedor de serviços para a comunidade e como um grande idler em geral: http://forum.i2p/viewtopic.php?t=275 14:04 <jrandom> w00t! 14:04 <jrandom> (vai duck vai, vai duck vai) 14:05 <Teal`c> e quanto ao sequestro de nomes de domínio? 14:05 * brachtus aplaude 14:05 * orion faz um gingado de pato como sinal de respeito. 14:05 <cervantes> um ponto importante para o futuro... você não precisa ser um gênio da criptografia para receber elogios! 14:06 <+Ragnarok> não, esse é o comportamento esperado. Posso mudar, mas antes vou ter que terminar de implementar o bloqueio de arquivo para que você possa mudar o hosts.txt diretamente 14:06 <orion> (mas ajuda) 14:06 <cervantes> você pode simplesmente ter contribuído com um eepsite incrível ou algo assim... 14:06 <cervantes> ou ter sido uma pessoa prestativa no fórum etc 14:07 <ant> <BS314159> hmm 14:07 <cervantes> (caso contrário, convenhamos, o jrandom ganharia toda semana) 14:07 <jrandom> ei, vocês estão pagando meu fundo da cerveja, essas coisas não são de graça ;) 14:07 <ant> <BS314159> você poderia simplesmente criar um novo arquivo, "publichosts.txt"? 14:07 <ant> <BS314159> então fazer o addressbook ignorar o userhosts.txt, mas permitir que os usuários assinem o próprio publichosts.txt? 14:08 <jrandom> Teal`c: não há como sequestrar um nome de domínio, nenhuma entrada é sobrescrita, e userhosts sempre sobrepõe hosts 14:09 <jrandom> Ragnarok: talvez a interface web possa tratar a questão do bloqueio, já que os usuários não vão adicionar aos arquivos manualmente 14:09 <+Ragnarok> uma vez que o bloqueio esteja feito, não há razão real para puxar endereços do userhosts.txt mais (atualmente é a única maneira de evitar uma condição de corrida), então não há muito sentido em adicionar um terceiro arquivo 14:10 <+Ragnarok> jrandom: bem, eu estava planejando usar a API de bloqueio de arquivo do Java 14:10 <jrandom> se você acha que é necessário, você é o chefe :) 14:10 <ant> <BS314159> isso permitiria que você removesse todos os nomes obtidos de outras pessoas enquanto mantém os que você mesmo criou 14:10 <ant> <BS314159> simplesmente limpando o hosts.txt e mudando sua assinatura 14:11 <ant> <BS314159> mas acho que isso pode esperar por name-signing (assinatura de nomes) 14:11 <orion> Metadados vão resolver esse problema. Já existe um rascunho de especificação? 14:11 <jrandom> usar apenas dois arquivos deve ser suficiente - um gerenciado pelo addressbook, outro não 14:12 <jrandom> (você poderia até fazer o addressbook ignorar completamente o userhosts.txt - de qualquer forma, userhosts.txt sobrepõe hosts.txt) 14:12 <+Ragnarok> jrandom: esse seria o plano, uma vez que o bloqueio esteja feito (o que realmente não deve dar muito trabalho, só não cheguei a fazê-lo ainda :) 14:13 <+Ragnarok> e no momento estou trabalhando para aprender o suficiente de XML Schema para escrever um para os namerecords 14:13 <ant> <dr_kavra> este é o canal do kenosis? outro canal me disse para vir aqui :D 14:13 <jrandom> lol 14:13 <jrandom> nah, foi mal, aqui é i2p 14:14 <jrandom> (a não ser que você esteja procurando uma camada de comunicação anônima) 14:14 <jrandom> irado, Ragnarok 14:14 <ant> <BS314159> ainda acho que XML é verboso demais e pouco legível por humanos para isso, comparado a YAML, mas não sou eu quem está escrevendo o código 14:14 <jrandom> Ragnarok: a parte difícil será fazer a criptografia com XML sem recorrer a um CDATA feio 14:14 <orion> alguém já escreveu um rascunho funcional para a especificação de metadados? 14:15 <jrandom> (pessoalmente acho que XML é uma droga, mas sou só um do contra) 14:15 <jrandom> orion: http://dev.i2p.net/pipermail/i2p/2004-February/000135.html tem uma configuração básica 14:15 <orion> (metadados de nome/chave) 14:15 <dox> o addressbook e seus recursos foram anunciados em algum lugar? Eu não sabia que meu hosts.txt é publicado 14:15 <jrandom> (veja os elementos NameReference e LocalEntry) 14:16 <jrandom> dox: é escrito no local especificado em addressbook/config.txt 14:16 <jrandom> (por padrão, ./eepsite/docroot/hosts.txt) 14:17 <orion> está faltando um flag público/privado (isto é, distribuir, não). 14:17 <ant> <cervantes> a única coisa boa sobre XML (e isso é um grande ponto positivo) é que é um padrão amplamente aceito 14:17 <jrandom> certo, orion, surgiram muitas boas ideias desde aquele post 14:17 <+Ragnarok> XML pode ser ruim, mas, francamente, é melhor do que qualquer uma das alternativas para o que estou fazendo 14:17 <jrandom> cervantes: EDI também 14:18 <orion> há um lugar para condensá-las? isto é, área no fórum? 14:18 <orion> ou talvez uma página no wiki? 14:18 <jrandom> orion: o wiki do susi ou do ugha 14:18 <orion> vou configurar wikis para o bytemonsoon e para o orion.i2p para ajudar a obter algum consenso da comunidade quanto aos objetivos de desenvolvimento futuro de cada um. 14:18 <BrockSamson> xml + crypto sem CDATA = mime, não? 14:19 <jrandom> irado, orion 14:19 <jrandom> BrockSamson: S/MIME, com analisadores diferentes ;) 14:19 <orion> (também um para metadados de nomes) 14:21 <jrandom> há muitas maneiras de fazer os metadados, o importante é flexibilidade e 'correção' para que possa crescer ou mudar ao longo do tempo 14:21 * jrandom tem certeza de que Ragnarok et al. vão propor coisas boas :) 14:21 <orion> é por isso que acho que um rascunho público é apropriado. 14:22 <ant> <cervantes> consórcio i2p :P 14:22 <jrandom> bem, as pessoas têm dito "alguém deveria colocar suas ideias no wiki" nas últimas reuniões, mas as páginas do wiki não estão crescendo muito ;) o que é ok, vamos no nosso ritmo 14:23 * orion promete colocar três wikis no ar dentro de um dia e enviar por e-mail a todos suas localizações 14:23 <BrockSamson> me chamem de preguiçoso, mas compare um EDI de Pedido de Compra ANSI 850 com quase qualquer pedido de compra baseado em XML, e eu prefiro decodificar, codificar e depurar a versão em XML. Mesmo que tenha 5x o tamanho do EDI 14:23 <jrandom> w00t 14:23 <jrandom> heh BrockSamson 14:24 <BrockSamson> Posição 10 é ST? ah então a posição 310 deve ser nome 14:24 <BrockSamson> dã 14:24 <jrandom> BrockSamson: não acho que os schemas XML para POs sejam muito melhores ;) 14:24 <jrandom> (mas é, essas coisas são um desastre sangrento total) 14:25 <BrockSamson> são às 4:30 da manhã 14:25 <BrockSamson> a não ser que... 14:25 <jrandom> heh 14:25 <BrockSamson> tenha sido escrito por um ex-programador de EDI 14:25 <BrockSamson> e o xml fica assim: <p1><po><q>1</q></po></p1> 14:26 <BrockSamson> aposto que, se você somar as horas que projetos OpenSource gastam discutindo 'XML' ou não 'XML', daria para programar o Linux 10x. 14:26 <BrockSamson> todo projeto de que participei teve debates enormes sobre isso 14:27 <orion> debates são bons para um projeto, dependendo de quem está debatendo. ;) 14:27 <jrandom> eh, faz o que faz, mas não é uma panaceia. pode funcionar bem para a parte de nomes 14:28 <BrockSamson> muitas pessoas estão em projetos só para debater, porém. 14:28 <jrandom> não aqui. estou aqui pela cerveja grátis 14:28 <ant> <cervantes> isso é discutível 14:28 <orion> os detalhes de implementação ficarão mais claros quando o rascunho da especificação for mais tangível. 14:28 <orion> daí a necessidade de um wiki/peer review. 14:29 <BrockSamson> ouvi dizer que este projeto dava alho grátis 14:29 <jrandom> muito alho 14:30 <jrandom> ok, mais alguém tem algo a trazer para a reunião? 14:30 <ant> * cervantes empurra para fora a vaca cerimonial com sino 14:30 <ant> <cervantes> call =cow 14:30 * jrandom se prepara 14:31 * jrandom dá um *baf* no sino da vaca, encerrando a reunião