Reunião de desenvolvedores do I2P - 04 de março de 2016

15:00:05 <zzz> 0) oi 15:00:23 <zzz> 1) estrutura para estas reuniões 15:00:32 <zzz> 2) discussão do roadmap 15:00:37 <zzz> 0) oi 15:00:41 <zzz> oi 15:00:54 <str4d> oi 15:01:02 <xcps_> oi! 15:01:27 <orignal_> e aí? 15:02:18 <zzz> por favor, revisem o tópico em http://zzz.i2p/topics/2021 e o roadmap atual em http://i2p-projekt.i2p/en/get-involved/roadmap 15:02:27 <zzz> 1) estrutura para estas reuniões 15:03:22 <zzz> devemos ir direto ao roadmap ou falar primeiro sobre prioridades de alto nível? 15:03:53 <str4d> Eu começaria pela segunda 15:04:41 <zzz> ok, então no tópico, eu sugeri duas prioridades — crescer a rede e aumentar a segurança 15:04:55 <zzz> como soam essas como princípios de alto nível? 15:05:25 <zzz> vamos primeiro decidir o que é importante 15:05:32 <EinMByte> Soam como esperado, acho 15:05:48 <EinMByte> “crescer a rede” deve ser no sentido amplo, no entanto 15:05:57 <str4d> Acho que são ótimos como temas amplos 15:06:03 <zzz> anonimal sugeriu um monte a mais no tópico, mas não era bem o que eu queria 15:06:13 <xcps_> aumentar a segurança deveria ser sempre o mais importante, na minha opinião 15:06:28 <zzz> outros princípios que devemos considerar ao revisar o roadmap? 15:06:28 <str4d> O que, na minha opinião, precisamos fazer aqui é entender o que isso realmente significa em termos de possíveis entregáveis 15:06:40 <EinMByte> Então “crescer a rede” também deveria significar “aumentar a atenção da pesquisa” 15:07:00 <zzz> crescer a rede significa uma enorme variedade de coisas — veja o tópico 15:07:09 <str4d> EinMByte, sim, acho que mencionei isso no tópico 15:07:36 <zzz> vamos descobrir o que isso significa em breve. neste momento, vamos concordar sobre o que é importante. 15:07:58 <str4d> Usabilidade é muito importante para mim e, na minha opinião, alimenta as duas áreas acima 15:07:58 <zzz> tudo é possível se continuarmos crescendo. assim que pararmos de crescer, estamos mortos 15:08:05 <zzz> concordo, str4d 15:08:41 <str4d> Mais imediatamente no sentido de aumentar nossa base de usuários, e mais a longo prazo no sentido de aumentar nossa exposição pública, facilidade de uso por pesquisadores etc. 15:09:11 <EinMByte> Observe também que crescer é a única maneira de atrair pesquisadores 15:09:25 <zzz> mais usuários trazem mais devs e mais pesquisadores e mais conteúdo e e e 15:09:37 <EinMByte> Redes grandes são geralmente mais interessantes de estudar 15:10:05 <EinMByte> Então acho que todos podemos concordar nessas 2 prioridades 15:10:16 <zzz> a maior parte do nosso crescimento no último ano veio do Vuze. O que é ótimo, mas eu adoraria ter mais crescimento 'nativo' também 15:10:43 <zzz> mas talvez crescimento em apps embarcados, ou focar em aplicações em geral, seja o caminho mais fácil para crescer 15:10:48 <str4d> Sim 15:11:04 <EinMByte> zzz: Para muita gente, é mais fácil usar um aplicativo que execute o I2P em segundo plano e cuide da configuração por eles 15:11:12 <sadie> oi — um pouco atrasada para a festa 15:11:20 <zzz> oi, sadie, que bom que você veio 15:11:23 <str4d> Isso, na minha opinião, virá de melhorias de usabilidade tanto na UI quanto nas APIs 15:11:42 <str4d> Na parte de APIs, já estamos trabalhando em vários tópicos 15:11:48 <zzz> de certa forma, são os apps que são especialistas em UI, deixe-os empacotar o i2p e expô-lo (ou escondê-lo) como acharem melhor 15:11:58 <str4d> Mmm 15:12:08 <EinMByte> str4d: Essa é uma solução diferente para o mesmo problema, sim. E eu gosto mais porque empacotar o I2P com tudo não escala, na minha opinião 15:12:30 <str4d> Esse é mais ou menos o caminho que eu estava seguindo no Android 15:13:04 <EinMByte> Precisa haver uma forma de garantir que as pessoas não tenham uma instância do I2P para cada aplicativo 15:13:12 <zzz> ok, mais algo em 1) ou devemos passar a olhar o próprio roadmap? 15:14:00 <str4d> Acho que todos aqui parecem estar em um acordo geral 15:14:08 <str4d> (pelo menos sem discordâncias :P) 15:14:14 <zzz> deixa eu copiar as linhas do tópico. Não como dogma, só como referência 15:14:25 <zzz> Crescer a Rede 15:14:25 <zzz> Inclui: Marketing, projetos conjuntos, empacotar mais coisas, ajudar outros a empacotar o i2p, usabilidade, melhorias no site, mais traduções, palestras e apresentações, artigos e relatos, UI, Android, apps Android, melhor evasão do GFW, orchid, mais libs e ferramentas para devs de cliente, melhor suporte para sites gigantes, apoiar dev alternativo de router, alianças, acelerações e eficiência, capacidade, aumento de limites, entrar no 15:14:25 <zzz> Debian, ... 15:14:25 <zzz> Aumentar a segurança 15:14:25 <zzz> Inclui: migração cripto, protocolo de assinatura, novos protocolos de transporte, transports plugáveis, LS2, NTCP2, novo DH, revogação de chaves, armazenamento de chaves, revisão de código, Sybil, correção de bugs, naming, SSL, ... 15:14:46 <zzz> ok, vamos para 2) o roadmap em si 15:15:10 <zzz> a url é http://i2p-projekt.i2p/en/get-involved/roadmap 15:15:50 <zzz> .25 está praticamente pronto, lançamento em cerca de 10 dias, então vamos olhar os próximos 4 releases 26-29 para este ano 15:16:00 <zzz> o que deve nos levar até o ccc 15:16:15 <EinMByte> Se algo está sob 2017, por exemplo, isso significa que só vamos olhar para isso então, ou significa que começamos a implementação naquele ponto? 15:16:41 <str4d> Em termos do que precisamos fazer, eu colocaria a migração cripto e o trabalho em Sybil como de alta prioridade 15:16:42 <zzz> 1mb, certamente queremos começar agora as coisas grandes de 2017, como nova cripto/DH, NTCP2, etc 15:17:04 <EinMByte> Além disso, ataques Eclipse são um problema agora, na minha opinião 15:17:05 <zzz> então o roadmap poderia incluir trabalho preparatório para isso 15:17:23 <str4d> EinMByte, sim, eu estava incluindo isso sob Sybil 15:17:36 <EinMByte> A ideia de rotação à meia-noite não funciona e deve haver alternativas melhores, suponho 15:17:52 <zzz> concordo 15:18:05 <EinMByte> str4d: Claro, é razoável classificá-los como o mesmo tipo de ataque 15:18:44 <str4d> EinMByte, discuti isso com algumas pessoas na RWC 15:18:48 <str4d> Tenho algumas ideias, mas é difícil discutir aqui 15:18:51 <EinMByte> zzz: Então, se quisermos começar com NTCP2/... até 2017, vamos precisar planejar trabalho preliminar 15:18:58 <zzz> certo, 1mb 15:19:02 <str4d> Sim 15:19:20 <str4d> Quero ter planejamento e pesquisa no roadmap :) 15:19:28 <zzz> aqui está o problema. Eu deveria estar trabalhando na 26 agora e não sei o que tem dentro 15:19:39 <orignal_> é possível adicionar padding aleatório ao NTCP existente? 15:20:01 <str4d> orignal_, não que eu me lembre, mas confira o tópico de NTCP2 15:20:02 <zzz> então vamos gastar 10 minutos planejando a 26, depois podemos ir para o longo prazo 15:20:13 <str4d> ok 15:20:14 <zzz> me digam o que eu deveria estar fazendo hoje 15:20:30 <EinMByte> Verdade, vamos focar nisso primeiro 15:20:34 <zzz> ok, vamos ver o que está na lista da 25 que não aconteceu 15:20:50 <zzz> wrapper não aconteceu, kytv está AWOL 15:20:54 <EinMByte> “melhorias de cripto” é bem amplo 15:21:12 <zzz> o que realmente aconteceu em melhorias de cripto foram algumas acelerações no 25519 15:21:34 <zzz> então a lista da .25 na verdade está toda lá, exceto o wrapper 15:22:00 <zzz> mas há mais a fazer em Sybil, então vamos manter isso na lista da 26 15:22:08 <str4d> Ótimo 15:22:25 <str4d> Empurramos o GMP 6 para a .26 por causa da necessidade de mais testes 15:22:35 <zzz> o que mais na lista da 26 agora deveria estar lá ou ser movido 15:23:05 <EinMByte> Eventualmente, prevenir Sybil provavelmente será muito trabalho, então me parece algo de longo prazo 15:23:10 <EinMByte> (no sentido de que precisamos primeiro de uma boa revisão da literatura) 15:23:15 <zzz> orignal, sim, NTCP com padding é NTCP2 15:23:21 <str4d> EinMByte, a ferramenta de detecção de Sybil ainda não é usada para nada, é aí que é necessário mais planejamento :) 15:23:49 <zzz> hottuna4 está indisponível por um mês, não tenho certeza de quando esse mês termina, então gmp6 pode ou não entrar na 26 15:24:02 <str4d> Ok 15:24:37 <str4d> Melhorias no protocolo de assinatura para o livro de endereços: isso seria muito bom de adicionar o quanto antes, para que proprietários de Dest antigos possam migrar para Ed25519 15:24:37 <EinMByte> Acho que CRLs realmente não precisam de um ponto de interrogação 15:24:47 <str4d> Mas quanto tempo isso realmente levará para fazer? 15:25:14 <zzz> vamos precisar de uma atualização de status do tuna em breve; espero que o prazo para aprontar coisas grandes para a 26 seja final de março / primeira semana de abril 15:26:10 * str4d ainda não entende muito bem a coisa de CRL, zzz poderia detalhar? 15:26:14 <zzz> 25 terá a habilidade de ler crls do disco, então podemos incluir na atualização 15:26:35 <zzz> mas isso não ajuda tanto porque em uma atualização podemos simplesmente remover o cert e isso faz a mesma coisa 15:26:56 <zzz> então, para distribuir crls para as pessoas sem precisar fazer uma atualização, nós as colocaríamos no feed 15:26:57 <str4d> Só estou tentando entender o caso de uso 15:27:09 <zzz> o caso de uso é alguém ser comprometido 15:27:20 <str4d> Ainda não fazemos cert pinning? 15:27:30 <zzz> não 15:27:56 <zzz> então eu já fiz 90% disso e só preciso colocar a crl no namespace 15:28:46 <zzz> pinning é complicado e perigoso 15:29:05 <zzz> o crypto cat fez o 'pinning suicide' 15:29:17 <zzz> onde eles estavam com pinning, mas um intermediário mudou 15:30:49 <zzz> não acho que pinning substitua cls 15:30:51 <zzz> crls 15:31:21 <zzz> crls não são só para ssl, tem as chaves de reseed e de update 15:31:58 <zzz> podemos manter crls na lista para a 26 então? está quase pronto 15:32:20 <str4d> O que me preocupa em relação a pinning é que alguém poderia fazer, por exemplo, algo tipo Quantum Insert para redirecionar um nome de domínio de reseed e simplesmente colocar qualquer cert SSL válido que satisfaça o requisito do nome de domínio, e os routers vão aceitar 15:33:05 <str4d> E sobre CRLs, se usarmos isso para desabilitar um certificado específico, por que certificado ele é substituído? 15:33:25 <zzz> nada. no próximo release presumivelmente haveria um substituto 15:33:45 <str4d> Isso está entrando um pouco demais nos detalhes 15:34:07 <str4d> Acho que o que eu queria dizer é que precisamos pensar mais um pouco sobre isso 15:34:24 <zzz> ok, então vamos manter crls para a 26, mas vamos discutir os detalhes disso na próxima semana ou duas 15:34:30 <zzz> já que não está 100% claro 15:34:38 <zzz> seguindo 15:34:42 <zzz> o que mais na lista da 26 15:34:43 <str4d> ok 15:34:50 <EinMByte> ok 15:35:08 <zzz> protocolo de assinatura 15:35:28 <zzz> isso é a chave para a migração cripto dos sites 15:35:40 <EinMByte> substituto do hosts.txt ou o que você quer dizer? 15:36:22 <zzz> sim, isto é o hosts.txt como um feed, com algo como foo.i2p=b64#sig=b64#cmd=alt ... 15:36:26 <str4d> EinMByte, emendar o protocolo de assinatura do livro de endereços com metadados de chave-valor assinados 15:36:49 <zzz> a proposta está bem definida, mas em pausa há uns 18 meses 15:37:07 <EinMByte> Certo, embora o tamanho do arquivo hosts não ficaria grande demais 15:38:02 <EinMByte> Talvez adicionar um parâmetro since, para excluir todos os hosts inseridos antes de um determinado momento 15:38:07 <EinMByte> (para evitar baixar a lista inteira mesmo quando não for necessário) 15:38:22 <zzz> isso originalmente fazia parte do plano de migração cripto, mas era difícil e não era a parte mais importante 15:38:49 <zzz> mas é a principal coisa restante na migração cripto de assinaturas 15:39:26 <str4d> EinMByte, meio que já temos isso com etag 15:39:28 <zzz> isso é mais uma daquelas coisas propostas com muitos detalhes, mas ainda não houve acordo e, portanto, não começou 15:39:42 <EinMByte> str4d: Mas é usado? 15:39:46 <str4d> EinMByte, sim 15:40:00 <EinMByte> Ah, deixa pra lá. nesse caso 15:40:03 <str4d> Isso não seria diferente da configuração atual 15:40:20 <zzz> então ficará na lista da 26 e vamos começar nisso o quanto antes. não sei se conseguiremos avançar o suficiente para a 26, mas vou tentar. precisamos revisar o tópico no zzz.i2p 15:40:22 <str4d> mas, em vez dos registros de nomes de domínio nunca se repetirem, agora eles se repetiriam no “stream” 15:40:42 <EinMByte> Há alguma razão específica para precisarmos manter o formato estranho, porém? 15:41:05 <EinMByte> Me pareceria mais fácil se simplesmente usássemos algo padrão 15:41:06 <zzz> talvez. compatibilidade com clientes antigos. mas devemos revisar e decidir com certeza se isso é importante 15:41:20 <zzz> nenhum de nós olhou para isso em talvez um ano 15:41:28 <zzz> então vamos tirar o pó e dar uma olhada 15:41:32 <EinMByte> zzz: A compatibilidade poderia ser tratada também fornecendo o arquivo hosts.txt antigo por um tempo 15:41:41 <str4d> Há também a questão mais ampla do que fazer com, por exemplo, todos os nomes “perdidos” 15:41:53 <str4d> Mas isso está fora da discussão atual 15:41:57 <zzz> sim. também precisaríamos envolver as outras impls 15:42:18 <EinMByte> str4d: Acho que isso é algo para decidir quando tivermos um novo sistema de naming (se um dia tivermos) 15:42:26 <str4d> Por enquanto, quero alguma forma para domínios atualmente ativos atualizarem seus dests 15:42:26 <zzz> ok, fica na lista da 26 por enquanto. próximo na lista — coisas de Sybil 15:42:45 <zzz> podemos fazer Sybil ser automático? Espero que todos tenham lido o artigo do Philip Winter???? 15:42:50 <str4d> E quanto antes colocarmos o código central, mais cedo poderemos ligá-lo em cerca de um ano 15:43:50 <EinMByte> zzz: Que artigo? Claramente perdi algo 15:44:27 <zzz> confira @__phw no Twitter para o link 15:45:02 <zzz> estamos trabalhando com ele graças a uma apresentação da sadie no ccc 15:45:03 <EinMByte> zzz: este: http://arxiv.org/pdf/1602.07787v1.pdf? 15:45:27 <zzz> se foi publicado nas últimas duas semanas, é esse 15:45:59 <EinMByte> Bem, é um eprint de fevereiro deste ano 15:46:09 <zzz> não acho que estejamos prontos para automático. eles também não, na verdade 15:46:22 <zzz> eles só cuspem um e-mail uma vez por dia para os dirauths 15:46:36 <zzz> é tudo heurística e mágica dos dois lados 15:46:49 <EinMByte> Então ele provavelmente colocou o eprint online depois que foi publicado 15:46:57 <zzz> então eu gostaria de empurrar as coisas automáticas para mais tarde no ano 15:47:07 <str4d> EinMByte, 25 de fev é a versão que eu tenho 15:47:14 <EinMByte> zzz: Então como exatamente isso funcionaria em um cenário descentralizado? 15:47:44 <str4d> Precisamos fazer as coisas de baixo pra cima em vez de cima pra baixo 15:48:06 <str4d> ou seja, cada router precisaria incluir “potenciais candidatos a Sybil” nos perfis de pares 15:48:13 <zzz> EinMByte, não sei. é difícil 15:48:20 <str4d> com base, por exemplo, em tempos online etc. 15:48:30 <EinMByte> Detectar ataques Sybil é factível, acho; preveni-los com base nessa detecção é muito difícil em uma rede descentralizada 15:48:30 <EinMByte> Mas eu gosto do desafio 15:48:34 <zzz> também precisamos do gravy que está trabalhando em um refazer centralizado do setup dele 15:48:43 <str4d> Há também a possibilidade de ter algum tipo de setup mais centralizado 15:48:45 <str4d> Sim, isso 15:48:45 <EinMByte> str4d: Nesse ponto você precisa começar a atribuir confiança a cada router 15:48:52 <EinMByte> o que por si só seria um sistema anti-Sybil inteiro 15:49:07 <str4d> E fazer os routers assinarem uma lista de potenciais sybils 15:49:07 <zzz> meio como as propostas do dagon 15:49:09 <str4d> EinMByte, isso é basicamente o que os perfis de pares são agora, porém 15:49:31 <str4d> onde “confiança” é atualmente definida como “roteou de forma confiável para mim no passado” 15:49:42 <EinMByte> str4d: Sim, e eles causaram alguns ataques até agora :) 15:50:15 <str4d> Sim 15:50:23 <EinMByte> Além disso, perfis de pares não permitem realmente que você exclua um par da rede 15:50:31 <EinMByte> A prevenção de Sybil permitiria isso, de certa forma 15:50:35 <str4d> Perfilamento de pares e seleção de pares é outra das coisas que acho que precisa de priorização 15:50:46 <str4d> Eles podem, sim 15:51:01 <zzz> então proponho mudar o item de Sybil da 26 para 'melhoria contínua', mas mover a parte 'automática' para mais tarde 15:51:01 <str4d> Agora não 15:51:11 <str4d> Só estou dizendo que é onde colocaríamos isso 15:51:34 <EinMByte> str4d: Sim, isso é possível. 15:51:37 <str4d> (no sentido de colocar detecção de Sybil e técnicas mais avançadas no léxico e na arquitetura do I2P) 15:51:53 <EinMByte> De qualquer forma, eu não abriria mão da descentralização. É a parte mais legal do I2P, na minha opinião 15:52:14 <str4d> Sim 15:52:27 <EinMByte> (e centralização também leva a vários ataques práticos de qualquer forma) 15:52:43 <zzz> vamos seguir. melhorias no streaming? não sei bem o que é, talvez só o item perene de 'melhorar' 15:52:49 <str4d> zzz, sim, podemos continuar a trabalhar naquela página da routerconsole, e depois integrá-la com os perfis e a seleção de pares quando decidirmos uma estratégia 15:53:00 <zzz> não consigo pensar no que há para fazer especificamente em streaming. alguém? 15:53:01 <EinMByte> Às vezes, adicionar uma autoridade central pode tornar sua prova de segurança fácil, mas causar falhas de segurança na prática 15:53:20 <str4d> Pesquisa e otimizações seriam boas 15:53:28 <EinMByte> zzz: Alguma melhoria óbvia que poderíamos fazer ali? 15:53:30 <str4d> Isso seria um bom candidato para pesquisa externa 15:53:46 <zzz> realmente precisamos de um setup de testes melhor 15:53:51 <EinMByte> str4d: Concordo. 15:53:55 <zzz> adicionar atrasos / perdas, reordenar etc. 15:54:04 <EinMByte> Provavelmente deveríamos estender nossa página de “questões de pesquisa em aberto” com isso e outras coisas 15:54:40 <zzz> não tenho muitas ideias mirabolantes na minha lista de coisas de streaming. precisa ser guiado por resultados de testes 15:54:50 <EinMByte> Pode haver mais melhoria na alocação de tunnels? 15:55:05 <str4d> zzz, há algum projeto no GH que simula “A Internet” com containers que podem fazer isso, se bem me lembro 15:55:08 <zzz> então que tal tornar este item 'streaming test harness' 15:55:17 <str4d> Não sei o quão fácil seria, porém, precisaríamos de uma nova JVM por container :P 15:55:25 <str4d> EinMByte, mmm 15:55:48 <EinMByte> str4d: shadow poderia ser usado, acho. Não sei se poderia ser integrado com Java, mas está na lista TODO do kovri 15:55:52 <str4d> Isso não é realmente streaming, porém, isso é no nível de datagramas 15:56:22 <zzz> a coisa da alocação de tunnels é a ideia do psi de fazer o client escolher tunnels 15:56:34 <EinMByte> str4d: Sim, suspeito que há mais a otimizar nisso 15:56:46 <EinMByte> zzz: Não acho que usuários sejam os melhores algoritmos de otimização, mas talvez 15:57:10 <zzz> é uma corrupção violenta do nosso layering, e não vejo como fazer. mas é isso que o psi está propondo 15:57:19 <EinMByte> ... ou provavelmente “cliente” não significa usuário 15:57:32 <zzz> client == lado cliente do i2cp 15:57:44 <str4d> A questão aí é 15:57:54 <str4d> Tor fornece essa capacidade via o Control Socket deles 15:57:58 <EinMByte> Ok então significa isso 15:57:59 <str4d> E é muito útil para pesquisadores 15:58:10 <str4d> Mas eles também têm uma arquitetura muito mais plana 15:58:19 <str4d> Enquanto nós isolamos diferentes clientes uns dos outros via I2CP 15:58:31 <EinMByte> zzz: Eu esperaria que o router tivesse mais informações relevantes. O cliente poderia passar quaisquer requisitos adicionais 15:58:41 <zzz> também temos os lua hooks do psi para pesquisadores, que nunca foram mesclados (nem em Java nem no kovri), mas ainda é uma opção 15:59:14 <zzz> veja, agora o lado cliente nem sabe sobre tunnels, então certamente não tem nenhuma habilidade de escolhê-los 15:59:16 <str4d> Falando com o nickm na RWC, ele disse que era muito mais fácil para o Tor manter uma interface de Control Socket do que um sistema de plugins 15:59:17 <EinMByte> Sei que o shadow está sendo usado na prática por pesquisadores 15:59:22 <EinMByte> Lua, não sei 15:59:55 <EinMByte> zzz: Então provavelmente a mesma coisa pode ser alcançada passando as informações relevantes pelo I2CP? 16:00:17 <zzz> 1mb, sim, mas ficaria realmente muito feio 16:00:44 <str4d> Poderíamos sempre restringir isso com um flag -research ou algo assim 16:00:54 <str4d> (no router.config) 16:01:06 <str4d> Assim, a maioria dos usuários não fica exposta à feiura 16:01:13 <zzz> kovri/i2pd ainda não têm aquelas barreiras rígidas de API entre cliente/router, é mais fácil para os 16:01:20 <zzz> *eles 16:01:28 <str4d> E podemos definir “.research” desde o começo para significar “Reservamos o direito de mudar essas APIs” 16:01:44 <str4d> ou seja, pesquisadores precisariam usar o flag .research junto com uma versão específica 16:01:57 <str4d> Voltando ao tópico real da discussão: 16:01:59 <EinMByte> zzz: Sobre tunnels. Depende. Acho que faria sentido passar informações sobre o uso pretendido do tunnel. 16:02:20 <zzz> (Para sua informação, esta reunião vai por mais 25 minutos no máximo, a continuar no domingo) 16:02:33 <EinMByte> zzz: É mais fácil para nós principalmente porque o shadow é escrito em C, acho 16:02:42 <str4d> Acho que isso deveria ser empurrado para a categoria “precisa de mais pesquisa” 16:02:44 <zzz> o problema é que não são só os seus tunnels que precisam ser escolhidos, mas os tunnels da extremidade remota 16:02:48 <EinMByte> Ok. Vamos em frente então. 16:03:08 <zzz> ok, isso é tudo o que está na lista da 26 agora. O que deve ser adicionado? 16:03:11 <EinMByte> zzz: A extremidade remota não cuida disso? 16:03:36 <zzz> não, fazemos roteamento na origem (ou seja, escolhemos o lease da extremidade remota a partir do leaseset dela para o inbound dele) 16:04:08 <zzz> olhem a lista 27-29. o que deveria ser puxado para a 26, se algo? 16:04:44 <str4d> Quero começar a fazer o trabalho preparatório para novos LSs e o netdb 16:04:46 <zzz> é aqui que está todo o 'trabalho inicial em xxx para 2017', mas também muita coisa de 2016 16:05:23 <EinMByte> zzz: Entendi errado o que você quis dizer com far-end, deixa pra lá 16:05:31 <str4d> Quanto antes acertarmos isso e colocarmos na codebase, mais cedo a rede terá suporte amplo a isso 16:06:42 <EinMByte> Observe que nós (kovri) queremos especificações 16:06:52 <EinMByte> Caso contrário, será difícil acompanhar a implementação 16:07:31 <zzz> claro. qualquer coisa que seja uma nova especificação, precisamos todos trabalhar juntos 16:07:36 <EinMByte> str4d: Vamos começar listando o que o LS2 realmente deve suportar 16:07:53 <EinMByte> (se isso ainda não foi feito) 16:09:40 <zzz> basicamente, LS2 são só algumas coisas 16:09:59 <zzz> adicionar algum espaço para flags 16:10:09 <zzz> e habilitar cripto futura 16:10:52 <zzz> mas eu tenho todas aquelas propostas sobre multihoming melhor, além de busca de serviço ao estilo grothoff 16:11:00 <zzz> anycast 16:11:01 <EinMByte> Temos uma lista específica em algum lugar para referência? 16:11:11 <zzz> está reunido no zzz, um segundo 16:11:23 <str4d> EinMByte, Estou trabalhando aos poucos para reunir tudo isso no site 16:11:41 <zzz> podemos acelerar isso, str4d? tipo na próxima semana ou duas? 16:11:47 <str4d> Isso deveria entrar na lista da .26 16:11:50 <str4d> Hmm 16:11:53 <str4d> Possivelmente 16:11:59 <str4d> Preciso de mais olhos nisso 16:11:59 <zzz> sem as propostas em uma lista simples, isso é difícil demais 16:12:08 <EinMByte> str4d: Ótimo. Na verdade, para algumas dessas coisas, uma funcionalidade de wiki seria útil 16:12:24 <EinMByte> (a ideia é que isso aceleraria) 16:12:48 <zzz> para começar, precisamos de uma lista 16:12:50 <str4d> exatamente 16:12:56 <zzz> não vamos tentar abraçar o mundo aqui 16:13:11 <str4d> Estou tentando mover de exigir HTML no backend para (atualmente) rST 16:13:31 <str4d> Preciso que pessoas revisem o que tenho para verificar que a) é utilizável e b) não perde nada do que temos atualmente 16:13:39 <str4d> Atualmente está aplicado apenas à documentação de especificação 16:13:40 <zzz> vamos colocar essa coisa das propostas na lista para a 26 e falamos depois sobre o que isso significa. Mas precisamos avançar nisso o quanto antes. 16:13:55 <str4d> Mas no momento em que isso estiver solidificado, estender para propostas é trivial 16:13:56 <zzz> quero elas no site. não me importa em que forma. 16:14:46 <EinMByte> Estou disposto a revisar propostas, mas às vezes acontece de eu simplesmente não encontrar nenhum texto 16:15:10 <EinMByte> (algumas coisas no site estão meio escondidas, acho) 16:15:37 <zzz> certo 16:16:05 <zzz> precisamos mover coisas do zzz.i2p para o site com algum tipo de organização 16:16:13 <EinMByte> str4d: Mover de HTML para algo que possa ser facilmente convertido para vários formatos é uma coisa boa 16:16:28 <EinMByte> zzz: Sim, absolutamente 16:16:35 <str4d> EinMByte, o que eu preciso que revisem está em i2p.www.str4d 16:16:36 <EinMByte> Talvez um processo fixo para todas as propostas 16:16:57 <zzz> ok. está na lista para a 26. detalhes virão. str4d, mãos à obra. eu não esperaria muito feedback. Apenas crie um novo sistema e todos entraremos na linha 16:17:02 <str4d> e em http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/ 16:17:04 <str4d> EinMByte, se você quiser trabalhar comigo para acertar isso, eu poderia terminar talvez até a .25 16:17:23 <zzz> o que mais para a 26? precisamos encerrar isso 16:17:36 <str4d> ( EinMByte, http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/spec especificamente) 16:18:14 <zzz> isso é coisa de curtíssimo prazo. Preciso saber o que fazer na segunda 16:18:27 <zzz> última chamada para a 26 16:18:41 <str4d> Acho que a parte de assinaturas vai levar um tempo 16:18:49 <str4d> Então eu ficaria feliz com isso sendo a principal coisa 16:18:52 <zzz> concordo. 16:19:54 <zzz> ok. reunião no domingo no mesmo horário. vamos começar com VRP/H1. por favor, revisem o ticket 1119 com antecedência. depois disso, falaremos sobre 27-29, se o tempo permitir. 16:20:06 <EinMByte> str4d: Algum desses que você acha que requer mais atenção? 16:20:27 <zzz> podemos também voltar brevemente à 26 no domingo, se necessário 16:20:43 <str4d> EinMByte, basicamente decidir se o formato para escrever propostas é utilizável e se limita o que vai parar no site (em formato HTML ou TXT) 16:20:45 <zzz> então a agenda no domingo será 1) VRP/H1/1119; 2) 26; 3) 27-29 16:20:57 <zzz> obrigado, pessoal 16:21:25 * zzz *bafs* reunião encerrada 16:27:50 <EinMByte> str4d: Provavelmente está OK desde que possa ser convertido para a maioria dos outros formatos :)