Reunión de desarrollo de I2P - 25 de noviembre de 2014

20:04:39 <str4d> Yo 20:04:44 <str4d> Es hora de la reunión 20:06:47 <str4d> zzz, psi, kytv, Meeh, dg 20:07:30 <psi> ¿lo es? 20:07:39 <psi> ah martes 20:09:03 <zzz> presente 20:09:48 <orignal> ¿reunión? 20:10:11 <str4d> orignal: hablando de la lista de tareas de Java I2P 20:10:35 <str4d> Mientras esperamos a que lleguen los demás: http://trac.i2p2.i2p/wiki/Roadmaps/1.0 20:10:41 <kytv> Presente también, aunque normalmente soy inútil para estas cosas. 20:11:37 <str4d> He ajustado el diagrama de Gantt en la página de arriba (que configuré para el ciclo de desarrollo 0.9.13-0.9.16) para mostrar lo que creo que hicimos. 20:13:30 <zzz> interesante 20:14:06 <zzz> múltiples dests por tunnel <-- no ha pasado 20:14:22 <str4d> ¿No ha pasado? Ok, culpa mía. 20:14:27 <zzz> pasada de FindBugs <-- ha ocurrido, pero siempre se puede volver a hacer 20:14:56 <str4d> Varias sesiones por I2CP: eso tampoco ha ocurrido *derp* 20:14:56 * str4d corrige 20:15:48 <zzz> vaya, tuvimos un buen año (en mi humilde opinión) 20:16:38 <eche|on> sí, lo tuvimos 20:17:14 <str4d> zzz: sí, lo consideré parte de la preparación de la auditoría específicamente, pero tienes razón. 20:17:39 <zzz> investigar un nuevo DH <---- diría que solo a medias, con respecto a NTCP2 al menos 20:20:26 <str4d> El diagrama de Gantt no muestra fácilmente lo medio hecho :P 20:20:34 <str4d> Recarguen la página, arreglos 20:21:36 <str4d> Bien, eso es lo que logramos el último ciclo. 20:21:36 <zzz> entonces no está hecho 20:23:45 <str4d> El propósito de esta reunión es comenzar a planificar qué se hará en el próximo ciclo. 20:23:46 <zzz> Me gustaría reiterar que un ciclo de planificación de 3-5 versiones parece ser muy útil para enfocar nuestras mentes y nuestros recursos 20:23:47 <str4d> (Cuando actualice el diagrama de Gantt, dejaré allí los a medio hacer y los empujaré hacia adelante) 20:23:47 <str4d> En la reunión anterior pedí a los asistentes que propusieran algunos puntos cada uno de cosas que quieren ver hechas en I2P y alrededor de I2P 20:23:47 <str4d> ¿Podemos pegarlas ahora, por favor? 20:24:21 <str4d> +1 20:24:36 <str4d> ¡Y ahora tenemos evidencia de ello! 20:26:15 <zzz> sin entrar en qué es más importante que qué, creo que casi todo lo que se muestra y está sin terminar en el diagrama de Gantt sigue siendo importante 20:27:01 <str4d> Estoy de acuerdo. 20:27:07 <str4d> Aún quiero ver qué ideas se les ocurrieron a todos durante la última semana, si es que hubo. 20:27:45 <str4d> Aquí van las mías: http://pastethis.i2p/show/jF2RkHwrIPkCb0yOpI7l/ 20:27:46 <iRelay> Título: Paste #jF2RkHwrIPkCb0yOpI7l | LodgeIt! (en pastethis.i2p) 20:28:07 <eche|on> Me quedo sin opciones, yo sí veo sacar I2P, con la ayuda de Bote para Android, i2p messenger es una opción, un servidor XMPP y Syndie. Lo siento, sigo viendo Syndie como importante. 20:28:27 <str4d> eche|on: ¡genial, gracias! 20:28:43 <str4d> Sigan enviándolas :) 20:28:53 <eche|on> y con la app de Android llegan las rutas restringidas 20:28:54 <zzz> mi lista de cosas nuevas: resolver el problema de ECDSA en Red Hat, migrar a EdDSA, Jetty 9 / Java 7, ampliar la base de usuarios de Vuze, y más marketing / divulgación / asociaciones / integración 20:29:36 <str4d> Para que quede registrado para la posteridad, escribiré mis ideas aquí también: 20:30:11 <str4d> Pendientes en I2P: análisis y rediseño de UX de Routerconsole; tomar ideas del diseño de HS 2.0 de Tor y aplicarlas a los Destinos de I2P; programación de ancho de banda. Pendientes alrededor de I2P: mejoras al tema del sitio web; implementar relés de obtención de I2P-Bote; investigación 20:30:23 <zzz> otro: orchid: arreglarlo o matarlo 20:30:32 <str4d> +100 20:31:13 <kytv> Con respecto al problema RedHat/Gentoo ECDSDA, quizá podríamos/deberíamos mostrar un mensaje en la barra lateral (o en los registros) con un enlace de descarga. O quizá preguntar al usuario si 'nosotros' deberíamos descargarlo en ./lib 20:31:35 <zzz> otro: mejoras de pruebas, hardware de pruebas, pruebas en Windows 20:31:58 <str4d> kytv: buenas ideas (pero hablar de ellas puede esperar a otra reunión :) 20:32:03 <zzz> otro: gastar más dinero 20:32:36 <zzz> otro: China 20:32:58 <str4d> Entre estas ideas y la lista de no completados en la página de arriba, tenemos un buen conjunto de proyectos potenciales. 20:33:34 <str4d> Mi objetivo es ordenar estos proyectos, formalizarlos y publicarlos en la página de tareas (todo) del sitio web 20:34:11 <str4d> Tras curiosear páginas de tareas de otros proyectos, este es el formato que propongo: 20:34:11 <str4d> http://pastethis.i2p/show/nvexU3ZvSFOI6L5DrrqM/ 20:34:12 <iRelay> Título: Paste #nvexU3ZvSFOI6L5DrrqM | LodgeIt! (en pastethis.i2p) 20:34:54 <eche|on> buena idea 20:35:10 <kytv> Ídem con Orchid 20:35:10 <kytv> Mi principal "TODO alrededor de I2P" es con respecto a pruebas. No pruebas automatizadas con software, per se, sino que alguno de nuestros servicios salga a producción sin ningún tipo de prueba... solo [poof], "está en vivo... aunque no sé si funciona." 20:35:12 <kytv> En I2P: Hacer que el instalador instale en el directorio del usuario en Windows para evitar cualquier problema de permisos. Debería ser fácil, pero no sé cómo. 20:35:16 <kytv> Chrome hacía eso (¿quizás aún lo hace?) 20:35:41 <str4d> Mi resultado ideal: los usuarios pueden ir a la página de tareas (todo) y encontrar una lista de todas las ideas que tenemos para proyectos en y alrededor de I2P. 20:36:11 <zzz> otro: GSoC 20:36:14 <str4d> Habrá una nube de etiquetas en la parte superior en la que pueden hacer clic para filtrar proyectos que requieren ciertas habilid 20:36:17 <str4d> habilidades 20:36:21 <zzz> otro: encuentro de verano 20:37:54 <zzz> otro: investigación de GNS, ¿segunda pasada? 20:38:28 <str4d> mmm 20:38:54 <zzz> o quizá baste con otra discusión con esos tipos 20:39:09 <str4d> Ahora voy a depurar del Gantt las tareas que hemos completado. 20:39:27 <zzz> ¿puedes guardarlo y empezar uno nuevo? 20:39:29 <str4d> zzz: ¿cuáles de las últimas de abajo se han completado (detección de replay de SSU, etc.)? 20:39:38 <str4d> Seguro, puedo. 20:39:49 <zzz> es bueno mostrar que realmente logramos cosas 20:40:19 <eche|on> zzz: la mayoría de las cosas las hiciste tú, IMHO 20:40:35 <EinMByte> ¿me perdí la reunión? 20:40:37 <zzz> Creo que he reportado todo respecto a si estaba completado o no 20:42:39 <str4d> Nuevo gráfico publicado 20:43:55 <str4d> zzz: ¿cuáles de las tres del fondo deberían empujarse hacia adelante? Creo que el bloqueo del cliente sigue siendo un problema? 20:43:59 <zzz> Me gustaría ver mucha más planificación y enfoque en las cosas sin código en los próximos meses. Demasiadas cosas están desorganizadas o no suceden a un ritmo disciplinado o constante 20:44:09 <str4d> (bloqueo de tunnel del cliente) 20:44:18 <str4d> zzz: Estoy de acuerdo. 20:44:34 <str4d> Esto, en mi humilde opinión, se verá ayudado por trabajar en la página de tareas (todo). 20:44:56 <str4d> Si podemos explicar los proyectos sin código de una forma que los recién llegados puedan entender y hacer, también nos ayuda. 20:44:59 <zzz> no estoy 100% seguro en este momento de qué es ese elemento de bloqueo del cliente, pero creo que sigue sin terminar 20:45:08 <str4d> (Lo mismo para proyectos con código) 20:45:32 <zzz> sí 20:45:53 * str4d empuja también las mejoras de streaming hacia adelante 20:46:03 <str4d> ¿Puedo cortar entonces la detección de replay de sesión SSU? 20:46:04 <dg> ¿Te refieres a los problemas de duplicados? 20:46:18 <dg> ¿A cómo teníamos tunnels que no se desregistran de I2PTunnel y no permiten nuevos? ¿Ese tipo de cosas? 20:46:30 <zzz> str4d, tendré que responderte luego respecto a SSU replay, no estoy seguro ahora mismo 20:46:45 <dg> Me gustaría ver menos muerte de tunnel en lugar de centrarnos en el rendimiento 20:46:59 <str4d> dg: podría ser eso. También está el tema aparte de que el inicio de I2PTunnel bloquea la UI 20:47:29 <zzz> pon 'tunnel death' ahí como un nuevo elemento, por qué no 20:48:01 <dg> str4d: ¡Lo había olvidado! 20:48:03 <str4d> k 20:48:39 <zzz> Creo que el tema del bloqueo tengo algo sin marcar en el código para ello, viene arrastrándose por unos 18 meses o así, pero aún no está bien 20:48:40 <str4d> Siguiente: revisar las ideas de arriba. ¿Cuáles deberían ir en nuestra hoja de 6 meses (es decir, cuáles agrego al Gantt)? 20:50:16 <psi> EinMByte: reunión en curso 20:50:21 <psi> (no) 20:51:51 <zzz> Sugiero que todo vaya ahí por ahora, luego hablamos de prioridades, o dejamos que las dependencias del Gantt nos digan qué hacer después 20:52:52 <str4d> mmk 20:53:04 * str4d está extrayendo la lista de arriba y ordenándola ahora 20:53:08 <EinMByte> psi: oh, genial. 20:54:08 <psi> elemento potencial: medir (benchmark) el throughput de tunnel y las tasas de pérdida de mensajes 20:54:26 <str4d> EinMByte: ¿tienes ideas para nuestra lista de tareas (todo)? 20:55:15 <EinMByte> NTCP2, posiblemente. Aunque sería a largo plazo 20:56:39 <str4d> EinMByte: para referencia: http://trac.i2p2.i2p/wiki/Roadmaps/1.0 20:56:53 <EinMByte> gracias 20:57:04 <EinMByte> (estaba a punto de preguntar) 21:00:23 <str4d> Aquí está la lista de las ideas de todos: 21:00:24 <str4d> http://pastethis.i2p/show/K0fGRb2708ADbCTZ9u9K/ 21:00:25 <iRelay> Título: Paste #K0fGRb2708ADbCTZ9u9K | LodgeIt! (en pastethis.i2p) 21:01:01 <str4d> Casi todas estas pueden convertirse en proyectos para la página de tareas (todo) del sitio web. 21:01:36 <str4d> Siguiente tema de discusión: ¿cuáles de estas (y las que están actualmente en el Gantt) son más importantes para hacer en los próximos seis meses? 21:02:48 <psi> rutas restringidas es probablemente el elemento más importante en mi opinión 21:02:50 <EinMByte> con respecto a Syndie, quizá: estaba trabajando en este plugin - aunque ahora no tengo tiempo). Esto podría ser una de las cosas que (?) traigan más atención a Syndie. 21:03:20 <dg> str4d: Falta muerte de tunnel y siento que es bastante importante 21:03:37 <EinMByte> Si alguien está interesado en desarrollar plugins para firefox / icedove: ya saben qué hacer 21:03:37 <str4d> dg: está ahí (bloqueo de hilo de tunnel) 21:03:41 <str4d> Pensé que era eso 21:03:49 <dg> oh, perdón str4d, me refería a cuando las conexiones se terminan abruptamente 21:03:54 <dg> mi culpa 21:04:04 <str4d> Ah, ok 21:04:55 <EinMByte> psi: Estoy de acuerdo en que las rutas restringidas son importantes. Pero también creo que debemos darnos cuenta de que tomará bastante tiempo implementarlas 21:05:21 <EinMByte> (no estoy seguro de cuánto del diseño / concepto se ha hecho) 21:05:35 <dg> En I2P: rutas restringidas, problemas de ECDSA en RedHat, HS 2.0 de Tor, y luego el resto. Alrededor de I2P: base de usuarios de Vuze, GSoC, investigación, benchmark, y luego el resto. 21:06:04 <dg> Estoy de acuerdo con EinMByte.. el rediseño de la consola del router es importante pero podría tomar un tiempo indeterminado. 21:07:15 <EinMByte> str4d: una cosa más, posiblemente. Conozco a algunos investigadores que han desarrollado un nuevo concepto para un DWSE (motor de búsqueda web distribuido), podrían estar interesados en desarrollar esto como una aplicación de I2P 21:07:42 <str4d> EinMByte: ¡bien! 21:07:49 <EinMByte> Dado que la mayoría de los DWSE ahora mismo no funcionan realmente bien, sería muy interesante tener esto, IMHO 21:08:01 <zzz> no, por 'tunnel death' me refería a roturas de tunnel de 3 minutos, la prueba de datagramas del tipo de Vuze, etc. Distinto de los problemas locales de bloqueo de i2ptunnel. 21:08:07 <EinMByte> También es algo que consideraría implementar 21:08:20 <dg> No estaba pensando precisamente en 3 minutos pero eso estaba incluido. 21:08:34 <EinMByte> (con ayuda, espero) 21:09:03 <str4d> ok, recarguen la página del Gantt 21:10:34 <EinMByte> str4d: de todos modos no cuenten demasiado con esto, depende de si los usuarios de I2P realmente están interesados en algo así. 21:11:14 <EinMByte> Además, no estoy seguro sobre lo de GNS. En cualquier caso no debería tener alta prioridad. 21:11:56 <str4d> Pegado actualizado de nuevas ideas: http://pastethis.i2p/show/1qxHbkWjD27N7SdzNJZL/ 21:11:57 <iRelay> Título: Paste #1qxHbkWjD27N7SdzNJZL | LodgeIt! (en pastethis.i2p) 21:12:35 <zzz> diría que 4 categorías amplias son de la mayor importancia: 1) continuar con la migración de cripto a corto plazo (libreta de direcciones, múltiples destinos, etc.) 2) planificación/investigación de cripto a más largo plazo (DH, LS2, NTCP2) 3) todo lo relacionado con pruebas 4) todo lo no relacionado con código 21:13:48 <EinMByte> zzz: ¿está en orden de importancia? 21:14:05 <str4d> Los problemas de ECDSA caen en la primera categoría; HS 2.0 de Tor cae en la segunda categoría. 21:14:21 <zzz> no. de importancia aproximadamente igual 21:14:44 <str4d> Así que el único elemento no representado en esas categorías es rutas restringidas 21:15:28 <jenkins@kyirc> Starting build #556 for job i2pd (previous build: SUCCESS) 21:15:30 <jenkins@kyirc> Project i2pd build #556: SUCCESS in 8.2 sec: 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> quizá NTCP2 no es tan importante 21:16:50 <zzz> y la razón por la que las agrupé así y digo igual prioridad es que probablemente haya 4 grupos separados de personas para esas 4 categorías que podrían avanzar en paralelo 21:17:08 <EinMByte> o, al menos antes de poder empezar correctamente con NTCP2 necesitamos hacer mucha investigación, además de responder algunas preguntas muy importantes 21:17:33 <jenkins@kyirc> Project i2pd (Linux x86) build #33: SUCCESS in 1 min 47 sec: http://jenkins.killyourtv.i2p/job/i2pd%20(Linux%20x86)/33/ 21:17:44 <EinMByte> zzz: en efecto 21:17:51 <JekabsR> es interesante que la red i2p tienda a reunir todos los routers rápidos 21:17:58 <jenkins@kyirc> Starting build #33 for job i2pd (Linux x64) 21:18:03 <zzz> correcto. "NTCP2" es solo una abreviatura para un montón de cosas que pueden o no resultar en algo llamado "NTCP2" 21:18:34 <JekabsR> y no prefieren routers lentos 21:18:40 <EinMByte> Sí. En cualquier caso si cambiamos las capas de transporte es extremadamente importante no cometer errores, ya que probablemente rompería I2P por completo. 21:19:19 <psi> JekabsR: los routers más lentos aún se usan, solo que no tanto 21:19:43 <jenkins@kyirc> Project i2pd (Linux x64) build #33: SUCCESS in 1 min 52 sec: http://jenkins.killyourtv.i2p/job/i2pd%20(Linux%20x64)/33/ 21:20:05 <EinMByte> zzz: si 2 es "investigación", entonces tienes razón 21:20:33 <EinMByte> se puede hacer simultáneamente 21:21:52 * str4d está reestructurando el Gantt en estas cuatro categorías (más una categoría Otros) 21:22:12 <JekabsR> pero hay un problema: destinos tipo cliente rara vez obtienen conexiones de router rápidas 21:22:40 <eche|on> ¿no? 21:22:46 <psi> JekabsR: no estoy del todo seguro de que eso sea exacto 21:23:46 <zzz> str4d, ¿nos olvidamos de Android, o es una hoja de ruta separada? 21:23:59 <str4d> zzz: nos hemos olvidado 21:24:01 <eche|on> JekabsR: los routers en modo oculto tienen algunos problemas, pero otros sí consiguen conexiones rápidas, ya que hay suficientes routers rápidos disponibles y con capacidad libre 21:24:26 <str4d> Técnicamente I2P Android cae en la categoría "en I2P" 21:24:35 <psi> oh otra pregunta de investigación: ¿cuánta capacidad tiene realmente I2P ahora mismo? 21:25:14 <zzz> quizá tenga más sentido una quinta categoría para Android 21:25:46 <zzz> pero no estoy obsesionado con las categorías. Solo mencioné las 4 como una forma rápida de comunicar lo que creo que es importante 21:25:54 <JekabsR> porque tienden a crear un pequeño número de conexiones realmente rápidas y un gran número de conexiones lentas 21:26:11 <dg> [se necesita cita] 21:26:15 <JekabsR> mi router empezó a soltar tunnels lentos 21:26:24 <str4d> zzz: Creo que fue una buena idea 21:26:56 <str4d> Actualicen la página del Gantt ahora 21:27:07 <eche|on> JekabsR: https://geti2p.net/_static/pdf/I2P-PET-CON-2009.1.pdf 21:30:12 <eche|on> JekabsR: los tunnels se sueltan solo al final de la vida del tunnel y si los tunnels propios necesitan la capacidad. 21:30:29 <str4d> Si actualizan http://trac.i2p2.i2p/wiki/Roadmaps/1.0 ahora verán los encabezados, cada uno con una barra de seis meses. Esto da una indicación de cuánto tiempo hay para encajar todo. 21:32:43 <str4d> Ahora que tenemos algunas ideas para los próximos seis meses, necesitamos empezar a planificar tiempos. 21:33:18 <str4d> Y quién va a encargarse de qué. 21:33:52 <JekabsR> mi consola informa con frecuencia que tiene demasiadas conexiones entrantes y los tunnels se rechazan parcialmente. ¿Cómo decide I2P cuál rechazar? 21:34:08 <dg> ¿'demasiadas conexiones entrantes'? 21:34:21 <dg> JekabsR: hay una reunión en curso, quizá quieras esperar a que termine 21:35:00 <str4d> También me gustaría algunos voluntarios para ayudar a convertir la lista de ideas en una página de proyectos funcional en la sección de tareas (todo) del sitio web 21:35:12 <JekabsR> Conexiones NTCP: 425. Límite: 425. Tiempo de espera: 2 min. 21:35:30 <JekabsR> Conexiones UDP: 1149. Límite: 1275. Tiempo de espera: 4 min. 21:36:14 <JekabsR> se alcanzan los límites 21:37:42 <JekabsR> el router está usando 80% de la CPU 21:38:23 <str4d> ¿Alguien? 21:39:36 <kytv> JekabsR: 1) reunión en curso, quizá quieras esperar; 2) mira http://127.0.0.1:7657/peers#help 21:41:16 <JekabsR> kytv: lo revisaré 21:41:44 <zzz> str4d, creo que perdiste a todos después de una hora 45. ¿Quizá declaremos la victoria por ahora y avanzamos más en otro momento? 21:41:45 <str4d> Intentemos algunas preguntas más específicas. 21:41:52 <str4d> O eso./ 21:41:55 <JekabsR> 330,0 / 342,4 KBps mi carga actual 21:42:06 <str4d> Sí, definitivamente hemos hecho buenos avances. 21:42:30 <JekabsR> y subidas de torrents a 2 - 5 kb de velocidad :( 21:44:17 <str4d> ¡Gracias por las discusiones, a todos! 21:44:20 * str4d warms up the baffer 21:44:20 * str4d ***bafs the meeting closed