Reunión de desarrolladores de I2P - 28 de diciembre de 2004

13:06 <@jrandom> 0) hola 13:06 <@jrandom> 1) 0.4.2.5 13:06 <@jrandom> 2) 0.5 13:06 <@jrandom> 3) ??? 13:06 <@jrandom> 0) hola 13:06 * jrandom saluda 13:06 <+postman> *saludo* 13:06 <ant> <jnymo> hola 13:06 <@jrandom> breves notas de estado publicadas en @ http://dev.i2p.net/pipermail/i2p/2004-December/000535.html 13:07 <@jrandom> pasando a 1) 0.4.2.5 13:07 <@jrandom> como se mencionó, las cosas están funcionando bastante bien 13:08 <+postman> sí, bastante impresionante 13:08 <+postman> ya no hay lease timeouts en mis sistemas en absoluto 13:08 <@jrandom> mucha gente ha visto lo que tú viste, jnymo, con 0 participating tunnels, en gran parte debido al aumento de eficiencia y selección de pares (donde ahora sabemos aprovecharnos de la máquina de postman ;) 13:08 <ant> <jnymo> yo también 13:08 <@jrandom> bien 13:08 <ant> <jnymo> y las eepsites están rápidas 13:09 <+postman> :) 13:09 <ant> <jnymo> gracias, postman :) 13:09 <+postman> totsl bw es 29kb / 30.1kb/s 13:09 <frosk> todos se sienten menos queridos, pero en realidad el cariño solo se está aprovechando de forma más eficiente 13:10 <ant> <jnymo> wow 13:10 <@jrandom> de puta madre, postman 13:10 <mule2> no creo que ese sea el ideal preferido. mejor que haya algo de tráfico a través de todos los nodos 13:10 <ant> <jnymo> podría soportarlo si la gente simplemente me quisiera :( 13:10 <+postman> sip 13:10 <mule2> como una especie de tráfico de cobertura 13:10 <@jrandom> mule2: es una cuestión de que nuestra carga sea mucho menor que la capacidad de la red 13:11 <@jrandom> no creo que podamos mantener la capacidad por encima de la carga por mucho tiempo 13:11 <ant> <jnymo> mule2, postman también actúa como mezclador.. así que es difícil saber adónde van tus paquetes después de que entran 13:11 <@jrandom> así que no me preocupa demasiado no enviar datos a través de pares más lentos 13:12 <mule2> probablemente una optimización menos perfecta sería buena para el anonimato 13:12 <@jrandom> por otro lado, también da incentivos para que más gente (implemente y) use i2pcontent, para que puedan hacer mirrors además de ganar tráfico de cobertura ;) 13:12 <jdot__> ¿es un problema de seguridad que un solo router maneje casi todos los tunnels? 13:13 <@jrandom> mule2: primero dejémoslo tan bien como podamos, luego podemos debatir hacer que sea peor de forma proactiva 13:13 <@jrandom> jdot__: no tenemos un router manejando todo el tráfico, pero sí estamos viendo que los routers con conexiones muy rápidas (colo, etc.) manejan más que los usuarios de dialup/DSL/cable 13:14 <@jrandom> además, el descenso de fallos de tunnel implica que cambiamos y exploramos menos 13:14 <mule2> quizá sería posible cierta distribución del tráfico, mientras estemos lejos de los límites de los routers 13:14 <@jrandom> correcto, el rechazo probabilístico de tunnel está en el router y se puede habilitar según los límites de ancho de banda del router 13:15 <ant> <jnymo> sí, pero un rendimiento tan alto en el nodo de postman hace más difícil analizar su nodo.. así que podría ser más seguro enviar a través de él que que todos los nodos hagan 1 KB/s.. 13:15 <@jrandom> (pero si postman no establece límites, no podemos rechazar basándonos en un % de eso ;) 13:15 <ant> <jnymo> agrupaciones de nodos más rápidos causan algo así como una estructura de cascada de mezclas, ¿no? 13:15 <@jrandom> sí, esa es una manera de verlo 13:15 <lektriK> ¿Puedo cerrar la ventana Start I2P? 13:15 * postman lamenta mucho NO limitar su ancho de banda 13:16 <@jrandom> lektriK: por desgracia, no realmente, a menos que inicies i2p como un servicio (Consulta http://localhost:7657/configservice.jsp) 13:16 <@jrandom> je, postman, no te preocupes, reduciremos la carga sobre tu router si/cuando alcancemos la capacidad de tu router 13:17 <lektriK> Ok, dice que el servicio se inició 13:17 <lektriK> ¿puedo cerrarla ahora? 13:17 <@jrandom> lektriK: no/sí - puedes apagar tu router y luego iniciarlo de nuevo vía start->run->"net start i2p" 13:18 <mule2> tal como está, unos pocos routers muy grandes podrían manejar todos los tunnels, eliminando todo el tráfico de cobertura de los demás routers. pero sigamos con eso después de la reunión. 13:18 <mule2> no quiero quejarme de que la red se comporte demasiado bien :) 13:18 <@jrandom> jeje 13:20 <@jrandom> habrá más exploración con 0.5, aunque hay cuestiones relacionadas con el anonimato al extenderse demasiado. habrá más detalles por resolver al respecto para 0.5 (y en el documento que podría estar listo la semana que viene como primer borrador) 13:21 <@jrandom> de todos modos, ¿alguien más tiene algo que plantear para 0.4.2.5? 13:21 <@jrandom> ¿o pasamos brevemente a 2) 0.5? 13:21 <+postman> avancemos 13:21 <ant> <jnymo> muy estable... sigamos 13:21 <@jrandom> consideren que ya hemos cambiado de tema 13:22 <@jrandom> 2) 0.5 13:22 <@jrandom> sí. todavía en desarrollo. más información cuando esté listo. 13:22 <ant> <Quadn-werk> Sir Arthur C. Clarke está vivo :P 13:22 <ant> <Quadn-werk> http://slashdot.org/articles/04/12/28/0120240.shtml?tid=99&tid=1 13:22 <ant> <jnymo> .5 es emocionante 13:22 <@jrandom> ok, eso es todo lo que tengo que decir al respecto: ¿alguien tiene preguntas / cosas para discutir sobre ello? 13:23 <@jrandom> sí, definitivamente hay algunos rediseños importantes en marcha, basados en lo que hemos aprendido en los últimos 16 meses 13:23 <@jrandom> (o mierda, 18) 13:23 <+postman> jrandom: entonces 0.5 empleará principalmente un nuevo sistema de gestión de tunnels? 13:23 <ant> <Quadn-werk> arg, espero no haber interrumpido la reunión :/ 13:23 <+postman> wow 13:23 <ant> <Quadn-werk> perdón je 13:23 <ant> <jnymo> je. tenía una sugerencia 13:24 <@jrandom> sí, postman, nueva gestión, agrupación y construcción 13:24 <+postman> quadn: mira lo que has hecho: tu pegado causó un netsplit (separación de red) :) 13:24 <@jrandom> ¡bastardo! 13:24 <ant> <Quadn-werk> ! 13:24 <@jrandom> ¿qué tal, jnymo? 13:24 <+postman> jrandom: ¿cada tunnel seguirá siendo un destino local separado? 13:25 <@jrandom> ¿huzzawuzzah? 13:25 <@jrandom> no habrá ningún cambio en i2ptunnel en 0.5 13:25 <+postman> jrandom: ok 13:25 <@jrandom> (al menos, no planeo ninguno) 13:26 <mule> ¿postman montando un ataque de intersección? 13:26 <ant> <jnymo> para quienes no están consiguiendo /nada/ de uso de ancho de banda.. ¿qué tal permitir que los routers construyan tunnels con ellos dentro.. como ABCABCA 13:26 <+postman> mule: no, fue culpa de quadn :) 13:26 <ant> <jnymo> y ese sería un tunnel ficticio 13:27 <@jrandom> jnymo: anunciar un router diciendo «hey, tengo ancho de banda de sobra, úsame» es un juego peligroso 13:27 <+postman> jrandom: ¿qué cuestiones abordarán entonces el rediseño (en pocas palabras) 13:27 <ant> <jnymo> no estoy seguro de haber querido decir eso, jrandom 13:27 <@jrandom> pero por lo que parece ahora, tendremos dos conjuntos de tunnels: los normales y los exploratorios, donde estos últimos se construyen a partir de pares no fallidos seleccionados aleatoriamente 13:28 <ant> <jnymo> jrandom: me refería a crear un tunnel ficticio y ponerme en medio de ese tunnel solo para simular algo de tráfico 13:29 <@jrandom> postman: hacer mucho más difícil correlacionar pares en un tunnel, permitir que los clientes elijan efectivamente la longitud de su tunnel de salida y proporcionar las opciones necesarias para abordar el ataque del predecesor (con varios compromisos) 13:29 <@jrandom> (oh, y mejorar el rendimiento eliminando muchas llamadas a modPow) 13:29 <+postman> ok gracias 13:29 <ant> <jnymo> postman: y los IDs de tunnel por salto es un tema importante 13:30 <+postman> ¿modpow? 13:30 <@jrandom> ah, jnymo. sí, hay mucho potencial para generar diversos tipos de tráfico chaff (de relleno) 13:30 <ant> <jnymo> de ese modo, dos nodos no adyacentes no pueden saber que están en el mismo tunnel, postman 13:30 <@jrandom> postman: exponenciación modular, gran uso de CPU y desperdicio de memoria 13:31 <ant> <jnymo> jrandom: k, guay 13:31 <+postman> k 13:31 <scintilla> jrandom, en cuanto a permitir que los clientes elijan la longitud del tunnel: ¿habrá algo para evitar que la gente la suba a 99 (o lo que sea)? 13:31 <ant> <jnymo> potencia de cpu 13:32 <@jrandom> cuando sea necesario podemos añadir hashcash, pero los tunnels excesivamente largos terminarán fallando de todos modos 13:32 <scintilla> ah, buen punto 13:32 <@jrandom> incluso podríamos añadir algún truco: exigir que un tunnel tenga un mensaje de tunnel válido circulando dentro de los 60 s de su creación para que sea «válido» 13:33 <@jrandom> (así que si el tunnel tuviera 20 saltos, les tomaría demasiado construir todos esos saltos) 13:33 <scintilla> es una gran idea: eso evitará que semejante ridiculez se prolongue por mucho tiempo 13:33 <@jrandom> pero eso es todo contra los hackers. los usuarios normales simplemente usarán la interfaz expuesta 13:34 <ant> <jnymo> bien, que limitarás en algún punto, ¿no? 13:34 <ant> <jnymo> llegaremos a más que el máximo de 2 como está ahora, ¿no? 13:34 <@jrandom> exacto, como el desplegable de # de saltos en /configclients.jsp o /i2ptunnel/edit.jsp 13:35 <@jrandom> oh, ¿pensé que el máximo era 3 ahora? ok, pero sí, habrá más de 2 disponible 13:35 <ant> <jnymo> 3 tunnels, 2 saltos 13:35 <@jrandom> ah 'k 13:35 <@jrandom> sí, 0.5 añadirá algunos ajustes nuevos importantes, como si se deben aleatorizar esas longitudes y cuánto aleatorizarlas, etc. 13:36 <frosk> el máximo es efectivamente 3 13:36 <ant> <jnymo> hmm 13:37 <@jrandom> ah, es 3 en /configclients 2 en i2ptunnel 13:37 <frosk> ¿0.5 sigue en camino para enero? 13:37 <ant> <jnymo> ah 13:37 <@jrandom> sí, frosk 13:37 <frosk> genial 13:37 <@jrandom> no me entretendré mucho más con la biblioteca de streaming, lo prometo ;) 13:37 <frosk> suena a mucho trabajo :) 13:38 <@jrandom> en realidad no es tan malo, la parte difícil es acertar con los algoritmos 13:38 <@jrandom> (detalles, detalletes ;) 13:39 <+postman> frosk: y ya está todo en papel 13:39 <+postman> :) 13:39 <ant> <jnymo> je 13:39 <frosk> cierto :) 13:39 <@jrandom> en su mayor parte, sí ;) 13:39 <@jrandom> ok, ¿alguien tiene algo más para 2) 0.5? 13:39 <ant> <jnymo> nada 13:39 <frosk> el zilcho 13:40 <@jrandom> 'k, pasemos al buen y viejo 3) ??? 13:40 <@jrandom> hola 13:40 <@jrandom> ¿alguien tiene algo más que quiera plantear? 13:41 <ant> <jnymo> postman: no hay inproxies SMTP/POP3 en i2pmail.org, ¿verdad? 13:41 <cat-a-puss> sigo viendo retrasos raros en el lado del cliente... 13:41 <+postman> hmm no 13:41 <frosk> aquí es donde entregaría la botella de vino de felicitación por un gran año de desarrollo ;) 13:41 <+postman> jnymo: POP3 solo está disponible para usuarios de i2p 13:41 <@jrandom> cat-a-puss: ah, me perdí esos mensajes cuando estuviste antes 13:41 <+postman> jnymo: SÍ hay un inproxy SMTP como MX para el dominio i2pmail.org 13:42 <@jrandom> frosk: salud 13:42 <ant> <jnymo> claro claro.. eso está bien.. 13:42 <cat-a-puss> Por ejemplo, puedo tener dos Destinations locales y cuando uno intenta conectarse al otro hay una demora y no está limitada por la CPU 13:42 <mule> cat-a-puss: ¿también entregas el cheque de bonificación? 13:42 * postman dona un buen whisky 13:42 <@jrandom> cat-a-puss: bien, viste un retraso de .5-1.0s, ¿cierto? 13:42 <cat-a-puss> mule: ¿qué? 13:42 <cat-a-puss> jrandom: sí 13:43 <@jrandom> cat-a-puss: perfectamente normal, parte del SYN diferido 13:43 <mule> perdón, el comentario fue de frosk 13:43 <ant> * jnymo saca ese vino de caja cutre 13:43 <mule> frosk: ¿también entregas el cheque de bonificación? 13:43 <@jrandom> (espera un poco para enviar el SYN y el ACK relacionado por si hay más datos que agrupar) 13:43 <scintilla> oh, para tu información, debería recibir pronto el libro con la especificación del algoritmo Fortuna... mientras tanto he estado experimentando con reunir entropía en Java sin destrozar una máquina 13:44 <@jrandom> ah, qué bien 13:44 <ant> <jnymo> mmm, alguien quería montar algunos ataques contra i2p 13:44 <ant> <jnymo> ¿quién era? 13:44 <@jrandom> connelly 13:44 <cat-a-puss> ¿Hay alguna forma de evitar eso, o simplemente tengo que intentar evitar conexiones de corta duración cuando pueda? 13:45 <ant> <jnymo> ¿alguna novedad sobre eso, jr? 13:45 <@jrandom> cat-a-puss: sí, hay algunas opciones que puedes pasar al crear el I2PSocketManager, déjame buscarlas 13:46 <@jrandom> jnymo: es un ataque de intersección a largo plazo, así que después de un tiempo tendrá datos para ayudar a identificar en qué routers están determinadas eepsites. seguro que nos escribirá un resumen con los datos cuando los tenga 13:46 <ant> <jnymo> scintalla: ¿qué es el algoritmo Fortuna? 13:46 <ant> <jnymo> jrandom: aight 13:48 <@jrandom> cat-a-puss: i2p.streaming.initialResendDelay=50 i2p.streaming.connectDelay=100 13:48 <scintilla> es un generador de números pseudoaleatorios criptográficamente seguro... algo absolutamente esencial para un cifrado confiable 13:48 <jdot__> ¿alguien se ha ofrecido voluntario para ese ataque ya? 13:48 <@jrandom> cat-a-puss: luego asegúrate de hacer flush() después de write() en el I2PSocket 13:48 <@jrandom> jdot__: sí, tiene 7 sitios voluntarios 13:48 <cat-a-puss> jrandom: ok 13:49 <ant> <jnymo> con respecto al gran debate sobre los nombres.. 13:49 <ant> * jnymo se ríe por lo bajo 13:49 <@jrandom> oh y i2p.streaming.initialAckDelay=1000 13:49 <@jrandom> o incluso =100 13:49 * jrandom le lanza barro a jnymo 13:50 <ant> <jnymo> de hecho trabajo con x500 y mi trabajo me permite tener winSevers gratis 13:50 <ant> <jnymo> así que, quizá configure un DNS central para fines de prueba en un mes o dos 13:51 <@jrandom> heh, tener un servidor de nombres centralizado alojado en un .mil sería jodidamente hilarante 13:51 <ant> <jnymo> aunque meter direcciones de i2p en winserver puede no ser trivial.. no sé 13:51 <ant> <jnymo> heh.. dnsalias es la clave 13:52 <@jrandom> nano ha hecho un trabajo muy bueno, integrando dnsjava con i2p 13:52 <ant> <jnymo> ooooh 13:53 <@jrandom> echen un vistazo a nano.i2p para más detalles 13:53 <ant> <jnymo> y nadie iba a decírmelo.. ah, gracias 13:53 <@jrandom> pero, como se mencionó la última vez, la gente debería publicar sus ideas y opiniones sobre los nombres en la wiki 13:54 <@jrandom> ok, ¿alguien más tiene algo para plantear en la reunión? 13:55 <ant> <jnymo> no 13:57 <@jrandom> ok, en ese caso 13:57 * jrandom se prepara 13:57 * jrandom *baf* cierra la reunión