Reunião de Desenvolvedores do I2P - 24 de outubro de 2006

16:03 <jrandom> 0) oi 16:03 <jrandom> 1) Status da rede 16:03 <jrandom> 2) Status do desenvolvimento do Syndie 16:03 <jrandom> 3) ??? 16:03 <jrandom> 0) oi 16:03 * jrandom acena 16:03 * Complication tropeça até algum lugar ao alcance do teclado (o começo da semana foi um inferno, mas já acabou) 16:04 <jrandom> (viva os começos infernais!) 16:04 <jrandom> notas de status semanais publicadas em http://dev.i2p.net/pipermail/i2p/2006-October/001315.html 16:04 <+Complication> Olá 16:05 <jrandom> enquanto vocês leem as (curtas) notas, vamos pular para 1) Status da rede 16:05 * jrandom está conectado ao freshcoffee há 3 dias sem desconectar, e parece que ambos os servidores de irc têm um bom número de usuários 16:06 <jrandom> stats.i2p voltou também, e a taxa de sucesso de tunnel tem dado alguns saltos estranhos, mas em geral está em boa forma também 16:06 <jrandom> (embora ainda na faixa de 20-30) 16:06 <jrandom> ((o que é muito melhor que 5-10, mas muito pior que 60-80)) 16:07 <jrandom> ok, alguém tem algo para trazer em 1) status da rede? 16:08 <+Complication> Similar aqui, mas sem conexões extra persistentes 16:08 <+tethra> além de aplausos, nada da minha parte! 16:08 <+Complication> Eu só queria deixar uma notinha relacionada a questões de NTP 16:09 <+Complication> Basicamente, no domingo, 29 de outubro, alguns fusos horários vão sair do horário de verão 16:09 <jrandom> (vai ser chato) 16:10 <+Complication> Eu pessoalmente espero que isso não cause problemas para ninguém, mas não entendo o suficiente de NTP para ter certeza 16:10 <+Complication> Então, caso a recente verificação de sanidade do servidor NTP (adicionada na versão .26) venha a incomodar alguém naquela noite... 16:11 <+Complication> ...achei melhor mencionar a chave de configuração com a qual isso pode ser desativado (se for necessário) 16:11 <+Complication> (assim quem lê as notas de status saberia) 16:12 <+Complication> Desativar isso pode ser feito inserindo a linha "router.clockOffsetSanityCheck=false" em http://localhost:7657/configadvanced.jsp 16:12 <+Complication> Mas, como disse, espero que ninguém precise disso 16:13 <+Complication> Vai ser interessante observar e ver como a rede se comporta naquela noite, conforme diferentes fusos começarem a mudar 16:13 <+Complication> Eu certamente vou observar, na esperança de que, se alguma anomalia for vista, talvez possa ser corrigida até a primavera :D 16:14 <jrandom> o minuto do evento provavelmente será bem instável, mas deve se curar logo 16:14 <+Complication> ...e era isso que eu tinha. :) 16:14 <jrandom> mas, com sorte vai dar certo, e se não, como você disse, há a primavera :) 16:14 <bar> e caso as coisas de fato b0rkarem, surgiram duas possíveis sugestões para melhoria futura no chat outro dia: 16:15 <bar> "prevent skewed routers from forming subnets by handing over control to NTP if peers <some number" 16:15 <bar> ...e "do not delete floodfill peer router infos from netdb if there are too few of them" 16:15 <jrandom> sim 16:16 <+Complication> De fato, ajustar o número necessário de pontos de dados (desvios de relógio dos pares disponíveis) exigidos para considerar confiáveis as medições de desvio dos pares 16:16 <+Complication> (opa, alguma redundância na minha última frase) 16:17 <+Complication> ...e sim, a verificação de floodfill. Entendo que nenhuma verificação semelhante existe atualmente? 16:18 <jrandom> certo 16:18 <+Complication> Parece que algumas pessoas, às vezes, seja por sorte ou mágica, podem estar conseguindo perder o rastro de pares floodfill 16:19 <jrandom> isso certamente deve ser corrigido 16:19 <jrandom> (isso atingiu algumas pessoas outro dia, quando um deles foi null routed) 16:20 <jrandom> (se #floodfill == 0, talvez tratar aleatoriamente alguns como floodfill) 16:20 <+Complication> Se isso for viável, possível também 16:21 <+Complication> Embora, talvez fazer isso além de manter pelo menos 2 (ou algo assim) pares floodfill seria uma aposta duplamente segura 16:22 <jrandom> sim 16:25 <jrandom> ok, alguém tem mais alguma coisa para 1) status da rede? ou vamos passar para 2) status do desenvolvimento do syndie? 16:25 <badger> sobre a estabilidade do irc: vendo muito muito muito menos reconexões no lado do servidor. 16:25 <badger> você quase poderia chamar isso de um serviço :) 16:26 <jrandom> :) 16:28 <jrandom> ok, pulando para 2) status do desenvolvimento do syndie 16:28 <jrandom> muito progresso aqui, como mencionado nas notas de status 16:28 <jrandom> também houve um monte de discussão sobre isso aqui nos últimos dias 16:28 <jrandom> alguém tem algo que queira trazer nesse front? 16:30 <@cervantes> instale algo diferente de mspaint 16:30 <jrandom> heh 16:30 <jrandom> bem, há valor em usar coisas *feias* para esboçar - limita expectativas 16:31 <+fox> <HotTuna> os links na postagem do fórum parecem estar fora do ar ... alguns, pelo menos.. 16:31 <@cervantes> Acho que isso é mencionado nas postagens 16:31 <+fox> <HotTuna> ah. . desculpa 16:31 <jrandom> hottuna: eles estão espelhados em dev.i2p.net/~jrandom/mockup/ 16:31 <@cervantes> alguns devem estar espelhados mais abaixo 16:32 <+Complication> Uma pergunta: então, você acha que é mais fácil (com segurança) implementar HTML limitado do zero, sem dissecar algum navegador? 16:33 * jrandom acabou de enviar mais duas imagens: dev.i2p.net/~jrandom/mockup/forum.webp and blog.webp (mostrando a discussão dos últimos dias sobre diferentes maneiras de visualizar um fórum) 16:33 <@cervantes> com certeza é mais fácil fazer isso com segurança 16:33 <+Complication> (só por curiosidade sobre o que está acontecendo no lado da GUI, já que eu estava meio alheio) 16:33 <jrandom> Complication: já tenho quase tudo pronto para fins de formatação geral 16:33 <@cervantes> especialmente dado o subconjunto limitado de HTML que o Syndie vai suportar 16:34 <+Complication> Aha 16:34 <jrandom> (fontes, alinhamento, tamanhos, cores, imagens, links, listas (incluindo aninhadas), cabeçalhos, parágrafos, entidades HTML) 16:35 <jrandom> agora, fazer divs para posicionamento ou tabelas exige substancialmente mais trabalho, mas não vou enfrentar isso agora 16:35 <+Complication> Parece bom o suficiente 16:36 <@cervantes> e claro a tag <blink> 16:36 * jrandom ataca cervantes com † 16:37 <@cervantes> ai, traspassado por uma entidade 16:37 <jrandom> vamos ver. conforme isso for implantado e usado, talvez seja necessário mudar para um motor de renderização HTML completo 16:38 * jrandom quer que a base de código seja o menor possível, para haver menos para depurar e revisar quanto a questões de segurança e anonimato 16:39 <+Complication> De fato, há sem dúvida benefícios em lidar com text/plain 16:40 <+Complication> (que, com sorte, só dá suporte a ataques de linguagem natural ;P ) 16:41 <+Complication> Quais são as suas opiniões sobre a possibilidade de medidas antispam com hashcash? Cedo demais para dizer? Você acha que seria fácil anexá-las depois? 16:42 <@cervantes> bem, acho que usar bbcode ou sintaxe wiki reduziria o risco de injeção de marcação em um motor de HTML completo 16:42 <@cervantes> *motor de renderização 16:43 <jrandom> bem fácil de anexar, Complication - apenas um novo cabeçalho público (com hash calculado em relação ao URI canônico do Syndie, verificado na importação, criado na assinatura) 16:44 * Complication pensou em alguns há alguns dias, mas só de leve 16:44 <jrandom> o hashcash pode ser feito em vários níveis também - por novo canal (meta.syndie), por canal atualizado ou por post (talvez até graduado em função de sizeof(post) ou #msgs/day) 16:44 <+Complication> Se alguém quisesse implementar hashcash como prova de trabalho, fico pensando contra o que seria melhor exigir que quem publica a mensagem calculasse colisões? 16:45 <+Complication> Aha, o URI... pode ser mesmo 16:45 <+Complication> Ah, de fato 16:45 <+Complication> Isso são coisas em que eu não tinha pensado 16:48 <jrandom> cervantes: verdade 16:48 <jrandom> ok, alguém tem mais alguma coisa para 2) status do desenvolvimento do syndie? 16:51 <jrandom> ok, se não, vamos pular para 3) ??? 16:51 <jrandom> alguém tem mais alguma coisa que queira levantar? 16:54 <jrandom> ok, se não... 16:54 * jrandom se prepara 16:54 * jrandom fecha a reunião com um *baf*