Reunión de desarrolladores de I2P - 04 de marzo de 2016

15:00:05 <zzz> 0) hola 15:00:23 <zzz> 1) estructura para estas reuniones 15:00:32 <zzz> 2) discusión de la hoja de ruta 15:00:37 <zzz> 0) hola 15:00:41 <zzz> hola 15:00:54 <str4d> hola 15:01:02 <xcps_> ¡hola! 15:01:27 <orignal_> ¿qué tal? 15:02:18 <zzz> por favor revisen el hilo en http://zzz.i2p/topics/2021 y la hoja de ruta actual en http://i2p-projekt.i2p/en/get-involved/roadmap 15:02:27 <zzz> 1) estructura para estas reuniones 15:03:22 <zzz> ¿deberíamos ir directo a la hoja de ruta o hablar primero de las prioridades de alto nivel? 15:03:53 <str4d> Yo empezaría por lo segundo 15:04:41 <zzz> ok, en el hilo propuse dos prioridades: hacer crecer la red e incrementar la seguridad 15:04:55 <zzz> ¿qué tal suenan como principios de alto nivel? 15:05:25 <zzz> primero decidamos qué es importante 15:05:32 <EinMByte> Suenan como cabría esperar, creo 15:05:48 <EinMByte> aunque «hacer crecer la red» debería entenderse en sentido amplio 15:05:57 <str4d> Creo que son excelentes como temas generales 15:06:03 <zzz> anonimal propuso muchas más en el hilo, pero no era realmente lo que buscaba 15:06:13 <xcps_> aumentar la seguridad debería ser siempre lo más importante, en mi opinión 15:06:28 <zzz> ¿otros principios que debamos considerar al revisar la hoja de ruta? 15:06:28 <str4d> Lo que, en mi opinión, necesitamos hacer aquí es concretar qué significan en términos de posibles entregables 15:06:40 <EinMByte> Así que «hacer crecer la red» también debería significar «aumentar la atención de la investigación» 15:07:00 <zzz> hacer crecer la red implica un montón de cosas: vean el hilo 15:07:09 <str4d> EinMByte, sí, creo que mencioné eso en el hilo 15:07:36 <zzz> en breve definiremos qué significan. por ahora, pongámonos de acuerdo en qué es importante. 15:07:58 <str4d> La usabilidad es muy importante para mí y, en mi opinión, alimenta las dos áreas anteriores 15:07:58 <zzz> todo es posible si seguimos creciendo. en cuanto dejamos de crecer, estamos muertos 15:08:05 <zzz> de acuerdo, str4d 15:08:41 <str4d> Más inmediatamente en cuanto a aumentar nuestra base de usuarios, y a más largo plazo en cuanto a aumentar nuestra visibilidad pública, facilidad de uso para investigadores, etc. 15:09:11 <EinMByte> Nótese también que crecer es la única forma de atraer investigadores 15:09:25 <zzz> más usuarios traen más desarrolladores, más investigadores, más contenido y y y 15:09:37 <EinMByte> Las redes grandes generalmente son más interesantes de estudiar 15:10:05 <EinMByte> Así que creo que todos podemos estar de acuerdo en esas 2 prioridades 15:10:16 <zzz> la mayor parte de nuestro crecimiento en el último año ha venido de Vuze. Lo cual es genial, pero también me encantaría tener más crecimiento «nativo» 15:10:43 <zzz> pero quizá el crecimiento en apps integradas, o centrarse en aplicaciones en general, sea el camino más fácil al crecimiento 15:10:48 <str4d> Sí 15:11:04 <EinMByte> zzz: Para mucha gente, es más fácil usar una aplicación que ejecute I2P en segundo plano y se encargue de la configuración por ellos 15:11:12 <sadie> hola; llego un poco tarde a la fiesta 15:11:20 <zzz> hola, sadie; me alegra que hayas llegado 15:11:23 <str4d> Eso, en mi opinión, vendrá de mejoras de usabilidad tanto en la UI como en las APIs 15:11:42 <str4d> En esto último ya hemos estado trabajando en varios hilos 15:11:48 <zzz> en cierto modo, las apps son las expertas en UI; dejemos que empaqueten i2p y lo expongan (o lo oculten) como crean mejor 15:11:58 <str4d> Mmm 15:12:08 <EinMByte> str4d: Es una solución diferente al mismo problema, sí. Y me gusta más porque empaquetar I2P con todo no escala, en mi opinión 15:12:30 <str4d> Ese es más o menos el enfoque que estaba siguiendo con Android 15:13:04 <EinMByte> Tiene que haber una manera de asegurar que la gente no tenga una instancia de I2P por cada aplicación 15:13:12 <zzz> ok, ¿algo más sobre 1) o pasamos a ver la hoja de ruta en sí? 15:14:00 <str4d> Creo que todos aquí parecen estar básicamente de acuerdo 15:14:08 <str4d> (al menos, sin disenso :P) 15:14:14 <zzz> déjenme copiar las líneas del hilo. No como dogma, solo como referencia 15:14:25 <zzz> Hacer crecer la red 15:14:25 <zzz> Incluye: marketing, proyectos conjuntos, empaquetar más cosas, ayudar a otros a empaquetar i2p, usabilidad, mejoras del sitio web, más traducciones, charlas y presentaciones, artículos y relatos, UI, Android, apps de Android, mejor evasión del GFW, orchid, más bibliotecas y herramientas para desarrolladores de clientes, mejor soporte para sitios web enormes, apoyo al desarrollo de router alternativo, alianzas, aceleraciones y eficiencia, capacidad, aumento de límites, entrar en 15:14:25 <zzz> Debian, ... 15:14:25 <zzz> Incrementar la seguridad 15:14:25 <zzz> Incluye: migración criptográfica, protocolo de suscripción, nuevos protocolos de transporte, pluggable transports (transportes conectables), LS2, NTCP2, nuevo DH, revocación de claves, almacenamiento de claves, revisión de código, Sybil, correcciones de bugs, sistema de nombres, SSL, ... 15:14:46 <zzz> ok, pasemos a 2) la hoja de ruta en sí 15:15:10 <zzz> la url es http://i2p-projekt.i2p/en/get-involved/roadmap 15:15:50 <zzz> .25 está prácticamente listo; lanzamiento en unos 10 días, así que veamos las próximas 4 versiones 26-29 para este año 15:16:00 <zzz> que deberían llevarnos hasta ccc 15:16:15 <EinMByte> Si algo está bajo 2017, por ejemplo, ¿significa que empezamos a estudiarlo solo entonces, o que empezamos la implementación en ese momento? 15:16:41 <str4d> En cuanto a lo que debemos hacer, pondría la migración criptográfica y el trabajo sobre Sybil muy arriba 15:16:42 <zzz> 1mb, ciertamente queremos empezar ya con las cosas grandes de 2017, como criptografía/DH nuevos, ntcp2, etc 15:17:04 <EinMByte> Además, los ataques de eclipse son un problema ahora mismo, en mi opinión 15:17:05 <zzz> así que la hoja de ruta podría incluir trabajo preparatorio para eso 15:17:23 <str4d> EinMByte, sí, estaba metiendo eso dentro de Sybil 15:17:36 <EinMByte> La idea de rotación a medianoche no funciona y supongo que debería haber mejores alternativas 15:17:52 <zzz> de acuerdo 15:18:05 <EinMByte> str4d: Claro, es razonable clasificarlos como el mismo tipo de ataque 15:18:44 <str4d> EinMByte, hablé de esto con algunas personas en RWC 15:18:48 <str4d> Tengo algunas ideas, pero es difícil discutirlo aquí mismo 15:18:51 <EinMByte> zzz: Entonces, si queremos empezar con NTCP2/... para 2017, necesitaremos planificar trabajo preliminar 15:18:58 <zzz> correcto, 1mb 15:19:02 <str4d> Sí 15:19:20 <str4d> Quiero que haya planificación e investigación en la hoja de ruta :) 15:19:28 <zzz> aquí está el problema. Debería estar trabajando en la 26 ahora mismo y no sé qué lleva 15:19:39 <orignal_> ¿es posible añadir padding aleatorio al NTCP existente? 15:20:01 <str4d> orignal_, que yo recuerde no, pero revisa el hilo de NTCP2 15:20:02 <zzz> así que dediquemos 10 minutos a planear la 26, luego podemos pasar al largo plazo 15:20:13 <str4d> ok 15:20:14 <zzz> díganme qué debería estar haciendo hoy 15:20:30 <EinMByte> Cierto, centrémonos en eso primero 15:20:34 <zzz> ok, veamos qué hay en la lista de la 25 que no ocurrió 15:20:50 <zzz> el wrapper no ocurrió, kytv está desaparecido 15:20:54 <EinMByte> «mejoras criptográficas» es bastante amplio 15:21:12 <zzz> lo que realmente ocurrió en mejoras criptográficas fueron algunas aceleraciones de 25519 15:21:34 <zzz> así que la lista de la .25 en realidad está toda ahí salvo el wrapper 15:22:00 <zzz> pero hay más por hacer en Sybil, así que mantengámoslo en la lista de la 26 15:22:08 <str4d> Genial 15:22:25 <str4d> Movimos GMP 6 a la .26 por la necesidad de más pruebas 15:22:35 <zzz> ¿qué más de la lista de la 26 debería estar ahí o moverse? 15:23:05 <EinMByte> Prevenir Sybil probablemente será mucho trabajo, así que me parece algo a largo plazo 15:23:10 <EinMByte> (en el sentido de que primero necesitamos una buena revisión de la literatura) 15:23:15 <zzz> orignal, sí, NTCP con padding es NTCP2 15:23:21 <str4d> EinMByte, la herramienta de detección de Sybil aún no se usa para nada; ahí es donde hace falta más planificación :) 15:23:49 <zzz> hottuna4 no está disponible durante un mes; no sé cuándo termina ese mes, así que gmp6 puede que entre o no en la 26 15:24:02 <str4d> Ok 15:24:37 <str4d> Mejoras del protocolo de suscripción para la libreta de direcciones: sería muy bueno añadirlo cuanto antes, para que los propietarios de Dest antiguos puedan migrar a Ed25519 15:24:37 <EinMByte> Creo que las CRL realmente no necesitan signo de interrogación 15:24:47 <str4d> Pero ¿cuánto tiempo llevará realmente hacerlo? 15:25:14 <zzz> necesitaremos pronto alguna actualización de estado de tuna; espero que la fecha límite para apuntalar cosas grandes para la 26 sea a finales de marzo / primera semana de abril 15:26:10 * str4d todavía no entiende del todo lo de las CRL, ¿podría zzz ampliar? 15:26:14 <zzz> la 25 tendrá la capacidad de leer CRL desde disco, así que podemos incluirlo en la actualización 15:26:35 <zzz> pero eso no es tan útil porque en una actualización podemos simplemente quitar el certificado y hace lo mismo 15:26:56 <zzz> así que, para distribuir CRL a la gente sin tener que hacer una actualización, las pondríamos en el feed 15:26:57 <str4d> Solo intento entender el caso de uso 15:27:09 <zzz> el caso de uso es que alguien se ve comprometido 15:27:20 <str4d> ¿Seguimos sin hacer pinning de certificados? 15:27:30 <zzz> no 15:27:56 <zzz> así que ya hice el 90 % y solo necesito meter la CRL en el namespace 15:28:46 <zzz> el pinning es delicado y peligroso 15:29:05 <zzz> crypto cat hizo el «pinning suicide» 15:29:17 <zzz> donde estaban anclados pero un intermedio cambió 15:30:49 <zzz> no creo que el pinning reemplace a las cls 15:30:51 <zzz> crls 15:31:21 <zzz> las CRL no son solo para SSL; también están las claves de reseed y de actualización 15:31:58 <zzz> ¿podemos mantener las CRL en la lista para la 26 entonces? está casi hecho 15:32:20 <str4d> Lo que me preocupa respecto al pinning es que alguien podría hacer, por ejemplo, algo tipo Quantum Insert para redirigir un nombre de dominio de reseed, y simplemente poner cualquier certificado SSL válido que cumpla el requisito del nombre de dominio, y los routers lo aceptarían 15:33:05 <str4d> Y con respecto a las CRL, si usamos eso para deshabilitar un certificado concreto, ¿con qué se reemplaza ese certificado? 15:33:25 <zzz> con nada. en la siguiente versión presumiblemente habría un reemplazo 15:33:45 <str4d> Esto se está metiendo un poco en los detalles finos 15:34:07 <str4d> Creo que a lo que iba es que necesitamos pensarlo un poco más 15:34:24 <zzz> ok, mantengamos las CRL para la 26 pero discutamos los detalles en la próxima semana o dos 15:34:30 <zzz> ya que no está 100% claro 15:34:38 <zzz> sigamos 15:34:42 <zzz> ¿qué más hay en la lista de la 26 15:34:43 <str4d> mmk 15:34:50 <EinMByte> ok 15:35:08 <zzz> protocolo de suscripción 15:35:28 <zzz> esto es la clave para la migración criptográfica de sitios 15:35:40 <EinMByte> ¿reemplazo de hosts.txt o a qué te refieres? 15:36:22 <zzz> sí, esto es lo de hosts.txt como un feed, con algo como foo.i2p=b64#sig=b64#cmd=alt ... 15:36:26 <str4d> EinMByte, enmendar el protocolo de suscripción de la libreta de direcciones con metadatos clave-valor firmados 15:36:49 <zzz> la propuesta está bastante definida, pero en pausa desde hace unos 18 meses 15:37:07 <EinMByte> Claro, aunque ¿no crecería demasiado el tamaño del archivo hosts? 15:38:02 <EinMByte> Quizá añadir un parámetro since para excluir todos los hosts insertados antes de un tiempo dado 15:38:07 <EinMByte> (para evitar descargar la lista completa aunque no sea necesario) 15:38:22 <zzz> esto era originalmente parte del plan de migración criptográfica, pero era difícil y no era la parte más importante 15:38:49 <zzz> pero es lo principal que queda en la migración criptográfica de firmas 15:39:26 <str4d> EinMByte, ya tenemos algo así con etag 15:39:28 <zzz> esto es otra de esas cosas propuestas con muchos detalles, pero sin suficiente acuerdo, así que no se ha empezado 15:39:42 <EinMByte> str4d: ¿se usa, sin embargo? 15:39:46 <str4d> EinMByte, sí 15:40:00 <EinMByte> Oh, no importa. en ese caso 15:40:03 <str4d> Esto no sería diferente de la configuración actual 15:40:20 <zzz> así que lo pondremos en la lista de la 26 y empezaremos cuanto antes. no sé si podremos avanzar lo suficiente para la 26, pero lo intentaré. necesitamos revisar el hilo en zzz.i2p 15:40:22 <str4d> pero en lugar de que las entradas de nombres de dominio no se repitan nunca, ahora se repetirían en el «flujo» 15:40:42 <EinMByte> ¿Hay alguna razón en particular para mantener el formato raro, aun así? 15:41:05 <EinMByte> Me parecería más fácil si simplemente usáramos algo estándar 15:41:06 <zzz> puede ser. compatibilidad con clientes antiguos. pero deberíamos revisar y decidir con certeza si eso es importante 15:41:20 <zzz> ninguno de nosotros ha mirado esto en quizá un año 15:41:28 <zzz> así que lo desempolvaremos y le echaremos un vistazo 15:41:32 <EinMByte> zzz: La compatibilidad se podría manejar proporcionando también el archivo hosts.txt antiguo durante un tiempo 15:41:41 <str4d> También está el tema más amplio de qué hacer con, por ejemplo, todos los nombres «perdidos» 15:41:53 <str4d> Pero eso está fuera de la discusión actual 15:41:57 <zzz> sí. también necesitaríamos involucrar a las otras impls 15:42:18 <EinMByte> str4d: Creo que eso es algo que decidir cuando tengamos un sistema de nombres nuevo (si es que alguna vez lo tenemos) 15:42:26 <str4d> Por ahora, quiero alguna forma de que los dominios actualmente activos actualicen sus dests 15:42:26 <zzz> ok, se queda en la lista para la 26 por ahora. siguiente en la lista: cosas de Sybil 15:42:45 <zzz> ¿podemos hacer que Sybil sea automático? ¿Han leído todos el paper de Philip Winter, espero???? 15:42:50 <str4d> Y cuanto antes metamos el código central, antes podremos activarlo en un año o así 15:43:50 <EinMByte> zzz: ¿Qué artículo? Claramente me perdí algo 15:44:27 <zzz> miren @__phw en Twitter para el enlace 15:45:02 <zzz> estamos trabajando con él gracias a una presentación de sadie en ccc 15:45:03 <EinMByte> zzz: ¿esto: http://arxiv.org/pdf/1602.07787v1.pdf? 15:45:27 <zzz> si se publicó en las últimas un par de semanas, ese es 15:45:59 <EinMByte> Bueno, es un eprint de febrero de este año 15:46:09 <zzz> no creo que estemos listos para lo automático. ellos tampoco, realmente 15:46:22 <zzz> ellos solo escupen un email una vez al día a los dirauths 15:46:36 <zzz> todo son heurísticas y magia por ambos lados 15:46:49 <EinMByte> Así que probablemente puso el eprint en línea después de que se publicara 15:46:57 <zzz> por eso me gustaría posponer lo automático para más adelante en el año 15:47:07 <str4d> EinMByte, 25 de feb es la versión que tengo 15:47:14 <EinMByte> zzz: Entonces ¿cómo funcionaría eso exactamente en un entorno descentralizado? 15:47:44 <str4d> Necesitamos hacer las cosas de abajo arriba en lugar de arriba abajo 15:48:06 <str4d> es decir, cada router tendría que incluir «candidatos potenciales a Sybil» en los perfiles de pares 15:48:13 <zzz> EinMByte, no lo sé. es difícil 15:48:20 <str4d> basado, por ejemplo, en tiempos en línea, etc. 15:48:30 <EinMByte> Detectar ataques Sybil es factible, creo; impedirlos basándose en esa detección es muy difícil en una red descentralizada 15:48:30 <EinMByte> Pero me gusta el reto 15:48:34 <zzz> también necesitamos a gravy, que está trabajando en rehacer su configuración de forma centralizada 15:48:43 <str4d> También existe la posibilidad de tener algún tipo de configuración más centralizada 15:48:45 <str4d> Sí, eso 15:48:45 <EinMByte> str4d: En ese punto necesitas empezar a asignar confianza a cada router 15:48:52 <EinMByte> lo cual en sí sería todo un sistema anti-Sybil 15:49:07 <str4d> Y hacer que los routers se suscriban a una lista de posibles Sybil 15:49:07 <zzz> algo así como las propuestas de dagon 15:49:09 <str4d> EinMByte, eso es básicamente lo que son ahora los perfiles de pares 15:49:31 <str4d> donde «confianza» se define actualmente como «ha enrutado bien de forma fiable para mí en el pasado» 15:49:42 <EinMByte> str4d: Sí, y han provocado algunos ataques hasta ahora :) 15:50:15 <str4d> Sí 15:50:23 <EinMByte> Además, los perfiles de pares no te permiten realmente excluir a un par de la red 15:50:31 <EinMByte> La prevención de Sybil permitiría algo así 15:50:35 <str4d> La elaboración de perfiles de pares y la selección de pares es otra de las cosas que creo que necesita priorización 15:50:46 <str4d> EinMByte, sí pueden 15:51:01 <zzz> así que propongo cambiar el elemento de Sybil de la 26 a «mejora continua», pero mover la parte «automática» para más adelante 15:51:01 <str4d> Ahora mismo no 15:51:11 <str4d> Solo digo que ahí es donde lo pondríamos 15:51:34 <EinMByte> str4d: Sí, es posible. 15:51:37 <str4d> (en términos de introducir la detección de Sybil y técnicas más avanzadas en el léxico y la arquitectura de I2P) 15:51:53 <EinMByte> En cualquier caso, no renunciaría a la descentralización. Es la mejor parte de I2P, en mi opinión 15:52:14 <str4d> Sí 15:52:27 <EinMByte> (y la centralización también conduce a varios ataques prácticos de todos modos) 15:52:43 <zzz> sigamos. ¿mejoras de streaming? no sé bien qué es, quizá solo el elemento perenne de «mejorarlo» 15:52:49 <str4d> zzz, sí, podemos seguir trabajando en esa página de la routerconsole, y luego conectarla a los perfiles y selección de pares una vez que decidamos una estrategia 15:53:00 <zzz> no se me ocurre qué hacer específicamente en streaming. ¿alguien? 15:53:01 <EinMByte> A veces añadir una autoridad central puede facilitar la demostración de seguridad, pero causar fallos de seguridad en la práctica 15:53:20 <str4d> Investigación y optimizaciones estarían bien 15:53:28 <EinMByte> zzz: ¿Alguna mejora obvia que podamos hacer ahí? 15:53:30 <str4d> Eso sería un buen candidato para investigación externa 15:53:46 <zzz> realmente necesitamos un mejor entorno de pruebas 15:53:51 <EinMByte> str4d: De acuerdo. 15:53:55 <zzz> añadir retrasos/pérdidas, reordenar, etc. 15:54:04 <EinMByte> Probablemente deberíamos ampliar nuestra página de «preguntas de investigación abiertas» con eso y otras cosas 15:54:40 <zzz> no tengo muchas cosas «blue sky» en mi lista de streaming. necesita estar guiado por resultados de pruebas 15:54:50 <EinMByte> ¿Puede haber más mejora en la asignación de tunnels? 15:55:05 <str4d> zzz, hay algún proyecto en GH que simula «Internet» con contenedores y puede hacer eso, si no recuerdo mal 15:55:08 <zzz> ¿qué tal si hacemos que este elemento sea «banco de pruebas de streaming» 15:55:17 <str4d> No sé qué tan fácil sería, necesitaríamos una JVM nueva por contenedor :P 15:55:25 <str4d> EinMByte, mmm 15:55:48 <EinMByte> str4d: se podría usar shadow, creo. No estoy seguro de si podría integrarse con Java pero está en la lista TODO de kovri 15:55:52 <str4d> Pero eso no es realmente streaming, eso está a nivel de datagramas 15:56:22 <zzz> lo de la asignación de tunnel es la idea de psi de que el cliente elija los tunnels 15:56:34 <EinMByte> str4d: Sí, sospecho que hay más que optimizar ahí 15:56:46 <EinMByte> zzz: No creo que los usuarios sean los mejores algoritmos de optimización, pero quizá 15:57:10 <zzz> es una violenta corrupción de nuestras capas, y no veo ninguna manera de hacerlo. pero eso es lo que propone psi 15:57:19 <EinMByte> ... o probablemente «cliente» no significa usuario 15:57:32 <zzz> cliente == lado cliente de i2cp 15:57:44 <str4d> La cuestión ahí es 15:57:54 <str4d> Tor proporciona esta capacidad mediante su Control Socket 15:57:58 <EinMByte> Ok, entonces sí significa eso 15:57:59 <str4d> Y es muy útil para investigadores 15:58:10 <str4d> Pero también tienen una arquitectura mucho más plana 15:58:19 <str4d> Mientras que nosotros aislamos distintos clientes entre sí vía I2CP 15:58:31 <EinMByte> zzz: Esperaría que el router tenga más información relevante. El cliente podría pasar cualquier requisito adicional 15:58:41 <zzz> también tenemos los hooks de Lua de psi para investigadores, que nunca se fusionaron (ni en Java ni en kovri), pero sigue siendo una opción 15:59:14 <zzz> fíjate, ahora mismo el lado cliente ni siquiera sabe de tunnels, así que ciertamente no tiene ninguna capacidad de elegirlos 15:59:16 <str4d> Hablando con nickm en RWC, dijo que era mucho más fácil para Tor mantener una interfaz de Control Socket que un sistema de plugins 15:59:17 <EinMByte> Sé que shadow está siendo usado en la práctica por investigadores 15:59:22 <EinMByte> Lua, no sé 15:59:55 <EinMByte> zzz: Entonces probablemente se pueda lograr lo mismo pasando la información relevante por I2CP? 16:00:17 <zzz> 1mb, sí, pero sería realmente feo 16:00:44 <str4d> Siempre podríamos restringirlo con una bandera -research o algo así 16:00:54 <str4d> (en router.config) 16:01:06 <str4d> Así la mayoría de usuarios no están expuestos a lo feo 16:01:13 <zzz> kovri/i2pd aún no tienen esas barreras rígidas de API entre cliente/router, es más fácil para 16:01:20 <zzz> *ellos 16:01:28 <str4d> Y podemos definir «.research» desde el principio para que signifique «Nos reservamos el derecho de cambiar estas APIs» 16:01:44 <str4d> es decir, los investigadores tendrían que usar la bandera .research junto con una versión particular 16:01:57 <str4d> Volviendo al tema de discusión: 16:01:59 <EinMByte> zzz: Sobre los tunnels. Depende. Creo que tendría sentido pasar información sobre el uso previsto del tunnel. 16:02:20 <zzz> (FYI esta reunión durará 25 minutos más como máximo; continuará el domingo) 16:02:33 <EinMByte> zzz: Principalmente es más fácil para nosotros porque shadow está escrito en C, creo 16:02:42 <str4d> Creo que esto debería pasarse a la categoría «necesita más investigación» 16:02:44 <zzz> el problema es que no solo hay que elegir tus tunnels, sino también los del extremo remoto 16:02:48 <EinMByte> Ok. Sigamos entonces. 16:03:08 <zzz> ok, eso es todo lo que hay ahora en la lista de la 26. ¿Qué debería añadirse? 16:03:11 <EinMByte> zzz: ¿No se encarga de eso el extremo remoto 16:03:36 <zzz> no, hacemos source-routing (es decir, elegimos el lease del extremo remoto de su leaseset para su inbound) 16:04:08 <zzz> miren la lista 27-29. ¿qué debería adelantarse a la 26, si algo? 16:04:44 <str4d> Quiero empezar a hacer el trabajo preparatorio para nuevos LSs y la netdb 16:04:46 <zzz> aquí es donde está todo el «trabajo inicial en xxx para 2017», pero también muchas cosas de 2016 16:05:23 <EinMByte> zzz: Malentendí lo que querías decir con far-end, no importa 16:05:31 <str4d> Cuanto antes estabilicemos eso y lo metamos en el código base, antes tendrá la red un soporte amplio para ello 16:06:42 <EinMByte> Tengan en cuenta que nosotros (kovri) queremos especificaciones 16:06:52 <EinMByte> De lo contrario será difícil seguir el ritmo de la implementación 16:07:31 <zzz> claro. cualquier cosa que sea una especificación nueva, tenemos que trabajarla todos juntos 16:07:36 <EinMByte> str4d: Empecemos listando qué debería soportar realmente LS2 16:07:53 <EinMByte> (si eso no se ha hecho ya) 16:09:40 <zzz> básicamente ls2 son solo un par de cosas 16:09:59 <zzz> añadir algo de espacio para flags 16:10:09 <zzz> y habilitar criptografía futura 16:10:52 <zzz> pero tengo todas esas propuestas sobre mejor multihoming, más búsqueda de servicios al estilo Grothoff 16:11:00 <zzz> anycast 16:11:01 <EinMByte> ¿Tenemos en algún lado una lista específica como referencia? 16:11:11 <zzz> está reunido en zzz, un segundo 16:11:23 <str4d> EinMByte, estoy trabajando poco a poco en reunir todo eso en el sitio web 16:11:41 <zzz> ¿podemos hacer eso más rápido, str4d? ¿como en la próxima semana o dos? 16:11:47 <str4d> Eso debería ir a la lista de la .26 16:11:50 <str4d> Hmm 16:11:53 <str4d> Posiblemente 16:11:59 <str4d> Necesito más ojos en ello 16:11:59 <zzz> sin las propuestas en una lista simple esto es demasiado difícil 16:12:08 <EinMByte> str4d: Genial. De hecho, para algunas de estas cosas una funcionalidad tipo wiki sería útil 16:12:24 <EinMByte> (la idea es que iría más rápido) 16:12:48 <zzz> para empezar necesitamos una lista 16:12:50 <str4d> EinMByte, exacto 16:12:56 <zzz> no intentemos «hervir el océano» aquí 16:13:11 <str4d> Estoy intentando pasar de requerir HTML de backend a (actualmente) rST 16:13:31 <str4d> Necesito que la gente revise lo que tengo para comprobar que a) es utilizable y b) no perdemos nada de lo que tenemos ahora 16:13:39 <str4d> Actualmente se aplica solo a los documentos de especificación 16:13:40 <zzz> pongamos lo de las propuestas en la lista para la 26 y hablaremos después de lo que significa. Pero necesitamos avances en eso cuanto antes. 16:13:55 <str4d> Pero en cuanto eso se solidifique, extenderlo a propuestas es trivial 16:13:56 <zzz> las quiero en el sitio web. no me importa en qué forma. 16:14:46 <EinMByte> Estoy dispuesto a revisar propuestas, pero a veces pasa que simplemente no encuentro ningún texto 16:15:10 <EinMByte> (algunas cosas en el sitio web están medio escondidas, creo) 16:15:37 <zzz> cierto 16:16:05 <zzz> necesitamos mover cosas de zzz.i2p al sitio web con algún tipo de organización 16:16:13 <EinMByte> str4d: Pasar de HTML a algo que pueda convertirse fácilmente a varios formatos es algo bueno 16:16:28 <EinMByte> zzz: Sí, absolutamente 16:16:35 <str4d> EinMByte, lo que necesito que revisen está en i2p.www.str4d 16:16:36 <EinMByte> Quizá un proceso fijo para todas las propuestas 16:16:57 <zzz> ok. está en la lista para la 26. detalles por venir. str4d, manos a la obra. no esperaría mucho feedback. Solo inventa un sistema nuevo y todos nos alinearemos 16:17:02 <str4d> y en http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/ 16:17:04 <str4d> EinMByte, si quieres trabajar conmigo para concretar eso, podría tenerlo listo quizá para la .25 16:17:23 <zzz> ¿qué más para la 26? tenemos que ir cerrando 16:17:36 <str4d> ( EinMByte, http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/spec específicamente) 16:18:14 <zzz> esto es para muy corto plazo. necesito saber qué hacer el lunes 16:18:27 <zzz> última llamada para la 26 16:18:41 <str4d> Creo que lo de suscripciones llevará un tiempo 16:18:49 <str4d> Así que me conformo con que eso sea lo principal 16:18:52 <zzz> de acuerdo. 16:19:54 <zzz> ok. reunión el domingo a la misma hora. empezaremos con vrp/h1. por favor revisen el ticket 1119 de antemano. después hablaremos de 27-29, si el tiempo lo permite. 16:20:06 <EinMByte> str4d: ¿Alguno de esos que creas que requiere más atención? 16:20:27 <zzz> también podemos volver brevemente a la 26 el domingo si es necesario 16:20:43 <str4d> EinMByte, básicamente decidir si el formato para escribir propuestas es utilizable y si limita lo que termina en el sitio web (ya sea en formato HTML o TXT) 16:20:45 <zzz> así que la agenda del domingo será 1) vrp/h1/1119; 2) 26; 3) 27-29 16:20:57 <zzz> gracias a todos 16:21:25 * zzz *bafs* cerró la reunión 16:27:50 <EinMByte> str4d: Probablemente está bien mientras pueda convertirse a la mayoría de los otros formatos :)