Reunião de desenvolvimento do I2P - 25 de novembro de 2014

20:04:39 <str4d> Oi 20:04:44 <str4d> É hora da reunião 20:06:47 <str4d> zzz, psi, kytv, Meeh, dg 20:07:30 <psi> é? 20:07:39 <psi> ah terça-feira 20:09:03 <zzz> presente 20:09:48 <orignal> reunião? 20:10:11 <str4d> orignal: discutindo a lista de tarefas do Java I2P 20:10:35 <str4d> Enquanto esperamos outros aparecerem: http://trac.i2p2.i2p/wiki/Roadmaps/1.0 20:10:41 <kytv> Presente também, embora eu geralmente seja inútil quanto a essas coisas. 20:11:37 <str4d> Ajustei o gráfico de Gantt na página acima (que eu configurei para o ciclo de desenvolvimento 0.9.13-0.9.16) para mostrar o que acho que fizemos. 20:13:30 <zzz> interessante 20:14:06 <zzz> múltiplos destinos por tunnel <-- não aconteceu 20:14:22 <str4d> Não aconteceu? Ok, culpa minha. 20:14:27 <zzz> passada do FindBugs <-- aconteceu, mas sempre dá para fazer de novo 20:14:56 <str4d> Várias sessões por I2CP - isso também não aconteceu *derp* 20:14:56 * str4d corrige 20:15:48 <zzz> uau, tivemos um bom ano (na minha opinião) 20:16:38 <eche|on> sim, tivemos 20:17:14 <str4d> zzz: sim, eu chamei isso de parte da preparação para a auditoria especificamente, mas você está certo. 20:17:39 <zzz> investigar novo DH <---- eu diria que só pela metade, em relação ao NTCP2 de qualquer forma 20:20:26 <str4d> O Gantt não mostra facilmente "meio feito" :P 20:20:34 <str4d> Recarreguem a página, corrigido 20:21:36 <str4d> Ok, então isso é o que concluímos no último ciclo. 20:21:36 <zzz> então não está feito 20:23:45 <str4d> O objetivo desta reunião é começar a planejar o que será feito no próximo ciclo. 20:23:46 <zzz> Gostaria de reiterar que um ciclo de planejamento de 3–5 versões parece ser muito útil para focar nossas mentes e nossos recursos 20:23:47 <str4d> (Quando eu atualizar o gráfico de Gantt, vou deixar os itens meio feitos lá e empurrá-los para a frente) 20:23:47 <str4d> Na reunião anterior, pedi aos participantes que pensassem em alguns pontos cada um sobre coisas que querem ver feitas no I2P e ao redor do I2P 20:23:47 <str4d> Podemos colar isso agora, por favor? 20:24:21 <str4d> +1 20:24:36 <str4d> E agora temos evidências disso! 20:26:15 <zzz> sem entrar no que é mais importante do que o quê, acho que quase tudo o que está mostrado e inacabado no gráfico de Gantt ainda é importante 20:27:01 <str4d> Concordo. 20:27:07 <str4d> Ainda quero ver que ideias as pessoas tiveram na última semana, se é que tiveram. 20:27:45 <str4d> Aqui estão as minhas: http://pastethis.i2p/show/jF2RkHwrIPkCb0yOpI7l/ 20:27:46 <iRelay> Título: Paste #jF2RkHwrIPkCb0yOpI7l | LodgeIt! (em pastethis.i2p) 20:28:07 <eche|on> Estou sem opções, eu vejo de colocar o I2P para fora, com a ajuda de bote android, i2p messenger é uma opção, um servidor XMPP e syndie. Desculpe, ainda considero syndie importante. 20:28:27 <str4d> eche|on: ótimo, obrigado! 20:28:43 <str4d> Continuem mandando :) 20:28:53 <eche|on> e com o app Android vêm rotas restritas 20:28:54 <zzz> minha lista de coisas novas: resolver o problema ECDSA do Red Hat, migrar para EdDSA, Jetty 9 / Java 7, expandir a base de usuários do Vuze, e mais marketing / alcance / parcerias / incorporação 20:29:36 <str4d> Para perpetuarmos nos logs, vou escrever minhas ideias aqui também: 20:30:11 <str4d> A fazer no I2P: análise de UX da Routerconsole e redesign; Pegar ideias do design HS 2.0 do Tor e aplicar aos Destinos do I2P; Escalonamento de largura de banda. A fazer ao redor do I2P: melhorias de tema do site; Implementar relés de busca do I2P-Bote; Pesquisa 20:30:23 <zzz> mais uma: orchid: consertar ou matar 20:30:32 <str4d> +100 20:31:13 <kytv> Com relação ao problema ECDSDA no RedHat/Gentoo, talvez pudéssemos/deveríamos exibir uma mensagem na barra lateral (ou nos logs) com um link de download. Ou talvez perguntar ao usuário se “nós” devemos baixá-lo em ./lib 20:31:35 <zzz> mais uma: melhorias de testes, hardware de testes, testes no Windows 20:31:58 <str4d> kytv: boas ideias (mas discuti-las pode ficar para outra reunião :) 20:32:03 <zzz> mais uma: gastar mais dinheiro 20:32:36 <zzz> mais uma: China 20:32:58 <str4d> Entre essas ideias e a lista não concluída na página acima, temos um bom conjunto de projetos potenciais. 20:33:34 <str4d> Meu objetivo é deixar esses projetos organizados, formalizados e publicados na página de tarefas do site 20:34:11 <str4d> Dando uma fuçada nas páginas de tarefas de outros projetos, este é o formato que estou propondo: 20:34:11 <str4d> http://pastethis.i2p/show/nvexU3ZvSFOI6L5DrrqM/ 20:34:12 <iRelay> Título: Paste #nvexU3ZvSFOI6L5DrrqM | LodgeIt! (em pastethis.i2p) 20:34:54 <eche|on> boa ideia 20:35:10 <kytv> Idem em relação ao Orchid 20:35:10 <kytv> Meu principal “A fazer ao redor do I2P” é com relação a testes. Não testes automatizados com software, por si só, mas qualquer um dos nossos serviços indo ao ar sem qualquer tipo de teste... apenas [puf], “está no ar... mas não sei se funciona.” 20:35:12 <kytv> No I2P: Fazer o Instalador instalar no diretório do usuário no Windows para evitar qualquer tipo de problema de permissões. Deve ser fácil, mas eu não sei como. 20:35:16 <kytv> O Chrome fez isso (talvez ainda faça?) 20:35:41 <str4d> Meu resultado ideal: usuários podem ir à página de tarefas e encontrar uma lista de todas as ideias que temos para projetos no e ao redor do I2P. 20:36:11 <zzz> mais uma: GSoC 20:36:14 <str4d> Haverá uma nuvem de tags no topo em que possam clicar para filtrar projetos que exigem certas habilidades 20:36:17 <str4d> skills 20:36:21 <zzz> mais uma: encontro no verão 20:37:54 <zzz> mais uma: investigação de GNS, segunda passada? 20:38:28 <str4d> mmm 20:38:54 <zzz> ou talvez, só mais uma discussão com aquele pessoal resolva 20:39:09 <str4d> Agora, vou retirar do Gantt as tarefas que concluímos. 20:39:27 <zzz> você pode salvar e começar um novo? 20:39:29 <str4d> zzz: quais dos últimos lá embaixo foram concluídos (detecção de replay de SSU etc.)? 20:39:38 <str4d> Claro, posso. 20:39:49 <zzz> é meio legal mostrar que realmente realizamos coisas 20:40:19 <eche|on> zzz: a maioria das coisas foi feita por você IMHO 20:40:35 <EinMByte> eu perdi a reunião? 20:40:37 <zzz> Acho que relatei tudo que estava do lado errado de concluído ou não 20:42:39 <str4d> Novo gráfico no ar 20:43:55 <str4d> zzz: quais dos três lá embaixo devem ser empurrados adiante? Acho que o bloqueio do cliente ainda é um problema? 20:43:59 <zzz> Eu gostaria de ver muito mais planejamento e foco nas coisas sem codificação nos próximos meses. Muitas coisas estão bastante desorganizadas ou não acontecendo em nada que se aproxime de um ritmo disciplinado ou constante 20:44:09 <str4d> (bloqueio de client tunnel) 20:44:18 <str4d> zzz: concordo. 20:44:34 <str4d> Isso, na minha opinião, será ajudado ao trabalharmos na página de tarefas. 20:44:56 <str4d> Se conseguirmos explicar os projetos sem codificação de uma forma que os recém-chegados possam entender e fazer, isso também nos ajuda. 20:44:59 <zzz> não tenho 100% de certeza agora sobre o que é esse item de bloqueio do cliente, mas acho que ainda está inacabado 20:45:08 <str4d> (Da mesma forma para projetos de codificação) 20:45:32 <zzz> isso aí 20:45:53 * str4d empurra as melhorias de streaming adiante também 20:46:03 <str4d> Posso cortar a detecção de replay de sessão SSU então? 20:46:04 <dg> Você quer dizer os problemas de duplicação? 20:46:18 <dg> O jeito em que recebíamos tunnels que não se descadastram do I2PTunnel e não permitem novos? Esse tipo de coisa? 20:46:30 <zzz> str4d, vou ter que te responder depois sobre SSU replay, não sei agora 20:46:45 <dg> Eu gostaria de ver menos morte de tunnel em vez de vazão 20:46:59 <str4d> dg: pode ser isso. Há também o problema separado de a inicialização do I2PTunnel travar a UI 20:47:29 <zzz> coloque “tunnel death” lá como um novo item, por que não 20:48:01 <dg> str4d: Tinha esquecido disso! 20:48:03 <str4d> k 20:48:39 <zzz> acho que essa coisa do bloqueio eu tenho algo sem marcar no código para isso, vem se arrastando há uns 18 meses, mas ainda não está certo 20:48:40 <str4d> Próximo: olhar as ideias acima. Quais devem ir na nossa planilha de 6 meses (isto é, quais devo adicionar ao Gantt)? 20:50:16 <psi> EinMByte: reunião em andamento 20:50:21 <psi> (não) 20:51:51 <zzz> Sugiro colocar tudo lá por enquanto, depois falamos de prioridades, ou deixamos as dependências do Gantt nos dizerem o que fazer a seguir? 20:52:52 <str4d> mmk 20:53:04 * str4d está extraindo a lista acima e arrumando agora 20:53:08 <EinMByte> psi: ah, ótimo. 20:54:08 <psi> item potencial: fazer benchmark da vazão de tunnel e das taxas de descarte de mensagens 20:54:26 <str4d> EinMByte: você tem alguma ideia para nossa lista de tarefas? 20:55:15 <EinMByte> NTCP2, possivelmente. Embora fosse de longo prazo 20:56:39 <str4d> EinMByte: para referência: http://trac.i2p2.i2p/wiki/Roadmaps/1.0 20:56:53 <EinMByte> obrigado 20:57:04 <EinMByte> (ia perguntar) 21:00:23 <str4d> Aqui está a lista das ideias de todos: 21:00:24 <str4d> http://pastethis.i2p/show/K0fGRb2708ADbCTZ9u9K/ 21:00:25 <iRelay> Título: Paste #K0fGRb2708ADbCTZ9u9K | LodgeIt! (em pastethis.i2p) 21:01:01 <str4d> Quase todas estas podem ser transformadas em projetos para a página de tarefas do site. 21:01:36 <str4d> Próximo tópico de discussão: quais destas (e as que estão no Gantt atualmente) são mais importantes para fazermos nos próximos seis meses? 21:02:48 <psi> rotas restritas é provavelmente o item mais importante na minha opinião 21:02:50 <EinMByte> com respeito ao syndie, talvez: eu estava trabalhando neste plugin - sem tempo agora, porém). Isto pode ser uma das coisas que podem (?) trazer mais atenção ao syndie. 21:03:20 <dg> str4d: Tunnel death está ausente e acho isso bastante importante 21:03:37 <EinMByte> Se alguém estiver interessado em desenvolver plugins para firefox / icedove: vocês sabem o que fazer 21:03:37 <str4d> dg: está lá (bloqueio de thread de tunnel) 21:03:41 <str4d> Achei que era isso 21:03:49 <dg> ah, desculpa str4d, eu quis dizer quando conexões são abruptamente terminadas 21:03:54 <dg> minha culpa 21:04:04 <str4d> Ah, ok 21:04:55 <EinMByte> psi: concordo que rotas restritas são importantes. Mas também acho que devemos perceber que vai levar bastante tempo para implementar 21:05:21 <EinMByte> (não tenho certeza de quanto do design/conceito foi feito) 21:05:35 <dg> No I2P: rotas restritas, problemas de ECDSA no RedHat, HS 2.0 do Tor, depois o resto. Ao redor do I2P: base de usuários do Vuze, GSoC, pesquisa, benchmark, depois o resto. 21:06:04 <dg> Concordo com EinMByte.. o redesign da router console é importante, mas isso pode levar um tempo indeterminado. 21:07:15 <EinMByte> str4d: mais uma coisa, possivelmente. Conheço alguns pesquisadores que desenvolveram um novo conceito para um DWSE (distributed web search engine, motor de busca web distribuído), eles podem estar interessados em desenvolver isso como uma aplicação do I2P 21:07:42 <str4d> EinMByte: legal! 21:07:49 <EinMByte> Já que a maioria dos DWSEs agora não funciona muito bem, seria muito interessante ter isso, na minha opinião 21:08:01 <zzz> não, por “tunnel death” eu quis dizer quebra de tunnel de 3 minutos, o teste de datagrama do cara do Vuze, etc. Distinto de problemas locais de bloqueio do i2ptunnel. 21:08:07 <EinMByte> Também é algo que eu consideraria implementar 21:08:20 <dg> Eu não estava pensando precisamente em 3 minutos, mas isso estava incluído. 21:08:34 <EinMByte> (com ajuda, de preferência) 21:09:03 <str4d> ok, recarreguem a página do Gantt 21:10:34 <EinMByte> str4d: de qualquer modo, não conte muito com isso, depende de os usuários do I2P realmente se interessarem por algo assim. 21:11:14 <EinMByte> Além disso, não tenho certeza sobre as coisas de GNS. Em qualquer caso, não deveria ter alta prioridade. 21:11:56 <str4d> Paste de novas ideias atualizado: http://pastethis.i2p/show/1qxHbkWjD27N7SdzNJZL/ 21:11:57 <iRelay> Título: Paste #1qxHbkWjD27N7SdzNJZL | LodgeIt! (em pastethis.i2p) 21:12:35 <zzz> eu diria que 4 categorias amplas são de maior importância: 1) continuação da migração cripto de curto prazo (livro de endereços, muiltidest, etc.) 2) planejamento/pesquisa cripto de longo prazo (DH, LS2, NTCP2) 3) tudo de testes 4) tudo de não-codificação 21:13:48 <EinMByte> zzz: está em ordem de importância? 21:14:05 <str4d> Os problemas de ECDSA entram na primeira categoria; o HS 2.0 do Tor entra na segunda categoria. 21:14:21 <zzz> não. importância aproximadamente igual 21:14:44 <str4d> Então o único item não representado nessas categorias é rotas restritas 21:15:28 <jenkins@kyirc> Iniciando build #556 para o job i2pd (build anterior: SUCESSO) 21:15:30 <jenkins@kyirc> Projeto i2pd build #556: SUCESSO em 8.2 s: http://jenkins.killyourtv.i2p/job/i2pd/556/ 21:15:31 <jenkins@kyirc> * orignal: eliminated NTCPServerConnection 21:15:32 <jenkins@kyirc> * orignal: moved NTCP client code to Transports 21:16:34 <EinMByte> talvez NTCP2 não seja tão importante assim 21:16:50 <zzz> e a razão de eu tê-las agrupado assim e dizer prioridade igual é que provavelmente são 4 grupos separados de pessoas para essas 4 categorias que poderiam progredir 21:17:08 <EinMByte> ou, pelo menos antes de podermos começar propriamente com o NTCP2, precisamos fazer muita pesquisa, além de responder algumas questões muito importantes 21:17:33 <jenkins@kyirc> Projeto i2pd (Linux x86) build #33: SUCESSO em 1 min 47 s: http://jenkins.killyourtv.i2p/job/i2pd%20(Linux%20x86)/33/ 21:17:44 <EinMByte> zzz: de fato 21:17:51 <JekabsR> é interessante que a rede i2p tende a juntar todos os routers rápidos 21:17:58 <jenkins@kyirc> Iniciando build #33 para o job i2pd (Linux x64) 21:18:03 <zzz> certo. “NTCP2” é só uma abreviação para um monte de coisas que podem ou não realmente resultar em algo chamado “NTCP2” 21:18:34 <JekabsR> e eles não preferem routers lentos 21:18:40 <EinMByte> Sim. Em qualquer caso, se mudarmos as camadas de transporte, é extremamente importante não cometer erros, pois isso provavelmente quebraria o I2P por completo. 21:19:19 <psi> JekabsR: routers mais lentos ainda são usados, só não tanto 21:19:43 <jenkins@kyirc> Projeto i2pd (Linux x64) build #33: SUCESSO em 1 min 52 s: http://jenkins.killyourtv.i2p/job/i2pd%20(Linux%20x64)/33/ 21:20:05 <EinMByte> zzz: se 2 é “pesquisa”, então você está certo 21:20:33 <EinMByte> pode ser feito simultaneamente 21:21:52 * str4d está refazendo o Gantt nessas quatro categorias (mais uma categoria Outros) 21:22:12 <JekabsR> mas há um problema — destinos do tipo cliente raramente obtêm conexões de router rápidas 21:22:40 <eche|on> não? 21:22:46 <psi> JekabsR: não tenho certeza se isso é preciso 21:23:46 <zzz> str4d, esquecemos do Android, ou isso é um roadmap separado? 21:23:59 <str4d> zzz: esquecemos 21:24:01 <eche|on> JekabsR: routers em modo escondido têm alguns problemas, mas outros conseguem conexões rápidas, pois há routers rápidos suficientes disponíveis e com capacidade livre 21:24:26 <str4d> Tecnicamente, I2P Android entra na categoria “no I2P” 21:24:35 <psi> ah, outra pergunta de pesquisa: quanta capacidade o i2p realmente tem agora? 21:25:14 <zzz> talvez uma 5ª categoria para Android faça mais sentido 21:25:46 <zzz> mas não estou preso a categorias. Só mencionei as 4 como uma forma rápida de comunicar o que acho importante 21:25:54 <JekabsR> porque tendem a criar um pequeno número de conexões realmente rápidas e um grande número de conexões lentas 21:26:11 <dg> [citação necessária] 21:26:15 <JekabsR> meu router começou a derrubar tunnels lentos 21:26:24 <str4d> zzz: acho que foi uma boa ideia 21:26:56 <str4d> Atualizem a página do Gantt agora 21:27:07 <eche|on> JekabsR: https://geti2p.net/_static/pdf/I2P-PET-CON-2009.1.pdf 21:30:12 <eche|on> JekabsR: tunnels são derrubados apenas no fim do tempo de vida do tunnel e se os próprios tunnels precisarem da capacidade. 21:30:29 <str4d> Se você recarregar http://trac.i2p2.i2p/wiki/Roadmaps/1.0 agora verá os títulos, cada um com uma barra de seis meses. Isso dá uma indicação de quanto tempo há para encaixar tudo. 21:32:43 <str4d> Agora que temos algumas ideias para os próximos seis meses, precisamos começar a planejar prazos. 21:33:18 <str4d> E quem vai pegar o quê. 21:33:52 <JekabsR> meu console frequentemente relata que tem conexões de entrada demais e tunnels são parcialmente rejeitados. Como o i2p decide qual rejeitar? 21:34:08 <dg> ‘conexões de entrada demais’? 21:34:21 <dg> JekabsR: uma reunião está em andamento, você pode querer esperar até terminar 21:35:00 <str4d> Também gostaria de alguns voluntários para ajudar a transformar a lista de ideias em uma página de projetos funcional na página de tarefas do site 21:35:12 <JekabsR> Conexões NTCP: 425. Limite: 425. Tempo limite: 2 min. 21:35:30 <JekabsR> Conexões UDP: 1149. Limite: 1275. Tempo limite: 4 min. 21:36:14 <JekabsR> os limites estão sendo atingidos 21:37:42 <JekabsR> o router está usando 80% da CPU 21:38:23 <str4d> Alguém? 21:39:36 <kytv> JekabsR: 1) reunião em andamento, você pode querer esperar; 2) dê uma olhada em http://127.0.0.1:7657/peers#help 21:41:16 <JekabsR> kytv: vou ver 21:41:44 <zzz> str4d, acho que você perdeu todo mundo depois de uma hora e 45. Talvez declarar vitória por agora e avançamos mais em outro momento? 21:41:45 <str4d> Vamos tentar algumas perguntas mais específicas. 21:41:52 <str4d> Ou isso./ 21:41:55 <JekabsR> 330,0 / 342,4 KBps minha carga atual 21:42:06 <str4d> Sim, definitivamente fizemos um bom progresso. 21:42:30 <JekabsR> e uploads de torrent a 2 - 5kb de velocidade :( 21:44:17 <str4d> Obrigado pelas discussões, pessoal! 21:44:20 * str4d aquece o baffer 21:44:20 * str4d ***bafs a reunião encerrada