Reunión de desarrolladores de I2P - 20 de julio de 2004

14:05 <jrandom> 0) hola 14:05 <jrandom> 1) 0.3.2.3, 0.3.3 y la hoja de ruta 14:05 <jrandom> 2) s/reliability/capacity/g 14:05 <jrandom> 3) actualizaciones del sitio web 14:05 <jrandom> 4) ataques y defensas 14:05 <jrandom> 5) ??? 14:05 <jrandom> 0) hola 14:05 * jrandom saluda con la mano 14:05 <jrandom> notas de estado semanales publicadas en @ http://dev.i2p.net/pipermail/i2p/2004-July/000358.html 14:06 <jrandom> pasando directamente al 1) 0.3.2.3, 0.3.3 y la hoja de ruta 14:07 <jrandom> (mientras van leyendo por adelantado, supongo ;) 14:07 <jrandom> la versión 0.3.2.3 está ahí fuera y parece estar yendo bien 14:07 <jrandom> ¿cuáles son los principales puntos problemáticos que la gente está viendo? 14:08 <deer> <Nightblade> ningún problema en absoluto 14:08 <deer> <duck> 4d de tiempo de actividad sin problemas 14:08 <jrandom> hmm, vale 14:08 <deer> <duck> para algunos irc no parece muy estable 14:08 <deer> <duck> como a kaji expulsándolo cada minuto 14:08 <deer> <duck> pero eso no es nada nuevo 14:09 <jrandom> sí, eso le pasa también en la red de freenode, así que no estoy seguro de a qué echarle la culpa ahí 14:09 <deer> <duck> sí 14:09 <deer> <duck> connelly tuvo algunas descargas malas hasta donde sé 14:10 <deer> <duck> pero no me oyes quejarme 14:10 <jrandom> ¿ah, de verdad? hmm, creo que encontramos que algunas de esas estaban relacionadas con su lib, pero he experimentado fallos ocasionales en transferencias de archivos más grandes 14:10 <jrandom> especialmente al bajar libros de alexandria 14:10 <jrandom> (bueno, no especialmente, pero ese es el único sitio del que bajo cosas) 14:11 <deer> <duck> :) 14:11 <jrandom> ok, bueno, mi plan es que, una vez salga la versión 0.3.3, dedicaré mi tiempo a llevarnos a la 0.4, junto con cualquier corrección de errores que la gente plantee 14:12 <jrandom> El trabajo restante para la 0.4 es en gran medida cosas web sencillas (nueva consola del router con servlets, integración con Jetty, un servlet para controlar el router y un servlet para configurar las instancias de i2ptunnel) 14:13 <jrandom> quizá algunas personas de JSP/servlet puedan ayudar con algo de eso para mojarse los pies con el código, aunque ya he hecho bastante de eso antes, así que la implementación no será demasiado difícil 14:13 <jrandom> hasta donde sé, el instalador de hypercubus está prácticamente listo 14:13 <jrandom> (aunque hoy le eché algo de trabajo nuevo ;) 14:13 <deer> <duck> featurecreep++ 14:14 <jrandom> mantiene a la gente en alerta :) 14:14 <jrandom> (pero vamos, todo el mundo odia descargar todos los jars por separado para las actualizaciones) 14:14 <deer> <duck> sí, ese es mi mayor problema al actualizar 14:14 <deer> <duck> (aunque uso cvs) 14:14 <deer> <duck> pero lo sería si no lo usara 14:15 <jrandom> je 14:15 <mihi> jrandom: simplemente haz tar de todos -> 1 descarga ;) 14:15 <jrandom> eso sería bastante simple, y dejar updgrade.sh/upgrade.bat == jar xf upgrade.jar 14:16 <jrandom> (después de una llamada tipo wget) 14:16 <jrandom> bueno, creo que hypercubus tiene bajo control el código para hacer todo eso, así que podemos dejar que él haga lo Correcto 14:17 <jrandom> de todos modos, sí, como quizá se hayan dado cuenta, nuestro calendario no es exactamente el que era antes 14:17 <jrandom> la hoja de ruta se ha actualizado y aaalllaaarrggaaadddaaa 14:18 <mihi> jjrraannddoomm:: rreevviissaa ttu ccoonmmuuttaaddoorr ddee ddúúpplleexx 14:18 <deer> <Nightblade> jajaja 14:18 <jrandom> je 14:18 * mihi cometió un error... ¿quién lo detecta primero? 14:19 <jrandom> (\n\n) 14:19 <jrandom> pero bueno 14:19 <mihi> vale, otro ;) 14:19 <duck> (sin espacios dobles) 14:19 <mihi> duck++ 14:20 <jrandom> Creo que la hoja de ruta es bastante realista, al menos hasta la versión 1.0 ahora; aunque, dependiendo de la adopción y comentarios de los usuarios, podríamos reordenar o eliminar una de 0.4.2 o 0.4.3 14:20 <jrandom> (y, por supuesto, como siempre, la hoja de ruta está sujeta a cambios si más gente se involucra :) 14:21 <modulus> quizá algún día lo haga, después de aprender Java, pero i2p no suena como un proyecto para un novato. 14:21 <deer> <Sandworm> sí, llevará más tiempo :) 14:21 <deer> * duck espera algunos deslices más en el camino 14:21 <modulus> :-) 14:22 <deer> * duck apenas puede llamarlo deslices, mira la impresionante tabla en http://www.i2p.net/redesign/announcements 14:22 <jrandom> Puede haber retrasos, claro, pero creo que los hitos que quedan son bastante abordables 14:22 <jrandom> sí, gracias por mostrar que no tengo vida, duck ;) 14:22 <deer> <duck> esta es tu vida 14:22 <modulus> entonces, ¿para cuándo sale la 1.0? :-) 14:22 <deer> <duck> siéntete orgulloso de ello 14:23 <jrandom> modulus: aunque algunas partes de i2p son un fastidio, hay muchas piezas que un desarrollador nuevo puede abordar con bastante facilidad 14:23 <modulus> aunque probablemente partes bastante aburridas, ¿no? 14:24 <jrandom> nah, para nada. por ejemplo, montar una app de transferencia de archivos o chat anónima, un mini servidor web, un MUD, una app de ajedrez, lo que sea 14:24 <duck> (actualizaciones del sitio web) 14:24 <modulus> hmm, suena bien. 14:24 <jrandom> (o sea, apps cliente sencillas que puedan ser anónimas) 14:24 <jrandom> y por supuesto, actualizaciones web ;) 14:25 <modulus> ¿qué es eso de las actualizaciones web? 14:25 <jrandom> nuestro sitio web necesita trabajo (ver http://dev.i2p.net/pipermail/i2p/2004-July/000358.html o esperar unos minutos al punto 3 de la agenda) 14:25 <cat-a-puss> ¿Dónde encaja myi2p en todo eso? 14:25 <modulus> ah ah 14:26 <jrandom> cat-a-puss: http://www.i2p.net/redesign/myi2p :) 14:26 <modulus> me parece que myi2p no es una prioridad ahora mismo... 14:26 <jrandom> (acabo de escribir una breve página al respecto hace unas horas) 14:27 <jrandom> como nota al margen, las actualizaciones del sitio se publican en la lista i2pwww (http://dev.i2p.net/pipermail/i2pwww/2004-July/thread.html) 14:28 <modulus> hmm, podría escribir un global naming ap :-) 14:28 <jrandom> pero sí sigo viendo que la implementación de myi2p (al menos la libreta de direcciones básica y el blog) se implemente para la versión 1.0 14:28 <jrandom> (según la hoja de ruta, prevista para noviembre) 14:28 <jrandom> sí, ciertamente podrías 14:28 <modulus> algo más simple que DNS, con autenticación y delegación de TLD's 14:28 <jrandom> tampoco estaría mal tenerlo: una app sencilla con la que pudieras consultar a un servidor de nombres central estaría bien 14:29 <modulus> sí 14:29 <jrandom> así que, a programar :) 14:29 <modulus> Empezaré mañana. Pégame un toque si estoy en otras cosas ;-) 14:29 <jrandom> jeje, genial, así lo haré 14:29 <jrandom> ok, pasemos al 2) s/reliability/capacity/g 14:29 <duck> pequeña pregunta sobre el sitio: 14:29 <duck> oh, espera 14:29 <duck> ese es el 3 14:29 <duck> perdón 14:29 <jrandom> claro, ¿qué pasa? 14:30 <jrandom> ah, 'k 14:30 <jrandom> va a haber un cambio bastante fundamental en el código de perfilado y selección de pares en la versión 0.3.3, como se describe en el correo y en http://www.i2p.net/redesign/how_peerselection 14:31 <jrandom> lo tengo corriendo en un par de routers por el momento y parece comportarse bastante bien (Velocidad: 25.18 (5 pares rápidos) Capacidad: 17.50 (8 pares de alta capacidad) Integración: 37.00 (2 pares bien integrados)) 14:31 <jrandom> y no más valores negativos :) 14:31 <modulus> :) 14:32 <jrandom> voy a probarlo a fondo un poco más, quizá otro día o dos, y luego lo publicaré como 0.3.3 14:32 <cat-a-puss> d 14:32 <cat-a-puss> <modulus> 14:32 <cat-a-puss> ups 14:33 <duck> ¿sugiriendo no actualizar cvs? 14:33 <cat-a-puss> para hacer DNS mira un caché de http://www.levien.com/thesis/compact.pdf 14:33 <jrandom> no, cvs está bastante estable por el momento 14:33 <jrandom> (pero, como siempre, prepárense para volver atrás si aparece alguna cosa fea) 14:35 <jrandom> se ve bien, cat-a-puss, gracias 14:35 <cat-a-puss> (tengo una copia del original si alguien la quiere) 14:36 <jrandom> la caché de Google estropea un poco las imágenes, así que si tienes el PDF en bruto, estaría genial 14:36 <jrandom> en fin, nos estamos yendo un poco del tema por el momento (pero podemos volver a esto) 14:37 <jrandom> eso es básicamente todo para el cambio de reliability/capacity, así que pasemos al 3) actualizaciones del sitio web 14:37 <jrandom> duck: ¿tenías algo que querías plantear? 14:38 <jrandom> mientras duck prepara sus notas, ¿quizá alguien tenga ideas/sugerencias/preocupaciones con respecto a los puntos publicados en el correo? 14:39 <deer> <Nightblade> el sitio web se ve bien 14:39 <jrandom> sí, me gusta la nueva navegación y el diseño del sitio es bastante limpio 14:40 <deer> <Nightblade> más fácil encontrar las cosas 14:40 <cervantes> _mucho_ más fácil encontrar las cosas 14:40 <duck> antes que nada quiero agradecer a nuestro defensor del usuario, protocol, por volverse útil :) 14:40 <jrandom> je 14:40 <duck> tuvo algunas buenas sugerencias y acaba de empezar 14:40 <cervantes> ¡hip hip hurra! 14:40 <jrandom> (¡eso, eso!) 14:41 <duck> luego, creo que casi no hay razón para no poner el rediseño en producción de verdad 14:42 <jrandom> de acuerdo: quizá podamos simplemente marcar news/development/documentation como elementos que no son de navegación de página, dejar de lado por el momento la jvm y los ajustes de configuración, y conseguir contenido básico para la página de I2PTunnel, creo que podemos desplegarlo 14:42 <jrandom> solo quiero que salga en vivo con todos los enlaces funcionando (y todas las páginas que no están funcionando) 14:43 <jrandom> por supuesto habrá más actualizaciones después de que salga en vivo ;) er, en vivo 14:43 <jrandom> ejem, en vivo 14:44 <jrandom> como nota al margen, wilde también ha conectado nuestra cuenta de 34sp, así que podremos migrar el sitio allí cuando sea necesario 14:44 <cervantes> genial 14:44 <jrandom> ¿qué opinas, duck? ¿puede el coso de menu.php manejar entradas de navegación que no sean de página? 14:44 * cervantes revisa su bandeja de entrada por puntos de referidos 14:45 <jrandom> (¿o sería demasiado esfuerzo modificar eso?) 14:45 <jrandom> jeje, cervantes, eso debería estar en camino 14:45 <cervantes> ;-) 14:45 <cervantes> ah, la vieja jugada de «el cheque va en el correo» 14:47 <duck> perdón; estoy haciendo otro trabajo mientras tanto. 14:47 <duck> ok; sí es posible hacerlo solo título de sección de navegación 14:47 <jrandom> no hay problema, podemos seguir y volver a eso luego si prefieres 14:47 <jrandom> ok, genial 14:47 <jrandom> (duck++) 14:48 <jrandom> ok, ¿algo más relacionado con el sitio web? 14:48 <duck> con tu sugerencia, suena listo para subir. 14:48 <jrandom> si no, podemos pasar al 4) ataques y defensas 14:48 <duck> . 14:48 <jrandom> vale 14:49 <jrandom> ok, supongo que han leído la lista de correo y han visto los mensajes de connelly y las distintas respuestas 14:50 <cervantes> ha estado ocupado :) 14:50 <cervantes> (casi tanto como proto) 14:50 <Connelly> en mi opinión, la red parece sólida frente a todo excepto análisis de tráfico (sitios con mucho tráfico), ataques de corte de conexiones por parte del gobierno y atacantes que tomen una gran mayoría de la red 14:50 <jrandom> aunque creo que estamos bastante bien, estoy seguro de que debe haber algo (o varias cosas) que se nos escapa, así que por favor no asuman que i2p hace o hará lo que dice: cuestionen los supuestos y digan por qué apesta 14:50 <Connelly> el cifrado básicamente neutraliza cualquier ataque no agresivo 14:51 <jrandom> esa es la esperanza 14:51 <jrandom> además, con las capacidades de i2p 2.0 y 3.0, serán posibles defensas contra ataques de adversarios de escala gubernamental 14:51 <Connelly> claro que en la práctica habrá agujeros de seguridad que parchear 14:52 * jrandom todavía necesita escribir algo de documentación sobre cómo las demoras 3.0 evitarán ataques de segmentación 14:52 <jrandom> ciertamente, connelly 14:54 <jrandom> ok, si no hay nada más en esa línea, creo que eso es todo lo que tengo 14:54 <jrandom> así que 5) ??? 14:55 <jrandom> oh, como nota al margen, tracé el gráfico de uso de ancho de banda frente al número de tunnels en los que se participa para una de las simulaciones durante un período de 4 días 14:55 <jrandom> eso está publicado en @ http://dev.i2p.net/~jrandom/4daybandwidth.webp 14:56 <jrandom> la simulación tenía mensajes de 32KB enviados ida y vuelta cada 30s, con dos routers estrangulados a 6KBps, y las cosas se comportaron exactamente como 'deberían' 14:56 <duck> (propiedad nolink implementada para el sitio) 14:56 <jrandom> (p. ej., carga distribuida sobre los pares rápidos y fiables, pares lentos evitados, etc.) 14:56 <jrandom> w00t 14:56 <Connelly> una gráfica logarítmica de ancho de banda/usuario frente al tamaño de la red estaría bien 14:57 <Connelly> para que puedas decir 'sí, realmente escala' 14:58 <jrandom> eso ni siquiera necesitaría una gráfica logarítmica: la escalabilidad de la comunicación del cliente es estrictamente O(1) [requiere 2k*msgSize, donde k = # de saltos en el tunnel] 14:58 <jrandom> pero sí, estoy de acuerdo, necesitamos documentación que describa cómo escala i2p 14:58 <Connelly> bueno, para Kademlia... ¿eso está en tu simulación? 14:58 <jrandom> sí, la simulación es en realidad el código completo del router, todo ejecutándose en una sola JVM 14:58 <jrandom> lo estoy ejecutando incluso con conexiones TCP completas en lugar del sistema de comunicación de la VM también 14:59 <jrandom> el código Kademlia se utiliza la primera vez que Alice quiere contactar a Bob; mientras sigan hablando, su comunicación es O(1) ya que incluyen su LeaseSet junto con la carga útil 14:59 <jrandom> (así que no hay necesidad de búsquedas posteriores en la netDb) 15:00 <cervantes> vl07 y onb0 son los routers estrangulados? 15:00 <jrandom> pero sí, necesitamos una simulación que demuestre cómo escala la propia netDb 15:01 <jrandom> cevantes: 0jvf y onb0 15:01 <cervantes> ¿a qué se debe la caída de vl07 después de un día de tiempo de actividad? 15:02 <cervantes> parece cruzarse con 00u0 15:02 <jrandom> todos los routers no estrangulados son esencialmente iguales: están todos en la misma CPU, todos tienen la misma latencia (0ms), así que la asignación de uno como 'rápido' frente a 'fiable' es simplemente arbitraria 15:04 <Connelly> ¿tus designaciones de 'rápido y fiable', 'lento', etc., se recuperan de valores muy grandes? 15:04 <jrandom> ¿por qué redujo su ranking/uso después de un día? no estoy seguro, quizá una sobrecarga transitoria de CPU o E/S mientras se estaba probando hizo que su velocidad se redujera un poco 15:04 <jrandom> sí, las clasificaciones usan ahora la mediana, no la media, además hay una caída bastante rápida en los datos 15:05 <jrandom> s/fiarly/fairly/ 15:05 <Connelly> entonces si te hago pensar que mi fiabilidad es 1000000000, ¿puedes recuperarte cuando empiece a soltar mensajes? 15:06 <jrandom> por supuesto: si 'fallas', dejo inmediatamente de pedirte que hagas cosas y disminuyo tu clasificación 15:06 <jrandom> a su vez, el nuevo cálculo de 'capacidad' es bastante sensible a ese tipo de cambios 15:06 <jrandom> (la velocidad también es difícil de falsear, pues todas las clasificaciones de velocidad son valores medidos reales) 15:07 <jrandom> ((como lo era la fiabilidad, y como lo es el cálculo de capacidad)) 15:09 <jrandom> ok, ¿alguien más tiene algo que quiera plantear? 15:10 <deer> * jrandomi2p sugiere el *baf*er 15:11 * jrandom está de acuerdo 15:11 * jrandom se prepara 15:11 * jrandom *baf* cierra la reunión