Reunión de desarrolladores de I2P - 1 de febrero de 2005

13:06 <jrandom> 0) hola 13:06 <jrandom> 1) estado 0.5 13:06 <jrandom> 2) nntp 13:06 <jrandom> 3) propuestas técnicas 13:06 <jrandom> 4) ??? 13:06 <jrandom> 0) hola 13:06 * jrandom saluda 13:06 <+postman> hola jr 13:07 * postman saluda 13:07 <jrandom> w3wt hay vida ahí fuera :) 13:07 <jrandom> notas semanales de estado publicadas en @ http://i2p.net/pipermail/i2p/2005-February/000561.html 13:07 <ant> * dm saluda 13:08 <jrandom> mientras leen ese email, podemos pasar a 1) estado 0.5 13:08 <MANCOM> hola 13:09 <jrandom> mucho progreso durante la última semana, toda la nueva cripto está integrada y probada, y ahora toda la operación de tunnel del router se hace a través de los nuevos pools de tunnel 13:10 <jrandom> todavía hay algunas partes del router que recorté durante la actualización, como la integración para solicitar leases desde los clientes o probar periódicamente los tunnels, pero no deberían ser demasiado difíciles 13:11 <jrandom> el código no es compatible con la red en vivo, y está en una rama separada en cvs, así que la gente aún puede sacar cvs HEAD y trabajar con lo último 13:12 <+polecat> Dook Por fin miré esa página, y aún no entiendo cómo podemos evitar la redundancia al estilo mixmaster para protegernos de ataques de detección de tunnels. 13:12 <+protokol> yey 13:12 <+polecat> Aunque me imagino que funciona muy bien. :) 13:12 <+protokol> ¿vas a meter alguna otra cosa chula que rompa la compatibilidad? 13:13 <+protokol> el pool de tunnel tiene que ver con los hilos, ¿verdad? 13:13 <jrandom> polecat: no verificamos en cada salto, pero tenemos un tamaño de mensaje fijo para prevenir etiquetado útil (y todo va cifrado en cada salto) 13:14 <jrandom> protokol: estoy considerando http://www.i2p/todo#sessionTag 13:14 <+polecat> Entonces, ¿cómo evitar que múltiples saltos se pasen mensajes falsos y causen un DoS? 13:15 <jrandom> pero no, los pools no son el tema de hilos; los pools solo nos permiten gestionar de forma segura los tunnels para que no obtengamos esos mensajes "Lease expired" y podamos configurar la longitud por cliente 13:15 <jrandom> polecat: fallarán en el extremo, y el creador detectará el fallo y dejará de usarlo 13:16 <+protokol> jrandom: aparte de cualquier dificultad, creo que cualquier función que mejore el anonimato debería entrar cuanto antes 13:16 <+polecat> ¡w00t! ¡PRNG sincronizado! ¡La primera aplicación que he visto de esa idea! 13:17 <ant> <dm> ¿qué significa PRNG? 13:17 <ant> <dm> si se puede preguntar :) 13:18 <jrandom> protokol: de acuerdo, para eso es la 0.5 :) no hay otras “victorias rápidas” a nivel de i2p, pero siempre hay mejoras que se pueden hacer en las capas de app y de biblioteca (p. ej., filtrado de i2ptunnel, etc.) 13:18 <jrandom> dm: Generador de Números Pseudoaleatorios 13:18 <ant> <dm> genial, gracias 13:20 <+protokol> entonces, ¿dices que después de esto será sobre todo ajustar velocidad y fiabilidad? 13:21 <+protokol> y por qué IRC ha estado yendo tan mal últimamente 13:21 <jrandom> protokol: antes de 2.0 para el núcleo y el router, sí 13:21 <+protokol> no puedo conectarme al servidor de ducks 13:21 <+protokol> yey 13:21 * jrandom no sabe; hemos visto quizá 5 desconexiones masivas en el último día más o menos, quizá algo del lado del servidor 13:22 <jrandom> hay mucho que ajustar, especialmente en la biblioteca de streaming después de desplegar la 0.5 13:23 <+polecat> Todo ese tema de UDP. 13:24 <jrandom> ah, la biblioteca de streaming no debería necesitar cambios para la versión 0.6, más allá de los que hagamos para la revisión 0.5 13:25 <jrandom> ok, eso es todo lo que tengo que comentar respecto al estado de la 0.5 - ¿alguien tiene algo más al respecto? 13:27 <jrandom> si no, pasamos a 2) nntp 13:27 <jrandom> nntp.fr.i2p está en marcha, échale un vistazo :) 13:28 <jrandom> no parece que LonelyGuy esté por aquí, pero se le puede contactar en http://fr.i2p/. también hay instrucciones de configuración para slrn en mi blog, y jdot descubrió que thunderbird puede ser bastante seguro (aunque no sé qué configuración usó jdot) 13:30 <smeghead> ¿LonelyGuy? :) 13:30 <cervantes> ¿alguien probó también Pan? 13:30 <jrandom> ha estado por aquí de vez en cuando 13:30 <+polecat> Yo no perdería demasiado tiempo con nntp, pero mientras tenga control de acceso gestionado por el usuario está bien. 13:30 <jrandom> (lonelyguy, no Pan ;) 13:30 <smeghead> pensé que su nombre era LazyGuy 13:31 <jrandom> ¿es LazyGuy? 13:31 <jrandom> sé que hemos tenido ambos... 13:31 <jrandom> tienes razón, lazyguy 13:31 * jrandom ¡se apuñala a sí mismo! 13:31 <jrandom> cervantes: creo que LazyGuy lo probó, aunque no sé la configuración ni el resultado 13:32 <cervantes> ¿Pensé que era LimeyGuy? 13:33 * jrandom aguarda los comentarios de SnarkeyGuy 13:33 <smeghead> es francés 13:35 <jrandom> ok, no tengo nada más que añadir además de eso, así que, a menos que alguien tenga preguntas, pasamos a 3) propuestas técnicas 13:35 <cervantes> smeghead: estás pensando en ParesseuxGuy 13:36 <jrandom> orion ha reunido unas buenas descripciones e ideas para algunos de los temas más complicados en 1) estado 0.5 13:36 <jrandom> 2) nntp 13:36 <jrandom> 3) propuestas técnicas 13:36 <jrandom> erg 13:36 <jrandom> maldito ^C^V 13:36 <jrandom> arriba en http://ugha.i2p/I2pRfc, eso es 13:37 <jrandom> así que la próxima vez que quieran discutir que tienen una idea de nombres brutal, vayan a http://ugha.i2p/I2pRfc/I2pRfc0001ResourceNameMetadata 13:39 <jrandom> realmente no tengo mucho más que añadir aparte de eso. es una wiki, pónganse a wikear :) 13:39 <+polecat> Bien. 13:39 <+postman> jrandom: ohh, genial creo que necesito añadir unas cuantas ... 13:40 <jrandom> genial, postman, pensé que lo harías :) hay una plantilla ahí arriba para nuevas 13:41 <+postman> jrandom: dame un poquito de tiempo (primero lo primero) pero contribuiré :) 13:41 <jrandom> w3rd 13:41 <+polecat> ResourceNameMetadata, formarlo es relativamente trivial. El truco es averiguar cómo /obtenerlo/ de otras personas. 13:42 <jrandom> polecat: como dijo postman, primero lo primero. 13:42 <+polecat> Pero si tuviera una solución, estaría wikieando ahora, ¿no? :) 13:42 <jrandom> jeje 13:42 <jrandom> discutir las compensaciones de /cómo/ distribuir antes de decidir /qué/ distribuir es prematuro 13:43 <jrandom> aun así, hay espacio para muchas, así que cualquiera debería sentirse libre de publicar ideas que aún no estén completamente trabajadas (aunque las totalmente funcionales con implementaciones también molarían ;) 13:44 <jrandom> ok, a menos que haya algo más sobre eso, quizá podamos pasar al buen viejo 4) ??? 13:44 <jrandom> ¿alguien tiene algo más que sacar? 13:45 <jrandom> smeghead: ¿hay algo que la gente pueda hacer para ayudar a resolver los problemas de gcj, o está bloqueado por su prng? 13:46 <+polecat> Qué distribuir es solo un diccionario firmado. Así de simple. 13:46 <+polecat> Sí, probablemente una buena idea. 13:46 <+polecat> Todavía estoy trabajando en el esqueleto de mi cliente bt de i2p, aunque agradecería mucho consejos en cualquier etapa. 13:46 <smeghead> creo que he encontrado una solución 13:46 <smeghead> en gnu crypto, hay una impl. de Fortuna desde el verano pasado 13:46 <jrandom> qué bien, polecat 13:46 <jrandom> oh, qué bien, smeghead 13:46 <+polecat> smeghead: Je, los $150 son prácticamente tuyos. 13:47 <smeghead> puedo armar un gnu-crypto.jar que contenga solo las clases necesarias para Fortuna 13:47 <+polecat> Mis notas de trabajo hasta ahora están en http://polecat.i2p/bittorrent.plan.doc 13:47 <smeghead> si distribuyéramos todo el gnu-crypto.jar son unos 500 KB, demasiado grande la verdad 13:47 <+polecat> No dejes que el .doc te asuste, es text/plain. 13:48 <+polecat> ¿Fortuna no usa SecureRandom para hacer cosas aleatorias? 13:48 <jrandom> vaya, sí, 500 KB es un poco excesivo, pero echando un vistazo a http://www.gnu.org/software/gnu-crypto/, parece algo que podríamos integrar de forma segura (ya que solo enlazaríamos a ello, no lo modificaríamos) 13:48 <smeghead> SecureRandom nunca fue el problema 13:48 <jrandom> polecat: fortuna /alimenta/ secureRandom :) 13:49 <smeghead> jrandom: sería fácil hacer un .jar personalizado, probablemente alrededor de 50 KB 13:49 <smeghead> (estimación aproximada, ojo) 13:49 <smeghead> podría hacer un build de ant para empaquetarlo a medida incluso bajo demanda 13:50 <jrandom> smeghead: ¿quieres integrarlo en i2p/apps/fortuna/ ? 13:50 <smeghead> lo haré 13:50 <jrandom> ¡genial! 13:51 <smeghead> después de eso, suponiendo que gcj finalmente escupa números aleatorios, probablemente habrá más pruebas de varias funcionalidades de i2p 13:51 <+polecat> ¿Cuál es la licencia? 13:51 <jrandom> entonces podemos hacer algo de vudú en net.i2p.util.RandomSource para usar SecureRandom o fortuna (si se encuentra, etc.) 13:51 <smeghead> lgpl 13:51 <+polecat> Genial. 13:51 <smeghead> cierto, SecureRandom sería innecesario 13:52 <jrandom> sí, aún hay mucho por hacer para gcjearlo, pero es un gran comienzo 13:52 <jrandom> en los perfiles que he hecho en la red en vivo, resembrar el PRNG ocupa una buena parte de la carga de CPU 13:52 <smeghead> si alguien está interesado en escribir pruebas 13:52 <smeghead> pero probablemente no tengo que terminar esa frase 13:52 <jrandom> jeje 13:53 <smeghead> preguntaré al mantenedor de gnu crypto sobre esta impl., porque busqué en Google información al respecto y revisé los archivos de su lista de correo y no hay ni una palabra sobre ello 13:54 <smeghead> y sus registros de commits de cvs tampoco son muy esclarecedores 13:54 <jrandom> 'k buena idea 13:54 <smeghead> espero que funcione 13:54 <smeghead> está en el cvs de kaffe, por cierto 13:54 <smeghead> tu versión incluso debería tenerlo 13:55 <jrandom> hmm, ah, sí, del import de gnu-crypto 13:55 <smeghead> gnu.security.prng.Fortuna 13:55 <jrandom> el proveedor 'kaffe' todavía usa su viejo sha1prng iirc 13:55 <jrandom> genial 13:56 <MANCOM> ¿cuál es el estado de lo de sam para .net? ¿conviene empezar a meterse o se esperan cambios importantes? 13:56 <smeghead> MANCOM: necesita pruebas, escribiré algunas pruebas unitarias pronto 13:56 <smeghead> este tema de gcj lo ha dejado un poco en pausa 13:57 <smeghead> MANCOM: no espero que haya cambios en la API en absoluto, así que debería ser seguro programar contra ella 13:58 <smeghead> es probable que haya cambios detrás de la API, pero tú como cliente no necesitas saber eso :) 13:59 <MANCOM> :) 13:59 <jrandom> puede haber algunas actualizaciones posteriores que sean relevantes si construyes apps que hagan transferencia masiva 14:00 <jrandom> pero si solo transfieres decenas de KB a la vez, debería estar bien 14:00 <smeghead> ok, si la API del cliente Java cambia, entonces la de sam-sharp también :) 14:01 <MANCOM> no puedo discutir eso 14:02 <jrandom> ok, ¿alguien tiene algo más que tratar en la reunión? 14:02 * cervantes baja el Big Ben al canal 14:03 <+DrWoo> nota: buen trabajo jrandom 14:03 <smeghead> buen juego de palabras, cervantes 14:03 * jrandom gime 14:04 <MANCOM> leí que no quieren promocionar i2p demasiado antes de la v0.5, ¿es cierto? 14:04 <jrandom> MANCOM: antes de la 0.6. sí 14:04 <jrandom> MANCOM: 0.5 mejorará el anonimato y ayudará a los usuarios a controlar mejor su rendimiento. 0.6 permitirá que miles+ de usuarios concurrentes operen de forma segura 14:04 <MANCOM> ah. 0.6. ok. 14:05 <jrandom> gracias doc, mucho progreso :) 14:05 <+polecat> Whee, con ganas de la 0.6... 14:05 <+DrWoo> :) 14:06 <jrandom> de acuerdo, polecat, de acuerdo :) 14:06 * jrandom se prepara 14:06 * jrandom cierra la reunión con un *baf*