Reunión de desarrolladores de I2P - 24 de febrero de 2004

[22:00] <jrand0m> 0) hola [22:00] <jrand0m> 1) 0.2.4.2/0.2.5 [22:00] <jrand0m> 2) documentación [22:00] <jrand0m> 3) ??? [22:00] <jrand0m> 0) hola [22:00] <human> hola [22:00] * jrand0m saluda al iip-ircd recién reiniciado :) [22:01] <jrand0m> (y, eh, a ti también :) [22:01] <jrand0m> las notas semanales de estado (en las que nos basamos) están en http://i2p.dnsalias.net/pipermail/i2p/2004-February/000148.html [22:01] <jrand0m> (y publicadas en la lista de correo, obviamente) [22:01] <jrand0m> 1) 0.2.4.2/0.2.5 [22:02] <jrand0m> El equipo de desarrollo ha avanzado bien con la versión 0.2.5, que permitirá y aprovechará tanto tunnels de 2 o más saltos como clientes con múltiples tunnels de entrada [22:03] <jrand0m> la funcionalidad clave que aportará será una mayor fiabilidad y anonimato efectivo [22:04] <jrand0m> los tunnels de 1 salto que tenemos ahora te exponen a un ataque estadístico por un oponente activo, pero con la 0.2.5 podrás determinar la longitud de tus propios saltos (y aumentar el valor predeterminado a 2), haciendo el ataque estadístico mucho más complejo [22:06] <jrand0m> también encontré un par de bugs en el proceso de envío del cliente y en la base de datos de la red que podrían explicar algo de la última inestabilidad [22:06] <jrand0m> (correcciones en curso) [22:07] <jrand0m> como nota al margen, creo que la hoja de ruta [http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap] sigue reflejando con precisión el calendario de desarrollo [22:07] * mihi se ha unido a #i2p [22:07] <jrand0m> hola mihi [22:07] * protocol ha salido de IRC (tiempo de espera de ping agotado) [22:07] <jrand0m> ok, eso es todo con el estado de desarrollo del router, pasamos a 2) documentación [22:07] * human quisiera decir que encuentra I2P inutilizable desde 0.2.4 (parece comportarse mucho peor que en la época de la 0.2.3, al menos en mi PC) [22:07] <jrand0m> hm [22:08] <human> quizá podríamos hablar de ello después de la reunión... [22:08] <jrand0m> ¿en términos de fiabilidad, latencia, CPU, ancho de banda? [22:08] * protocol se ha unido a #i2p [22:08] <mihi> hola jrand0m, hola a todos [22:08] <human> jrand0m: no puedo alcanzar ningún eepsite ni servicio de I2P (salvo pocas excepciones temporales) [22:08] * mihi secunda a human [22:09] <jrand0m> la mayoría de los eepsites están caídos - duck, baffled, madman2003 son los que más han estado en línea últimamente [22:09] <human> jrand0m: no puedo alcanzarles, ni a irc.*.i2p [22:09] <jrand0m> squid lo uso constantemente para toda mi navegación web - ¿no puedes usar eso? [22:09] <human> no [22:09] <jrand0m> hm [22:10] <madman-away> bueno, un tiempo de actividad de unas 8 horas diarias para mi sitio i2p [22:10] <human> jrand0m: podríamos hablarlo después de la reunión, no quiero monopolizar la discusión :-) [22:10] * madman-away ahora se llama madman2003 [22:10] <mihi> podría ser también un problema de mi proveedor, http://babelfish.altavista.com/babelfish/urltrurl?tt=url&url=http%3A%2F%2Fwww.expressnet.de%2Fnews%2Fnews.php&lp=de_en :( [22:10] <Janonymous> yo también [22:10] <human> jrand0m: solo para señalar que parecen existir algunos problemas (que antes no se mostraban) [22:10] <Janonymous> el mío debería estar arriba ahora [22:11] <madman2003> ¿qué destino? [22:11] <jrand0m> bien, ok, si en fiabilidad vamos hacia atrás tenemos que abordar eso antes de pasar a 0.2.5 [22:11] * mihi odia el inglés de babelfish :( [22:11] <jrand0m> je [22:12] <jrand0m> (bueno, al menos acertó la frase Thank you for your understanding.) [22:12] <human> debería investigarse... también pensé en un problema del ISP, pero el problema parece constante desde la 0.2.4 (y no parece ocurrir con otros servicios de red) [22:12] <jrand0m> 0.2.4.0 fue una mierda, igual que 0.2.4.1 [22:12] * wilde se ha unido a #i2p [22:13] <human> lo sé, y me preocupa... [22:13] <wilde> hola i2p [22:13] <jrand0m> hola wilde [22:13] <madman2003> una cosa que noté es que los tunnels tienden a volverse inestables con más frecuencia [22:13] <human> 0.2.4.2 no cambió demasiado (al menos para mí) [22:13] <human> s/ i / it / [22:14] <jrand0m> madman2003> eso se debe fácilmente a routers que se encienden y apagan (lo cual será un gran problema hasta la 0.3) [22:14] <jrand0m> hmm ok [22:14] <wilde> jrand0m: ¿eso significa que deberíamos evitar ejecutar transitorios por ahora? [22:15] * mihi ha salido de IRC (tiempo de espera de ping agotado) [22:15] <jrand0m> hm, creo que habrá correcciones significativas en 0.2.5, pero podemos posponer pasar de 0.2.5 a 0.3 hasta que se resuelvan los problemas de fiabilidad. [22:16] <jrand0m> wilde> no me gusta el término transitorios, me hace pensar en otro proyecto que trata routers poco fiables de forma diferente a los fiables. tratamos a todos los routers por igual (y necesitamos hacerlo, por anonimato) [22:16] <jrand0m> pero mientras los routers estén generalmente arriba o generalmente abajo, están bien [22:17] <jrand0m> (solo no arriba 10 minutos, abajo 10 minutos, arriba 30, abajo 30, etc.) [22:17] <madman2003> tengo una petición: una opción para que el router (y los tunnels) se restablezcan [22:17] <baffled> ¿i2p es una organización de igualdad de oportunidades para routers? [22:17] <jrand0m> je baffled [22:18] <jrand0m> ¿que el router se restablezca? ¿tu router sigue apagándose? [22:18] <madman2003> me refiero a reconectar todo [22:18] <madman2003> una especie de reinicio en caliente del router [22:18] <madman2003> sin molestar a los otros routers [22:18] <madman2003> (tengo que reiniciar el router y los tunnels a menudo) [22:18] <jrand0m> puedes reiniciar con seguridad tus apps cliente (p. ej., i2ptunnel eepproxy, etc.) sin tocar el router [22:19] <jrand0m> nunca deberías necesitar reiniciar tu router. [22:19] <jrand0m> (casi toda la configuración se actualiza dinámicamente) [22:19] * Trix se ha unido a #i2p [22:19] <jrand0m> hola Trix [22:19] <Trix> hola [22:19] <madman2003> normalmente reiniciar los tunnels hace el apaño [22:21] <jrand0m> solo hay una situación en la que eso sea técnicamente necesario (caducidades de lease antiguas en el leaseSet de un cliente, que ocurrían aleatoriamente al arrancar), y eso se ha corregido en CVS, así que no deberías necesitarlo. [22:22] <jrand0m> (de hecho, reiniciar tunnels puede causar problemas temporales, dependiendo del tipo de tunnel) [22:22] <madman2003> a veces simplemente no sé si estoy causando problemas yo o si es otra persona [22:22] <jrand0m> si la consola de tu router no tiene ninguna de las advertencias en rojo, es la red (o alguien más) [22:22] * jnk se ha unido a #i2p [22:23] <jrand0m> la paciencia arregla más bugs actuales de i2p que los reinicios ;) [22:24] <jrand0m> pero tendremos otra serie de versiones de corrección de bugs después de 0.2.5 [22:24] <jrand0m> (como testnet, solo que sin las restricciones sobre la base de usuarios) [22:25] <jrand0m> (y, como siempre, cuando algo se rompa, se agradecen los logs :) [22:25] <jrand0m> en fin, pasemos a 2) documentación [22:26] <jrand0m> como se publicó en http://i2p.net/pipermail/i2p/2004-February/000147.html ha habido nuevos documentos de visión general [22:27] <jrand0m> agradecería algunas críticas para mejorarlos, ya que esas páginas a las que se hace referencia van a convertirse esencialmente en el punto de partida principal para aprender sobre I2P [22:28] <madman2003> los leí y espero que tengas razón sobre la posibilidad de reducir de forma segura la cantidad de cripto [22:29] <wilde> ¿capas de cripto o número de bits? [22:29] <jrand0m> no estoy convencido de que la cripto sea el cuello de botella, pero es una posibilidad [22:30] <jrand0m> no podríamos reducir las capas de forma segura, pero podríamos usar diferentes niveles de cripto en diferentes capas, en lugar de reutilizar el mismo código para todo [22:30] <madman2003> el problema es encontrar el camino [22:30] <jrand0m> ¿hmm? [22:31] <madman2003> un camino estático suele encontrarse bien [22:31] <madman2003> uno más dinámico es más difícil de establecer [22:32] <madman2003> (estoy hablando de la incapacidad de manejar adecuadamente cuando los routers se caen) [22:32] <jrand0m> ah, pensé que hablabas de cripto [22:32] <jrand0m> será relativamente fácil manejar routers poco fiables, es solo código de la 0.3 [22:33] * jrand0m tiene ~30 páginas de notas sobre diferentes técnicas; todo es viable, solo que hay mucho por hacer [22:33] * protocol ha salido de IRC [22:34] <madman2003> quizás una idea sea tener rutas de respaldo listas [22:34] <madman2003> redundancia de tunnel [22:34] <jrand0m> exacto, eso es 0.2.5: múltiples leases [22:35] <jrand0m> (lease == declaración de que se puede alcanzar un destino a través de un tunnel específico) [22:35] <madman2003> estaré esperando eso :) [22:36] <jrand0m> w3rd [22:37] <jrand0m> bueno, si alguien tiene sugerencias para mejorar la documentación, siéntase libre de editar el wiki, escribir a la lista o enviarme un correo [22:38] <jrand0m> ok, avanzando a buen ritmo hacia 3) ??? [22:38] <jrand0m> ¿algo que la gente quiera plantear y discutir? [22:39] <DrWoo> las patatas son jodidamente baratas pero las patatas fritas son caras, ¿qué pasa con eso? [22:39] <DrWoo> :) [22:39] <jrand0m> ¡es una conspiración! [22:40] * DrWoo piensa que jrand0m tiene la respuesta para casi todo :) [22:40] <jrand0m> por supuesto, puedes culpar de cualquier cosa a las conspiraciones. [22:40] <jrand0m> ok [22:40] <wilde> ¿Stego? [22:40] * human acepta sugerencias sobre cómo exponer funcionalidad orientada a mensajes tipo I2CP a aplicaciones no Java [22:41] <wilde> cómo implementará I2P Stego para que un portscan normal no revele nada [22:41] <wilde> ni siquiera bytes aleatorios [22:41] * human puede sonar (¿suena?) repetitivo... está pensando en VPNs sobre I2P con http://openvpn.sf.net/ [22:41] <jrand0m> bueno, por ejemplo, PHTTP. [22:42] <jrand0m> openvpn sí que parece muy interesante: no me había dado cuenta de que tun/tap tenía versiones para Windows [22:42] <jrand0m> un puente de sockets orientado a mensajes simple para I2CP debería ser muy fácil [22:43] <wilde> ¿No lo llama freenet 'Silent Bob', cuando el nodo se calla si no das el golpe secreto (conocer el ID del router) [22:43] * madman2003 ha salido de IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12)) [22:43] <baffled> bueno, como de costumbre tengo otra cita en 15m, así que me pondré al día más tarde. [22:43] <jrand0m> exacto, si quisiéramos integrar con un servidor web/etc para hacer Silent Bob, podríamos [22:43] <jrand0m> genial, hasta luego baffled [22:44] <jrand0m> (pero Silent Bob no evita la detección por portscan, solo hace que parezca otro servicio) [22:44] <wilde> preferiría que gente al azar o los ISP no me hicieran portscan y encontraran puertos abiertos [22:44] <wilde> ok [22:44] <human> ok, trabajaré en ello cuando I2P vuelva a funcionar en mi PC :-) [22:44] <jrand0m> UDP también funcionaría [22:44] <jrand0m> :) human [22:45] * kaji se ha unido a #i2p [22:46] <jrand0m> no me había dado cuenta de que la fiabilidad había bajado tanto; pasaremos por suficientes iteraciones después de la 0.2.5 para recuperarla para ti, human [22:46] <wilde> ¿hay alguna forma de ocultar un puerto abierto a un programa Java, sin tocar el SO o el firewall? [22:46] <human> ¡w00t! [22:47] <jrand0m> ¿te refieres a tener un socket TCP en escucha que no pueda ser encontrado por un portscan? no, no directamente desde Java. [22:47] <wilde> ok [22:48] <jrand0m> (ni siquiera sé cómo hacer eso en otros lenguajes) [22:48] <jrand0m> udp probablemente sería la mejor manera de hacerlo [22:48] * human invita a la gente a intentar hacer telnet a human.i2p (servidor de eco TCP en tunnel) y escribir algo [22:48] <wilde> eso sería quizá un pequeño programa en C filtrando y reenviando a otro puerto [22:49] * kaji_ se ha unido a #i2p [22:49] <jrand0m> si acepta conexiones TCP, ya es demasiado tarde, si entiendo bien tu preocupación. [22:49] <Janonymous> ¿cómo haces telnet? [22:49] <kaji_> por fin [22:50] <kaji_> eso tomó una eternidad, la usabilidad de iip apesta ahora mismo [22:50] * kaji ha salido de IRC (Ping timeout) [22:51] <duck> si te preocupan los puertos abiertos, podrías usar rTCP / PHTTP / lo que sea, ¿no? [22:51] <Janonymous> maldita sea... oye, jr, ¿esos documentos nuevos son accesibles desde la página principal de i2p? [22:51] <human> Janonymous: java -jar lib/i2ptunnel.jar -nogui -e "config localhost 7654" -e "client 12221 human.i2p" [22:51] <jrand0m> no, Janonymous, solo desde los enlaces de ese correo [22:51] <human> Janonymous: luego telnet localhost 12221 [22:51] <jrand0m> duck> correcto [22:52] <Janonymous> ok [22:52] <duck> (por supuesto, lo que sea puede ser un transporte SilentBob/stealth/stego) [22:52] <jrand0m> human> Envío de mensaje falló después de 61226ms con 391 bytes [22:53] <human> ¿y eso significa...? [22:53] <jrand0m> significa que no puedo alcanzar tu echo [22:53] <duck> -nogui está deprecado :) [22:53] <jrand0m> ¿puedes alcanzar duck.i2p? [22:54] <wilde> da miedo, busqué en Google rtcp: http://dret.net/glossary/rtcp [22:54] <jrand0m> sí, rtcp ya está cogido :/ [22:54] <human> lo estoy intentando, pero no puedo alcanzar duck.i2p desde hace muuuucho tiempo... [22:54] <jrand0m> wilde> http://wiki.invisiblenet.net/iip-wiki?RelayingTCP [22:54] <wilde> "Wilde's WWW Online Glossary" [22:55] <jrand0m> jeje oh sí :) [22:55] <jrand0m> human> eso es definitivamente algo malo, ya que suele estar arriba casi siempre; ¿podrías reenviarme tu log-*.txt? [22:56] <human> Iniciado el: Tue Feb 24 10:21:22 GMT 2004 [22:56] <human> Versión: Router: 0.2.4.2 / SDK: 0.2.4.2 [22:56] <human> Ancho de banda usado: 56096295 bytes enviados, 34308394 bytes recibidos (prom 1.44KBps enviados 0.88KBps recibidos) [22:56] <human> ok, logs en camino por meshmx [22:56] <jrand0m> gracias [22:56] <jrand0m> ok, ¿alguien tiene algo más que plantear? [22:58] * jrand0m va terminando [22:58] * jrand0m *baf*s cierra la reunión