Reunião de Desenvolvedores do I2P - 23 de agosto de 2005

12:01 <jrandom> 0) oi 12:01 <jrandom> 1) status do 0.6.0.3 12:01 <jrandom> 2) status do IRC 12:01 <jrandom> 3) susibt 12:01 <jrandom> 4) Syndie 12:01 <jrandom> 5) ??? 12:01 <jrandom> 0) oi 12:01 * jrandom acena 12:01 <lucky> oi 12:02 <jrandom> notas semanais de status no ar @ http://dev.i2p.net/pipermail/i2p/2005-August/000857.html 12:02 <lucky> hihihihi 12:02 <jrandom> oi lucky 12:02 <jrandom> ok, indo para 1) status do 0.6.0.3 12:02 <jrandom> acho que as principais coisas que valem mencionar com relação ao 0.6.0.3 estão nas notas de status, mas além disso, alguém tem algo para levantar? 12:04 <gott> Qual é a de 'Unknown' ? 12:04 <jrandom> não tenho certeza se as melhorias de cwin do SSU virão no 0.6.0.4 ou vão esperar até 0.6.1 quando tivermos melhor configuração de pares 12:04 <jrandom> gott: há dois parágrafos no e-mail sobre isso — você tem alguma pergunta específica além disso? 12:05 <jrandom> ou há algum ponto que eu possa esclarecer? 12:05 <gott> Não, é que eu ainda não li o maldito e-mail. 12:05 <jrandom> hehe 12:05 <jrandom> bem, suba cinco linhas e leia o maldito e-mail ;) 12:06 <jrandom> ok, mais alguém tem perguntas sobre o 0.6.0.3? 12:07 <jrandom> se não, passando para 2) status do IRC 12:07 <modulus> foi mal, pessoal, mas preciso sair. até mais, todos. 12:08 <jrandom> além do que está no e-mail, postman/cervantes/arcturus: vocês têm algo que queiram levantar? 12:08 <jrandom> até mais, modulus 12:08 <+arcturus> sobre 1)? 12:08 <+arcturus> ah, foi mal 12:08 <gott> Hum. 12:08 <+arcturus> agora é 2) 12:09 <gott> Quanta largura de banda de upstream o IRC sobre I2P costuma consumir no momento? 12:09 <+arcturus> netsplits são coisa do passado 12:09 <+arcturus> gott: eu não poderia dizer isso sem comprometer o anonimato do meu router 12:09 <gott> Não, não, não. 12:10 <jrandom> não sei, meu router com squid.i2p/dev.i2p/cvs.i2p/www.cvs/syndiemedia.i2p mais meu IRC e eepproxy usa em média 10–20 KB/s 12:10 <gott> Isso requer uma linha comercial? 12:10 <jrandom> boa, arcturus 12:10 <gott> jrandom: quero dizer, para hospedar. 12:10 <jrandom> gott: operar um servidor ou um cliente? 12:10 <jrandom> ah 12:10 <+arcturus> gott: eu não poderia dizer isso sem comprometer o anonimato do meu router 12:10 <gott> servidor. 12:10 * jrandom não sabe. provavelmente menos quando você tem apenas um ircd 12:10 <gott> Então você está rodando um unrealircd modificado? 12:11 <jrandom> digamos, some um fator de 1,3 ao uso do cliente para um único servidor 12:11 <+arcturus> gostaria também de acrescentar que o lag entre servidores é estável e muito, muito baixo 12:11 <gott> Presumo que sim, já que não parece haver o comando VERSION 12:11 <+arcturus> eu desativei o VERSION 12:12 <gott> Suas modificações são de código aberto? 12:12 <+arcturus> talvez estejamos rodando unreal, talvez não :) 12:12 <gott> Você deveria publicá-las para que outros possam iniciar suas próprias redes privadas. 12:12 <+arcturus> não posso te dizer sem comprometer a segurança 12:12 <gott> segurança pela obscuridade, que beleza. 12:12 <jrandom> isso aí, arcturus. estou vendo algo como 0–2 s de lag em média (no momento, menos do que o detector de lag do irssi) 12:12 <+arcturus> não, é apenas uma camada de segurança 12:13 <+arcturus> e só serve como um elemento dissuasor, não substitui medidas técnicas de segurança 12:15 <jrandom> arcturus: como vai o vanguard? 12:15 <+arcturus> não tenho codado nele ultimamente, outros projetos têm me ocupado, mas sinto uma pressão constante e firme para acabar com isso :) 12:16 <jrandom> hehe maneiro 12:16 <+arcturus> vanguard será mais eficaz contra bots, a medida de hashcash é um assunto à parte 12:16 <+arcturus> mas estou preocupado com hashcash agora 12:17 <+arcturus> com os ataques mais recentes contra o SHA-1 12:17 <+arcturus> não vai demorar para haver ferramentas disponíveis para as massas 12:17 <+arcturus> infelizmente, a implementação padrão de hashcash é baseada inteiramente em SHA-1 12:17 <susi23_> Unable to find a javac compiler; // com.sun.tools.javac.Main is not on the classpath. // Perhaps JAVA_HOME does not point to the JDK 12:18 <@cervantes> ah, consegui 12:18 <susi23_> alguma ideia sobre isso? JAVA_HOME aponta com certeza para o diretório correto, javac está no PATH e é executável 12:18 <+arcturus> susi23_: estamos em uma reunião no momento :) 12:18 <jrandom> susi23_: OOM (falta de memória)? 12:18 <susi23_> reunião? mas são 20h? 12:18 <jrandom> (pré-compile suas JSPs em vez de deixar o Jetty/Tomcat fazer, é mais rápido ;) 12:19 <jrandom> sim, mudamos o horário, susi23_ :) 12:19 <susi23_> não sabia, desculpe 12:19 <jrandom> hehe sem problema, que bom que você chegou para a reunião, seu item da pauta é o próximo ;) 12:20 * susi23_ senta e escuta 12:20 <+arcturus> então, embora eu não espere problemas imediatos com hashcash, acho plausível que o SHA-1 possa ser seriamente comprometido em breve 12:21 <jrandom> arcturus: hashcash com MD5 provavelmente estaria ok 12:21 <jrandom> é só uma PoW (prova de trabalho) 12:21 <+arcturus> se alguém souber de alguma implementação de hashcash baseada em SHA-256 ou superior, por favor me avise 12:21 <+arcturus> bem, PoW é inútil se houver pouco P nela :) 12:21 <jrandom> o tamanho do hash só importa quando seu hashcash atinge o tamanho do hash 12:23 <jrandom> (mas, sim, rodar contra um SHA-256 truncado ou 512 ou Whirlpool ou o que for seria legal) 12:23 <+arcturus> acho que podemos seguir com a implementação atual; talvez possamos projetá-la de forma que possamos substituí-la facilmente depois, quando precisarmos 12:24 <jrandom> (DTSTTCPW) 12:25 <+arcturus> porque eventualmente teremos de abandonar o SHA-1, tenho certeza disso :) e se não pudermos ter uma razoável certeza de que um token foi gerado corretamente, não há razão sequer para usar hashcash 12:25 <jrandom> (é só uma PoW para obter um nym (pseudônimo) no IRC, não para conseguir acesso a Fort Knox ;) 12:26 <@cervantes> há alguma conversa na lista de e-mails do hashcash sobre implementar SHA-256 12:26 <+arcturus> não é para um nym (pseudônimo), é para a entrada no servidor 12:26 <+arcturus> cervantes: legal, vou conferir isso 12:27 <+arcturus> jrandom: e não é só PoW, o hashcash é o que nos dá um método para identificar exclusivamente clientes na rede, semelhante a poder identificar por IP, para que possamos banir com precisão 12:28 <jrandom> certamente isso é renovado ao longo do tempo, certo? 12:28 <jrandom> por exemplo, um novo certificado de PoW a cada 6 meses (ou 6 h, ou o que for) 12:28 <+arcturus> se um usuário não tiver de fazer trabalho algum para obter seu ID, isso anula nossa capacidade de bani-lo 12:29 <+arcturus> não conheço nenhum motivo para expirá-los automaticamente; só expirar manualmente se violarem os termos de serviço 12:29 <+arcturus> não há necessidade de fazer as pessoas realizarem trabalho desnecessário para novos IDs 12:29 <jrandom> eh, é apenas uma PoW passiva, eles podem rodar um ciclo a cada 6 horas para gerar uma nova 12:29 <jrandom> mas talvez DTSTTCPW 12:30 <+arcturus> qualquer hashcash gerado deve ser usado em 24 horas, ou será inválido 12:32 <@cervantes> só para reiterar: o novo servidor irc.freshcoffee.i2p precisa ser adicionado no seu i2ptunnel console 12:32 <jrandom> beleza. ok, mais algo para 2) irc2p? 12:33 <@cervantes> (http://forum.i2p/viewtopic.php?t=911 12:33 <@cervantes> ) 12:33 <@cervantes> <-- feito 12:34 <+arcturus> não tenho mais nada com que entediá-los :) 12:34 <jrandom> hehe 12:34 <jrandom> ok, 3) susibt 12:34 <ardvark> hum, quando eu adiciono o novo servidor ao meu tunnel, eu tenho que reiniciar o I2P? 12:34 <jrandom> susi23_: p1ng 12:35 <@cervantes> ardvark: apenas o tunnel 12:35 <@cervantes> (ircproxy tunnel) 12:35 <ardvark> ah ok, eu só adicionei e salvei, então isso não é suficiente, né 12:36 <jrandom> certo, infelizmente você precisa parar e iniciar esse proxy 12:36 <susi23_> bem 12:36 <ardvark> mas aí vou perder a reunião ;) 12:37 <susi23_> susibt é uma webapp (como o susimail) para colocar na VM (máquina virtual) do seu router 12:37 <susi23_> ela atua como um frontend web para o i2p-bt 12:38 <susi23_> assim você pode gerenciar seus seeds, fazer upload e download de arquivos, etc. 12:38 <jrandom> w00t 12:39 <susi23_> o problema é que você precisa iniciar um btdownloadheadless.py para cada seed... então você fica com muitos processos de Python além das suas muitas threads de Java :) 12:39 <+arcturus> isso será tratado no ducktorrent *cof* 12:39 <jrandom> hehe 12:39 * jrandom prende a respiração 12:40 <susi23_> ela inclusive suporta reinício dos seeds após reiniciar o router 12:40 <@cervantes> legal 12:40 <jrandom> irado 12:40 <susi23_> planos futuros incluem criação automática de torrents e melhoria da UI (interface do usuário) 12:41 <susi23_> se você quiser testar, recomendo uma instância separada do Jetty 12:41 <susi23_> assim você não precisa mexer no seu router :) 12:41 <susi23_> instruções de download e instalação em http://susi.i2p 12:42 <susi23_> é isso *ping de volta para o jr* 12:42 <jrandom> w3wt, valeu, susi 12:42 <jrandom> ok, alguém tem perguntas e comentários sobre isso, ou vamos pular para 4) syndie? 12:44 <jrandom> ok, sobre syndi, publiquei um monte na lista sobre isso no último dia ou dois, e haverá muito mais atividade 12:45 <jrandom> o principal site de demonstração do syndie é http://syndiemedia.i2p / http://66.111.51.110:8000/, mas claro, incentivamos as pessoas a baixá-lo e instalá-lo localmente 12:45 <jrandom> não tenho muito a acrescentar no momento nesse front. a menos que alguém tenha alguma pergunta? 12:46 <gott> Por que se chama syndie? 12:46 <gott> é uma referência a 'syndicate'? 12:47 <jrandom> sim, é um frontend de sindicação genérico (+ segurança, autenticação e consciência de anonimato) 12:48 <jrandom> ok, se não há mais nada em 4), vamos passar para 5) ??? 12:48 <jrandom> alguém tem algo relacionado ao I2P para trazer para a reunião? 12:51 <jrandom> ok, se não há mais nada 12:51 * jrandom se prepara 12:52 * jrandom *baf* encerra a reunião