Reunión de desarrolladores de I2P - 11 de octubre de 2005

16:29 <jrandom> 0) hola 16:29 <jrandom> 1) 0.6.1.2 16:29 <jrandom> 2) I2PTunnelIRCClient 16:29 <jrandom> 3) Syndie 16:29 <jrandom> 4) I2Phex 16:29 <jrandom> 5) Stego y darknets (re: flamewar) 16:29 <jrandom> 5) ??? 16:29 <jrandom> 0) hola 16:29 <@cervantes> (6) 16:29 <+postman> ¿quieres decir 6)? 16:29 <jrandom> sí, no sé contar ;) 16:30 * postman choca los cinco con cervantes 16:30 <jrandom> notas de estado semanales publicadas @ http://dev.i2p.net/pipermail/i2p/2005-October/000990.html 16:30 <wiht> Las preguntas deberían ser el punto 6. 16:30 <jrandom> como llego 30 minutos tarde, seguro que ya han leído esas notas, así que pongámonos en marcha ;) 16:31 <jrandom> 1) 0.6.1.2 16:31 <@cervantes> 6) Discutir el pésimo sentido del momento del compañero de piso de jrandom 16:31 <jrandom> *ejem* ;) 16:31 <jrandom> ok, como se mencionó en el correo, la versión 0.6.1.2 parece ir bastante bien 16:32 <jrandom> hemos encontrado el bug que mantenía los servidores de IRC en una build más antigua, y ahora también están al día (w00t!) 16:32 <+postman> :) 16:32 <wiht> Hablando de eso, en la netDB en la consola del router, ¿sería posible listar la tabla con los routers y sus versiones en la parte superior de la página? 16:33 <jrandom> el número de routers por versión, ¿no? claro, eso se podría hacer bastante fácil, quizá integrarlo en la tabla peers.jsp (mostrando la versión por par) y una tabla nueva al final? 16:34 <jrandom> es agradable ver 9 versiones funcionando bien juntas, aunque por supuesto las más nuevas funcionan mejor 16:35 <jrandom> ok, ¿alguien más tiene algo que comentar respecto a 1) 0.6.1.2? 16:35 <+postman> uno de mis routers muestra 1080 conocidos 16:35 <jrandom> caray 16:35 <+postman> creo que esto está un poco fuera de rango? 16:35 <jrandom> ¿eso es en 0.6.1.2? 16:35 <+postman> sí, creo que sí 16:36 <jrandom> hmm, sí, eso es... un poco alto. yo estoy viendo como la mitad ahora mismo 16:36 <+Complication> De forma sostenida, unos 400 por aquí 16:37 <+bar> igual por aquí 16:37 <wiht> Yo veo 260 routers conocidos. 16:37 <jrandom> postman: quizá podamos investigar qué está pasando en ese router después de la reunión (¿podrías crear un tar.bz2 de netDb/routerInfo-* para mí?) 16:38 <+postman> jrandom: sí, gracias 16:38 <jrandom> gracias 16:38 <jrandom> sí, no todo el mundo verá cada referencia en la netDb, así que es normal que haya fluctuación 16:40 <jrandom> ok, si no hay nada más sobre 1) 0.6.1.2, pasemos a 2) I2PTunnelIRCClient 16:40 <@cervantes> bien ahí, dust 16:40 <jrandom> como se mencionó en el correo, tenemos un filtro específico para el protocolo IRC disponible en CVS, y debería desplegarse como predeterminado en la próxima rev 16:41 <+postman> genial 16:41 <jrandom> sí, está muy bien, la gente ha estado pidiendo algo así desde hace años 16:41 <+Myo9> Jrandom, te has vuelto más abierto últimamente, hemos sabido de tu ex, y ahora de tu compañero de piso, etc. Recuerda: http://www.navysecurity.navy.mil/st031204.webp 16:41 <jrandom> *ejem* 16:42 <dust> si quieres ver lo que envía tu cliente puedes añadir net.i2p.i2ptunnel.I2PTunnelIRCClient=INFO y luego mirar los logs para verlo todo 16:43 <dust> he probado algunos clientes pero hay muchos.. 16:43 <jrandom> sí, lo he estado observando un rato, pero el filtrado parece sólido 16:44 <jrandom> hay algunas cosas interesantes que quizá podamos hacer en el futuro también, p. ej., PING/PONG localmente, para reducir la actividad de red 16:44 <+Complication> dust: gracias por la “info” :) 16:44 <+bar> genial, dust, muchas gracias 16:44 <wiht> ¿Esto significa que no necesitamos configurar un tunnel IRC adicional? 16:44 <jrandom> wiht: no, necesitarás un irc tunnel, pero puede reemplazar el que ya usas 16:45 <+Complication> wiht: preocúpate menos de que nuestro cliente IRC nos delate 16:45 <jrandom> postman/cervantes: ¿ideas sobre aumentar o eliminar los timeouts de ping/pong del servidor? 16:45 <wiht> Eso lo explica, gracias. 16:46 <+postman> mmh, yo no los quitaría, mi cliente se volvió completamente loco cuando estuve trasteando con eso 16:46 <jrandom> postman: bueno, estoy pensando que si respondiera localmente, el cliente recibiría un PING/PONG realmente, realmente rápido 16:46 <@cervantes> postman: el proxy podría responder a los pings 16:46 <jrandom> (pero el ping/pong no tendría que ir por la red) 16:47 <jrandom> no sé el impacto, pero podría valer la pena investigarlo. 16:47 <@cervantes> pero no estoy seguro de cómo reaccionarían los servidores, podrías terminar con un montón de clientes zombi 16:47 <+postman> jrandom: bueno 16:47 <jrandom> bueno, el keepalive de la librería de streaming debería encargarse de eso 16:47 * Complication ha experimentado zombificación ocasionalmente 16:47 <jrandom> Complication: ¿recientemente? 16:47 <+postman> jrandom: si el proxy hace ping por el cliente, el proxy también debe hacer ping/pong al cliente 16:48 <+Complication> Hace una semana, creo. 16:48 <jrandom> postman: un PING del cliente al proxy haría que el proxy respondiera directamente al cliente con un PONG sin enviar nada por i2p 16:48 <+Complication> Pero mi “copia” se cayó finalmente. 16:48 <@cervantes> jrandom: la conexión se mantendría abierta... los servidores tendrían que bajar su umbral para decidir en qué punto un cliente está caduco y necesita expulsión 16:48 <jrandom> Complication: ah, los servidores de irc no estaban al día entonces, no debería ocurrir más 16:49 <+Complication> Sin que yo usara “ghost”. Los usos recientes del comando ghost se han debido a operar con muchos nodos. 16:49 <+postman> jrandom: ¿y la medición del lag? 16:49 <jrandom> cervantes: correcto. y/o si fuera necesario, el proxy podría inyectar un mensaje PING extra al servidor si lo /necesita/. 16:49 <+postman> me resulta bastante útil saber si tengo lag o no 16:49 <jrandom> postman: a mí también, pero siempre puedes /msg a ti mismo 16:50 <dust> podrían quizá reducir el número de pings 16:50 <jrandom> ahorraría una cantidad considerable de ancho de banda, ya que los mensajes de tunnel son bloques de 1024 bytes, enviados a través de 2*k+1 saltos 16:50 <jrandom> eso también 16:50 <jrandom> no sé, solo una idea. lo que tenemos ahora es la leche de todos modos 16:51 <+postman> ok, intentaría parchear un servidor de pruebas 16:51 <@cervantes> quizá podríamos mirar de reducir el número... pero creo que aún deberíamos enviar algunos pings reales para determinar si los clientes siguen vivos 16:51 <+postman> quizá funcione 16:51 <jrandom> suena razonable, cervantes. no creo que necesitara ningún parche en el servidor, ¿eso espero? 16:52 <+postman> jrandom: para desactivarlo quizá, pero bajar el intervalo es un parámetro de configuración 16:53 * postman mastica la documentación de ircd ( otra vez ) 16:53 <jrandom> genial, sin prisa. solo algo que podemos mirar en algún momento 16:53 <@cervantes> class servers 16:53 <@cervantes> { 16:53 <@cervantes> pingfreq 120; 16:54 <@cervantes> class clients { pingfreq 90 } 16:54 <@cervantes> esa es mi configuración actual 16:54 <+postman> cervantes: sí, lo sé - la pregunta es si se puede desactivar del todo 16:54 <@cervantes> yo no los desactivaría... solo miraría de reducirlos 16:55 <+postman> ok, empecemos con eso 16:55 <+postman> cervantes: ¿qué tal 180 seg? 16:56 <@cervantes> a lo grande con 240 16:56 <@cervantes> pero quizá deberíamos tener lista primero la parte del ircproxy 16:57 <@cervantes> *discutir después de la reunión* 16:57 <+postman> de acuerdo 16:57 <jrandom> w3rd. ok, ¿algo más sobre 2) I2PTunnelIRCClient, o pasamos a 3) Syndie? 16:57 <@cervantes> cualquier cosa que reduzca mis actuales 40 kb/seg de tráfico medio del router ;-) 16:58 <jrandom> je, por alguna razón dudo que todo eso sea irc ;) 16:58 <jrandom> ok, sigamos 16:59 * cervantes esconde sus descargas de videos de ponis que ha estado chupando de jrandom toda la semana 16:59 <@cervantes> is=the 16:59 <+postman> LOL 16:59 <jrandom> como se mencionó en el correo, hay cosas bastante chulas pasando con syndie 16:59 <jrandom> la CLI es trivial, pero el nuevo Sucker de dust pinta muy prometedor 16:59 <jrandom> dust: ¿quieres darnos un resumen? 17:00 <dust> oh, 17:01 <dust> bueno, usa rome para parsear los feeds y luego lo convierte a sml, como se describe en el blog de jrandom 17:02 <dust> no es lo que llamarías robusto todavía, pero solo tiene dos días :) 17:02 <dust> tengo algo de Dilbert en mi syndie.. 17:02 <dust> :) 17:02 <dust> . 17:02 <jrandom> bien 17:03 <jrandom> ok, ¿qué opinas sobre hacia dónde va? ¿deberíamos meterlo en el código fuente de syndie y exponerlo como una CLI, o mantenerlo separado y distribuirlo independientemente, u otra cosa? 17:04 * dust no sabe, tú decides 17:04 <dust> cuantas menos herramientas separadas, mejor 17:04 <jrandom> sí, probablemente sea más fácil empaquetarlo todo junto, así todo el mundo sabe que puede usarlo 17:05 <jrandom> entonces podríamos hacer cosas como integrarlo en la interfaz web, y quizá en el scheduler de Ragnarok (sindicando con otros nodos y tirando de rss/atom/etc.) 17:07 <jrandom> ok, ¿alguien tiene preguntas/comentarios/preocupaciones sobre 3) Syndie? 17:07 <wiht> Si siguen integrando software en I2P, puede convertirse en un paquete de software inflado. 17:07 <wiht> Claro, puedo apagar Syndie si no lo estoy usando. 17:08 <jrandom> el i2p sdk 13KLOC 17:08 <jrandom> y el router de i2p solo tiene 22KLOC 17:08 <jrandom> pero sí, hay un impacto en los tiempos de descarga de la instalación 17:09 <jrandom> si alguien quisiera, podría construir un router minimalista sin aplicaciones cliente, usando solo router.jar, jbigi.jar y i2p.jar 17:09 <wiht> Sí, me refería a la descarga. 17:09 <jrandom> (pero es mucho más útil cuando hay una interfaz web para controlarlo, y i2ptunnel, y la librería de streaming, etc ;) 17:11 <jrandom> smeghead estaba trabajando en un sistema de distribución (como emerge, para java), y también están los de jpackage 17:11 <jrandom> si alguien quiere investigar una manera transparente y fiable de gestionar las aplicaciones sin empaquetarlas, estaría bastante bien 17:12 <jrandom> ok, si no hay nada más sobre eso, saltemos a 4) I2Phex 17:13 <jrandom> realmente no tengo mucho que añadir más allá de lo que está en las notas de estado 17:13 <jrandom> redzara: ¿andas por aquí? 17:13 <+redzara> sí, aquí estoy 17:13 <+redzara> Ya estoy trabajando en la próxima versión, mientras espero la reunión con Gregor. 17:13 <jrandom> ah, genial 17:13 <+redzara> El trabajo, por el momento, consiste principalmente en identificar las diferencias y las necesidades relacionadas con el uso de I2P, como por ejemplo tcp/udp vs i2p, gestión de los parámetros específicos de I2P (y gestión de la actualización de esos mismos parámetros en el momento de las próximas versiones, ...), port de GWebCache a I2P, usar RSS o no, usar push o no... 17:14 <+redzara> Tengo mucha documentación y código que leer 17:15 <jrandom> vaya, sí, suena a mucho. avísame si tienes alguna pregunta sobre la integración con i2p, o si solo quieres alguien con quien contrastar ideas 17:16 <jrandom> conseguir que la parte I2Phex sea un plugin para el Phex principal sería realmente brutal 17:17 <jrandom> ok, ¿alguien más tiene algo para 4) I2Phex? 17:18 <+redzara> Ciertamente necesitaría ayuda para la parte de petname 17:19 <+redzara> y quizá también para el fine tunning de los parámetros de los tunnels 17:19 <jrandom> genial, la nomenclatura es bastante sencilla: a un nivel básico, incluso podrías apañarte sin usar nombres en absoluto (así es como I2Phex lo hace ahora) 17:20 <jrandom> la config de tunnel tampoco debería ser un problema, aunque eso nos lleva a la idea de que quizá Phex necesite una sección de “configuración avanzada” para plugins 17:20 <jrandom> (obviamente querríamos tener buenos valores por defecto de todos modos) 17:21 <+redzara> quizá algo como ircclient, un filtro para estar seguros 17:22 <@cervantes> mejor poner la app en forma, imho 17:22 <jrandom> eso podría funcionar, aunque lidiar con secuencias arbitrarias de bytes puede ser duro 17:23 <jrandom> aunque, un proxy como ircclient podría permitir que cualquier cliente gnutella lo use. pero sería un montón de trabajo. 17:23 <+redzara> humm, solo es una idea ;) 17:23 * jrandom no conoce el protocolo lo suficientemente bien como para decir cuál es el mejor enfoque, así que sugiere ir con lo más simple que pueda funcionar :) 17:25 <jrandom> ok, si no hay nada más, quizá podamos pasar brevemente por 5) stego y darknets 17:26 <jrandom> no estoy seguro de tener algo que añadir más allá de lo que se está diciendo en la lista (y la discusión principal probablemente debería continuar allí) 17:27 <jrandom> dicho esto, ¿hay algo que la gente quiera plantear sobre los temas mencionados? 17:27 <wiht> Se mencionaron Freenet versión 0.5 y 0.7 en la discusión. ¿Hay una versión 0.6 de Freenet? 17:27 <jrandom> 0.6 es su rama “inestable” actual de la red 17:27 <jrandom> hasta donde sé 17:27 <+postman> ohh y yo pensé que había sido robada por fuerzas alienígenas 17:28 <jrandom> aunque culpar a los alienígenas suele ser una apuesta segura, este es uno de los pocos casos en los que no tienen la culpa 17:28 <+postman> :) 17:28 <wiht> Toad estaba hablando de poder recolectar las direcciones IP de nodos de I2P o FreeNet, ¿verdad? 17:28 <jrandom> entre otras cosas 17:29 <wiht> Solo quería aclararlo, gracias. 17:29 <jrandom> np. ok, ¿alguien más tiene algo sobre el 5), o pasamos al clásico 6) ??? 17:30 <+postman> ok, tengo una para el 6) 17:30 <jrandom> considera que ya nos movimos. 17:30 <jrandom> ¿qué hay, postman? 17:30 <+postman> todos hemos visto que los proxies con capacidad de filtros específicos por protocolo son buenos y necesarios 17:31 <+postman> ¿sería factible pensar en un proxy genérico 17:31 <+postman> que pueda alimentarse con una descripción de protocolo 17:31 <+redzara> Me gustaría tener una aplicación tipo cron usando beanshell para ejecutar código Java dinámicamente 17:31 <+postman> junto con cosas a vigilar/filtrar/disfrazar 17:31 <+postman> como una descripción XML de filtro/saneado 17:32 <+postman> para que no necesitemos código nuevo sino solo un nuevo archivo/perfil de filtro 17:32 <+postman> (solo una pregunta de si merece la pena pensarlo) 17:32 <jrandom> muy, muy complicado, postman. sería posible usar un lexer como javacc para construir lenguajes de entrada y una app para traducir ese lenguaje al formato de salida 17:32 <@cervantes> lo complicado es atrapar lo que se desvía del protocolo 17:33 <+postman> solo era una idea para desencadenar un proceso de lluvia de ideas 17:33 <+postman> imho algo como un proxy genérico con filtro/analizador (parser) modelado es muy usable 17:33 <wiht> ¿Alguien ha podido conectarse a eepsites.i2p? He intentado varias veces durante la última semana, pero siempre sin éxito. 17:33 <jrandom> wiht: lo cargué una vez, es lo mismo que eepsites.com 17:34 <jrandom> (¿o es .net? ¿o .org? ya no recuerdo) 17:34 * wiht visita eepsites.com 17:34 <jrandom> postman: si alguien pudiera dar con algo que funcionara, sería la leche 17:34 <+postman> jrandom: ok, pensaré un poco junto con susi 17:34 <jrandom> w3wt 17:34 <+postman> jrandom: quizá lo dejemos la semana que viene 17:35 <wiht> Es eepsites.com, y es un buscador de eepsites. 17:35 <+postman> pero tuve un sueño de que funcionaba 17:35 <+postman> :] 17:35 <jrandom> :) 17:36 * Complication sospecha que describir todas las sutilezas que ocurren en los protocolos... requiere código, y nada menos que código 17:36 <+Complication> (para la mayoría de los protocolos, al menos) 17:36 <@cervantes> nah, solo unas eeevul regex (expresiones regulares) 17:36 <+postman> Complication: quizá esta sospecha es la razón que nos impide seguir investigando 17:37 <+postman> Complication: aún no estoy seguro, pero la sospecha por sí sola no me dejará tranquilo en ese asunto 17:37 <jrandom> bueno, un punto importante aquí es algo que dust nos demostró - 17:37 * Complication teme una regex capaz de tales cosas 17:37 <jrandom> el código no es necesariamente tan aterrador. 17:37 <+postman> ¿ves? :) 17:37 <+postman> un buen lenguaje de modelado de filtros hará lo mismo 17:38 <+postman> :) 17:38 <@cervantes> tcl? :) 17:38 <+Complication> Tendría que ser bueno. 17:38 * jrandom ve que tú también tienes tus propios ponis voladores, postman ;) 17:38 * a dust también le parecía mal duplicar código aquí y allá 17:38 <+postman> jrandom: sin vacas :) 17:38 <jrandom> código funcionando>>> mejoras teóricas en el código 17:39 <+postman> mmh 17:40 <+postman> una cosa que aprendí de i2p 17:40 <wiht>>>> significa “mucho, mucho mejor?” 17:40 <+postman> no te rindas por las primeras apariencias 17:40 <jrandom> cierto, postman 17:40 <jrandom> sí, wiht 17:41 <jrandom> sería realmente genial 17:41 <jrandom> ok, ¿alguien más tiene algo para plantear en la reunión? 17:41 <+bar> bueno, ¿cómo va el IMAP, postman? (lo leí en los foros pero aún no lo he probado yo mismo) 17:41 <+postman> bar: pruébalo tú mismo - aún no tengo informes de usuarios 17:41 * cervantes rueda el gong con forma de poni 17:42 <+bar> ok, lo haré :) 17:42 <+postman> bar: y a mí me funciona GENIAL :) 17:42 <jrandom> bien 17:42 <+bar> genial 17:42 <+postman> cervantes: estás obsesionado 17:42 <@cervantes> ¿¡yo!? 17:42 <@cervantes> :) 17:43 <jrandom> ok, antes de que lleguemos a la marca de 90 minutos 17:43 * jrandom toma impulso 17:43 * jrandom da por cerrada la reunión con un *baf*