Reunión de desarrolladores de I2P - 22 de noviembre de 2005

16:18 <jrandom> 0) hola 16:18 <jrandom> 1) Estado de la red 16:18 <jrandom> 2) Caza del zorro 16:18 <jrandom> 3) ??? 16:18 <jrandom> 0) hola 16:18 * jrandom saluda tarde desde una casa con la electricidad restablecida 16:18 <jrandom> notas de estado semanales publicadas en http://dev.i2p.net/pipermail/i2p/2005-November/001227.html 16:19 <jrandom> 1) Estado de la red 16:20 <jrandom> no hay mucho que añadir más allá de lo que está en el correo... ¿alguien tiene algo que quiera plantear respecto al estado de la red? 16:21 <jrandom> si no, pasamos a 2) Caza del zorro 16:21 <zzz> gran idea 16:22 <jrandom> aquí tampoco tengo mucho que añadir más allá de lo del correo y las propuestas de Raccoon23.. 16:22 <+fox> <ailouros> Tengo algo en contra del nombre "Caza del zorro". Preferiría llamarlo "Caza del hombre". Los zorros no hicieron nada malo. 16:22 <Raccoon23> jaja 16:22 <jrandom> sí, concuerdo zzz, será bastante útil dar a la gente un incentivo real sin los peligros serios del uso real 16:23 <nickless_head> llamadlo "caza de <animal políticamente correcto> 16:23 <Raccoon23> "Fox hunt" es el nombre típico para un concurso de radioaficionados en el que intentas encontrar un transmisor clandestino 16:24 <+fox> <ailouros> No me importan los transmisores de radio llamados Fox, estamos hablando de I2P aquí, no se permiten zorros anónimos 16:24 <+fox> <ailouros> :D 16:24 * cervantes se pregunta si ailouros conoce el nombre de changate 16:24 <nickless_head> quizá "Caza de disidentes" 16:25 <@cervantes> <fox> <ailouros> :D 16:25 <+fox> <ailouros> (eh ¿qué es changate?) 16:25 <jrandom> je 16:25 <@cervantes> ailouros: son los bots que retransmiten el chat entre diferentes redes 16:26 <+fox> <ailouros> ¿te refieres a vulpine aquí? 16:26 <@cervantes> el chat en I2P se te retransmite como vulpine 16:26 <@cervantes> y tu chat se nos retransmite vía fox 16:26 <@cervantes> ;-) 16:26 <@cervantes> *tu 16:26 <+fox> <ailouros> ¿así que la caza es por el pobre bot esclavizado? :D 16:27 <Raccoon23> sí, creo que debería haber una página de recompensa/información. Creo que deberíamos apuntar a recaudar $1k 16:27 <+fox> <ailouros> sí, perdón, normalmente no voy a i2pchat :) 16:27 <+fox> <ailouros> ahora, ¡esa sí es una recompensa! 16:28 <jrandom> Raccoon23: estoy de acuerdo, pero puede que sea un poco prematuro hacerlo ahora. 16:28 <jrandom> (siempre podemos asignar fondos del fondo general a la recompensa para impulsarla cuando sea necesario) 16:28 <+fox> <ailouros> ¿empezar la caza ahora mismo pero sin recompensa? 16:28 <+fox> <ailouros> quiero decir, cuanto antes empiece, más ojos se abrirán 16:28 <jrandom> para que la caza del zorro tenga sentido (o sea, ayude a I2P), tenemos que hacerlo con cuidado. 16:28 <jrandom> no, ailouros, no estoy de acuerdo. 16:29 <jrandom> ejecutar el concurso antes de que I2P esté listo sería muy malo. 16:29 <Raccoon23> sí 16:29 <jrandom> tanto porque desperdiciaría el tiempo de la gente evaluando algo que no está terminado, como porque no diría nada útil 16:30 <+fox> <ailouros> ....punto tomado 16:30 <Raccoon23> y sería mala prensa si se "encontraran" vulnerabilidades que ya estaban programadas para corregirse en versiones próximas 16:30 <jrandom> sí 16:33 <jrandom> ok, ¿algo más sobre 2), o pasamos a 3) ??? 16:34 <zzz> sobre la otra parte del hilo jrandom/raccoon23, ¿se concluyó pasar a un mínimo de 2 saltos? ¿alguna otra conclusión? 16:35 <jrandom> hmm, todo es una cuestión de quién sea el adversario, pero no haría daño poner por defecto 2 +0-1 y brindaría protección contra una clase de atacante 16:35 <jrandom> otras conclusiones pueden ser "oye, pongamos en marcha 0.6.2" :) 16:35 <+fox> <ailouros> ¿cómo configuro para que los tunnels siempre tengan un valor fijo (como varianza 0+1)? me siguen saliendo valores por defecto en cada reinicio 16:36 <jrandom> ailouros: deberías poder guardar la configuración en /i2ptunnel/ 16:36 <jrandom> ¿o las estás cambiando en /configtunnels.jsp ? 16:37 <Raccoon23> Creo que los tunnels de 1 salto permiten que un atacante bastante débil haga mucho en 0.6.1 al menos. Yo argumentaría que 0.6.1.6 no debería tener tunnels de 1 salto por defecto 16:37 <+fox> <ailouros> es configtunnels 16:37 <jrandom> sí, de acuerdo, Raccoon23 16:37 <jrandom> ailouros: usa /i2ptunnel/ y guarda tu configuración 16:37 <+fox> <ailouros> no me di cuenta de la interfaz nueva :D 16:38 <@cervantes> ailouros: se añadió justo en 0.6.1.5 16:38 <jrandom> sí, cervantes hizo un gran trabajo ahí, ailouros 16:38 <+fox> <ailouros> pues, kudos por eso 16:39 <@cervantes> ya que estamos en ese tema, si la gente tiene problemas para guardar la configuración en la interfaz nueva, quizá quieran usar un navegador que no sea IE por ahora hasta la próxima versión 16:39 <@cervantes> *gruñido* microsoft *gruñido* 16:40 <+fox> <ailouros> en otro tema, ¿a alguien le interesaría si monto un servidor de nethack en I2P? :D 16:41 <@frosk> ailouros: lo he estado pensando (jugando nethack irl), pero me temo que el lag sería horrible (y el lag apesta realmente cuando juegas nethack) 16:42 <+fox> <ailouros> supongo 16:42 <+fox> <ailouros> vale, idea descartada 16:43 * frosk acaba de tener su primera ascensión hace unos meses, woot 16:44 <jrandom> ok, ¿alguien tiene algo más para la reunión? 16:45 <+fox> <ailouros> sí, algún indicador para Syndie cuando el hilo tenga un mensaje nuevo 16:46 <nickless_head> jrandom: y estaría bien si los mensajes nuevos (los títulos) pudieran mostrarse en negrita/cursiva la primera vez que se muestran 16:47 <nickless_head> jrandom: ¿hay una forma _realmente simple_ de acceder a los mensajes en la base de datos de Syndie, vía http? 16:47 <jrandom> ah sí, ailouros/nickless_head, estoy pensando en colorear/marcar con banderas la primera columna por fecha (p. ej., lo publicado hoy lleva una marca brillante, ayer una menos brillante, etc). 16:47 <nickless_head> jrandom: preferiblemente en algo bonito e importable como xml 16:48 <jrandom> nickless_head: wget -R http://localhost:7657/syndie/archive/ 16:48 <nickless_head> si la hay, podría escribir un exportador de Syndie a nntp 16:48 <jrandom> oh, si quieres exportar a nntp, usa rss a nntp 16:48 <nickless_head> jrandom: ok, probaré eso :) 16:48 <nickless_head> jrandom: ¿eso ya existe? ... rayos. ;) 16:49 <jrandom> también estoy pensando en añadir historiales de mensajes por usuario para permitir marcar mensajes como leídos/no leídos, pero probablemente no estará en 0.6.1.6 (a menos que alguien más lo implemente :) 16:49 <jrandom> o quizá un filtro nuevo en el árbol de hilos: mostrar solo mensajes publicados desde [hoy |v] 16:49 <jrandom> (o ayer, o hace 2 días) 16:50 <jrandom> nickless_head: http://www.methodize.org/nntprss/ 16:50 <nickless_head> jrandom: gracias 16:54 <jrandom> np 16:54 <Raccoon23> jrandom: así que tardaría un tiempo antes de poder implementarlo (quiero terminar primero las rutas restringidas), pero ¿qué piensas de un garlic routing (encaminamiento "garlic" de I2P) opcional de 1024 bits para los tunnels de servidor salientes? 16:54 <jrandom> sobrecarga tremenda: O(data) es>>> O(tunnels). si ahora tenemos problemas con O(tunnels), no hay manera de que podamos aspirar a O(data) 16:55 <Raccoon23> ¿seguimos teniendo problemas de CPU? mi router ha estado bastante bajo, pero no es que tenga una T1 por aquí.. 16:56 <jrandom> no todo el mundo tiene p4s ;) 16:56 <jrandom> oigo reportes de 8-15% de uso en máquinas lentas, pero eso se dispara feo bajo congestión 16:56 <jrandom> (hasta 100+%) 16:56 <+Complication> Sobre el consumo de CPU: curiosamente, Java en Mandriva 10.1 consume mucho menos que Java en Mandriva 2006. 16:56 <Raccoon23> sí, pero quienes no las tienen probablemente tampoco tienen T1 16:56 <Raccoon23> tampoco :) 16:57 <+Complication> Ambas ajustadas, 2006 tiene jbigi compilado localmente. 16:57 <jrandom> raro, Complication 16:57 <jrandom> ¿mismas revisiones de I2P? 16:57 <+Complication> En 2006 (Celeron 2.4) Java puede llegar al 20%. 16:58 <+Complication> En 10.1 no pasaba del 5%. 16:58 <+Complication> (Usualmente) 16:58 <+Complication> (usualmente == no en el arranque) 16:58 <+Complication> Mismas revisiones. 16:58 <+Complication> Casi el mismo Java también (_04 versus _05) 16:59 <+Complication> Me recuerda ajustar un poco más los demonios. Quizá alguno esté obstaculizando Java. 16:59 <+Complication> De alguna manera rara que no puedo identificar. 17:00 <+Complication> Pero sí, el Cel 300 se siente notablemente mejor. Podría haber sido la MTU adaptativa 17:01 <jrandom> ah, genial, sí, tenemos cosas chulas en camino :) 17:03 <+Complication> Me pregunto si habría una forma de superar los problemas de jbigi relacionados con libc en ciertas distros Linux? 17:03 <jrandom> sí, definitivamente, solo hay que reconstruir todos los jbigis 17:03 <jrandom> (no es libc, es libg++) 17:05 * Raccoon23 decide que no abandona sus sueños de garlic routing, pero esperará a que el rendimiento se estabilice... quizá 2.0 17:05 <+Complication> Oh, ¿crees que una reconstrucción adecuada ayudará? 17:05 <jrandom> Complication: sí, los errores de enlace de jcpuid son innecesarios, ya que jcpuid es realmente solo una llamada ASM (y no debería haberse implementado en C++ de todos modos ;) 17:06 <jrandom> Raccoon23: genial :) es algo que eventualmente podemos hacer también sobre la red en vivo, usando solo un tipo de mensaje I2NP diferente, anunciando la capacidad adecuada y filtrando en base a eso 17:06 <jrandom> (eventualmente) 17:07 <Raccoon23> ¿como un caps=S para CPU rápida? ;) 17:08 <jrandom> y caps=I para insane ;) 17:08 <jrandom> ok, ¿alguien más tiene algo para la reunión? 17:08 <Raccoon23> jaja 17:09 <Raccoon23> ¿qué piensas de la medida temporal de compartir claves a través de múltiples tunnels? ¿muy poca ganancia para el trabajo? 17:09 <jrandom> ¿por qué eso sería mejor que simplemente tener múltiples tunnels y enviar el mensaje por uno de los múltiples tunnels? 17:10 <jrandom> (y, eh, ¿no sería peor desde la perspectiva de seguridad y de anonimato?) 17:10 <Raccoon23> bueno, la idea es que los nodos no podrían saber qué tráfico era parte de un tunnel, de modo que si estuvieras ejecutando i2phex y un eepsite, y eligieras los mismos hosts para tus tunnels, el tráfico de ambos se mezclaría hasta donde los saltos pudieran ver 17:11 <Raccoon23> lo que debería dificultar los ataques de temporización 17:11 <jrandom> ah, uf, sí. eso añade una vinculación realmente mala 17:11 <jrandom> por eso pasamos a pools de tunnels por cliente en la 0.4 17:11 <Raccoon23> ¿explica? 17:11 <jrandom> i2ptunnel sí permite a la gente compartir pools, si quieren, compartiendo la misma destination 17:12 <jrandom> si mensajes de 2 clients bajan por un tunnel, sabes que ambos clients están controlados por la misma persona 17:12 <jrandom> s/clients/destinations/ 17:13 <Raccoon23> bueno, si se compartieran las claves, los primeros saltos podrían mezclarse, pero los leasesets serían separados.. 17:13 <Raccoon23> siendo los primeros saltos los peligrosos para los ataques de temporización de todas formas 17:13 <jrandom> aún permitiría un vector para vincular las dos destinations no vinculables 17:14 <jrandom> se podría hacer algo de munging para, con suerte, ofuscar la vinculación, pero estarían inherentemente vinculados. lo cual no es necesario, y es malo. 17:18 <Raccoon23> de vuelta a soñar con caps=SI, supongo :) 17:19 <jrandom> ah, bueno. ok, ¿alguien tiene algo más? 17:20 * jrandom se prepara para terminar 17:20 * jrandom cierra la reunión con un *baf*