Reunión de desarrolladores de I2P - 9 de diciembre de 2003

[22:02] <jrand0m> 0) bienvenidos a $num [22:02] <jrand0m> 1) estado de iip [22:02] <jrand0m> 2) cosas de kademlia + idn [22:02] <jrand0m> 3) cosas de perfilado de pares [22:02] <jrand0m> 4) servicios de i2p [22:02] <jrand0m> 5) cosas [22:02] <jrand0m> 0) bienvenidos [22:02] <jrand0m> hola [22:03] <jrand0m> esta es la reunión 67 o 68... [22:03] <jrand0m> 1) estado de iip [22:03] <jrand0m> No lo sé. ¿Alguien sabe cuál ha sido la situación últimamente? [22:04] <jrand0m> los desarrolladores de iip no están aquí, así que... ni idea. [22:04] <jrand0m> [ping] [22:04] <jrand0m> (la semana pasada estuve escribiendo como 10 minutos antes de que mi cliente me desconectara por ping...) [22:05] <jrand0m> (no voy a escribir nada más hasta que reciba un p0ng, maldita sea ;) [22:05] *** Nostradumbass (nostradum@anon.iip) se ha unido al canal #iip-dev [22:05] <jrand0m> hola Nostradumbass [22:06] <Nostradumbass> hola :) [22:06] <jrand0m> ok, genial, así que no me hizo ping timeout, la gente solo está lurkeando. genial :) [22:06] * jrand0m salta al siguiente punto de la agenda [22:06] <Nostradumbass> ¿Cómo va i2p? [22:06] <Nostradumbass> ¿perdón? [22:06] <jrand0m> buen pie de entrada ;) [22:07] <jrand0m> punto de la agenda 3) estado de i2p 0.2.3 :) [22:07] *** nerox (~nerox@anon.iip) se ha unido al canal #iip-dev [22:07] <jrand0m> ha habido mucho progreso, aunque estoy offline. hice commit de un montón de código hace unas horas [22:07] <jrand0m> eso incluye una implementación del kademlia netDb [22:08] <jrand0m> así que estoy bastante seguro de que llegaremos al release de la 0.2.3 la próxima semana (que básicamente es kademlia netDb + un script de shell) [22:08] <jrand0m> sin embargo, ha habido algunas variaciones más en el proto de kademlia para hacer las cosas más relevantes para i2p [22:09] <jrand0m> siempre tendremos un árbol de kademlia muy, muy, /muy/ disperso. [22:09] <jrand0m> 2^256 slots posibles, y 1-10 valores por par en la red. [22:09] <jrand0m> así que, siendo absurdamente optimistas, aún no estaremos usando una mierda, y todo estará en el kbucket más lejano [22:10] <jrand0m> así que algunas partes de kademlia se van a ignorar discretamente ;) pero la idea básica sigue igual, incluido el algoritmo de búsqueda y la métrica de distancia [22:10] <jrand0m> idn, sin embargo, está muerto en el agua. [22:11] <jrand0m> la idea de que el código del netDb de i2p pudiera funcionar con el mismo código que una DHT de publicación fue una ideita tonta [22:11] <jrand0m> y ha sido abandonada de inmediato. [22:11] <jrand0m> idn sigue siendo en general una buena idea, pero no voy a gastar mi tiempo de dev de i2p trabajando en ello [22:12] *** tusko (~tusko@anon.iip) se ha unido al canal #iip-dev [22:12] <jrand0m> pero parte de los cambios de la 0.2.3 incluyen una revisión drástica de cómo elegimos los pares y organizamos las estadísticas del router [22:12] <jrand0m> heya tusko [22:12] <jrand0m> eso nos lleva al punto 3 de la agenda) perfilado de pares [22:12] <jrand0m> he sido bastante tonto... y por fin hice algo de las cuentas [22:13] <jrand0m> las estadísticas que se están recopilando ahora son enormes. [22:13] <jrand0m> unos 6000 puntos de datos /por par/ [22:13] <duck> ¿qué es el perfilado de pares? [22:13] <jrand0m> el perfilado de pares es donde el router lleva un registro del rendimiento de cada par para poder decidir a quién usar en el futuro [22:13] <duck> ah [22:13] <jrand0m> (aka routers rápidos, routers fiables, etc) [22:13] <duck> el proceso que se come mi memoria :) [22:14] <jrand0m> jeje en realidad esa parte no es taaaan mala [22:14] <jrand0m> aunque 6000 puntos de datos no escalan. [22:14] <jrand0m> 1000 routers @ 6000 puntos de datos cada uno @ 4 bytes / punto de datos = 24Mb [22:15] <jrand0m> aunque mantener estadísticas detalladas de unos pocos cientos de pares probablemente esté bien, incluso cuando la red crezca más allá de eso [22:15] <jrand0m> no /necesitamos/ mantener estadísticas de todos. solo de los routers que queremos 'usar' para nuestros tunnels, garlic routing (enrutamiento garlic), y source routing. [22:16] <jrand0m> probablemente a largo plazo nos bastaría con llevar seguimiento de un centenar de pares o así. [22:16] <jrand0m> pero, por ahora, voy a decir a la mierda. [22:16] <jrand0m> mantener estadísticas de todos los pares [22:16] <duck> ping [22:16] <jrand0m> p0ng [22:17] <duck> ¿intentará aprender acerca de todos los pares? [22:17] <jrand0m> por ahora, sí [22:17] <duck> oh espera, tus últimas líneas cubrieron eso [22:17] <jrand0m> también tenemos algo de código para fusionar y ejecutar cálculos sobre los perfiles de pares [22:18] <jrand0m> así que uno de esos calculadores determinará qué pares descartar [22:18] <jrand0m> un ejemplo del conjunto de datos que se está recopilando: (Link: http://i2p.dnsalias.net/~jrandom/profile.txt)http://i2p.dnsalias.net/~jrandom/profile.txt [22:19] <jrand0m> (notarás muchos 0s :) [22:19] <jrand0m> he escrito un manifiesto aproximado para la selección y el perfilado de pares, pero necesito subirlo al wiki [22:20] <jrand0m> pero eso es todo material de la 0.3, realmente. la 0.2.3 solo usa un poco de ello [22:21] <jrand0m> ok, eso es todo sobre el perfilado de pares. mucho más después, solo dando una pequeña vista de lo que hay [22:21] <jrand0m> (por supuesto, como siempre, cualquiera que quiera ensuciarse las manos y averiguar qué otras estadísticas / cálculos / ataques / etc deberían usarse sería *muy* bienvenido) [22:22] <jrand0m> ok, 4) servicios de i2p [22:23] <jrand0m> ¡el sitio de tc es increíble & realmente fiable! por fin también llegué a la página de nightblade, y es un blog chulo ('plog' ;).. solo quisiera poder dejar comentarios :) [22:23] <jrand0m> también está el servidor de jabber de duck, que funciona bastante fácil con las instrucciones publicadas en el board de tc [22:24] <jrand0m> las cosas a veces se portan un poco mal, pero eso está relacionado con algunos bugs en el router <= 0.2.2, y ya se han arreglado (y saldrán en la 0.2.3) [22:24] <jrand0m> el proxy squid generalmente está offline, ya que yo estoy offline demasiado para estar cuidando mis routers de kaffe :/ [22:25] <jrand0m> así que por el momento, los eepsites y el chat de jabber son probablemente las cosas más fiables en i2p, todo corriendo sobre i2ptunnel [22:25] <jrand0m> ¿qué servicios sería guay que aparecieran después? [22:25] <duck> intenté correr un ircd sobre i2ptunnel [22:25] <duck> pero antes de que recibiera el MOTD completo tras loguearme, ya tuve ping timeout [22:26] <jrand0m> d'oh [22:26] <duck> y eso fue en el mismo router [22:26] <duck> así que en el mundo real el rendimiento será aún peor [22:26] <jrand0m> ¿en el router local hizo ping timeout?! [22:26] <jrand0m> el router local no debería hacer ping timeout a nada nunca [22:26] <jrand0m> oh, excepto por ese bug [22:26] <jrand0m> (que probablemente fue lo que pasó, ya que era local y la carrera es más rápida ahí) [22:26] <duck> el cliente de irc hizo ping timeout por no responder a tiempo [22:27] <duck> lo volveré a intentar con la 0.2.3 [22:27] <jrand0m> eso [22:27] <duck> aunque jabber está bien por ahora [22:27] <jrand0m> totalmente [22:27] <jrand0m> y a largo plazo, irc no es el camino [22:27] <duck> ¡tc, jrandom y yo estamos ahí para chatear! [22:27] <jrand0m> jeje :) [22:28] <jrand0m> necesitamos una solución de IM y chat de grupo que no dé texto en claro a nadie no autorizado, y que no requiera puntos de estrangulamiento centralizados [22:28] <jrand0m> (aka iip 2.0) [22:28] <jrand0m> ahora sería un buen momento para que userx volviera al redil ;) [22:29] * jrand0m deja de contener la respiración [22:29] <jrand0m> un servidor nntp /también/ molaría muchísimo. [22:29] <duck> lo probaré mañana [22:29] <jrand0m> r0x0r [22:30] <duck> jabber es realmente bueno para ejecutar otras cosas por encima [22:30] <duck> échale un vistazo a las especificaciones de jabber rpc [22:30] <duck> (Link: http://www.pipetree.com/jabber/jrpc/)http://www.pipetree.com/jabber/jrpc/ [22:30] <duck> ¿otros servicios? [22:30] <jrand0m> eso es interesante: usar jabber como un servicio de nombres, esencialmente [22:31] <duck> quieres decir: [22:31] <jrand0m> siempre habrá más servicios que añadir: con correo (usenet), chat (jabber) y publicación/navegación (eepsites), hay buena cobertura [22:31] <duck> el servidor de nombres tiene un cliente de jabber a través del cual puedes registrar nombres (token proporcionado) [22:31] <duck> ¿también usarlo para consultar? [22:31] <jrand0m> nah [22:32] <jrand0m> que el registro de jabber sea el servicio de nombres [22:32] <duck> ok [22:32] <jrand0m> es centralizado, pero funciona [22:32] <jrand0m> igual que hosts.txt :) [22:33] <duck> ¿hay soluciones de correo que se adapten mejor a estos entornos que smtp y pop/imap ? [22:33] <jrand0m> esa es una muy buena pregunta [22:33] <duck> porque no creo que simplemente funcione cuando conectes servidores de correo [22:34] <jrand0m> sí, probablemente necesitaría o bien un gateway (al estilo freemail) o que el servicio de nombres hiciera algunos malabares interesantes [22:34] <jrand0m> o vuelve a un único servidor POP3/IMAP centralizado con todo el mundo en el mismo servidor [22:35] <duck> hablé con aum (autor de freemail) ayer [22:35] <duck> estaba hablando de reimplementar fred en python [22:35] <jrand0m> jajaja bien [22:35] *** mrflibble (mrflibble@anon.iip) se ha unido al canal #iip-dev [22:35] <duck> así que le sugerí que mejor trabajara en los routers en python para i2p [22:35] <jrand0m> ¡ooh eso molaría TOTALMENTE! [22:35] <duck> luego se molestó totalmente por los documentos pdf [22:36] <jrand0m> oye, si quiere los originales de openOffice, o incluso una exportación a txt, los exporto [22:36] <duck> y perdí la paciencia y le dije que tú también tendrías los docs de m$word si lo pidiera amablemente [22:36] <duck> bueno, fuiste un cabrón por no hacer una exportación a html o algo así [22:36] <jrand0m> nah, lo intenté ;) [22:36] <duck> perdí la paciencia y le dije que hablara contigo [22:36] <jrand0m> la exportación a html de openOffice APESTA [22:37] <duck> hm [22:37] <mrflibble> cierto jr [22:37] <jrand0m> cuando las especificaciones lleguen a 1.0 (aka cuando el router llegue a 1.0 y se actualicen para coincidir con el código), estarán en el wiki. [22:37] <duck> aunque el wiki tiene la mayor parte de la info [22:37] <jrand0m> exacto [22:37] <mrflibble> intenté usar eso para ese libro de kevin mitnick. fue peor que ms office [22:37] <duck> en fin [22:37] <jrand0m> exactamente. [22:37] <duck> podría aparecer por aquí alguna vez [22:37] <jrand0m> eso estaría genial [22:38] <duck> pero quizá con su actitud sea mejor que se una a la banda de freenet [22:38] <duck> ... [22:38] <jrand0m> bueno, el esfuerzo en freenet siempre es algo bueno [22:38] * duck vuelve a ser amable [22:38] <jrand0m> :) [22:38] <duck> el trabajo de aum mola [22:38] <duck> ojalá mole en i2p [22:39] <jrand0m> sí, cada vez que alguien hablaba de búsqueda en freenet, yo siempre decía "pues haz un McNabb" [22:39] <jrand0m> necesitamos la ayuda, sin duda [22:39] <duck> lo cual me lleva a la siguiente pregunta: [22:39] <duck> ¿están especificados los cambios que haces a I2P? [22:39] <duck> ¿o es el código fuente en java la documentación con la información más reciente [22:40] <jrand0m> tengo notas tomadas en mi palmpilot, filesystem y cuaderno, pero por desgracia no he actualizado los docs de openoffice en un tiempo [22:40] <jrand0m> febrero es el mes de docs para jrandom. [22:40] <jrand0m> (y qa, y corrección de bugs) [22:41] <jrand0m> ((y borracheras ;)) [22:41] <jrand0m> las especificaciones siguen siendo bastante correctas, solo hay más detalles. [22:41] <duck> genial [22:41] <jrand0m> pero las estructuras de datos han tenido más cambios [22:42] <jrand0m> ok, ¿algo más sobre servicios? [22:43] <jrand0m> ok, 5) cosas [22:43] <jrand0m> hola [22:43] <duck> ¡hola! [22:43] <jrand0m> ¿qué tal todo? [22:43] <jrand0m> [cualquier pregunta / idea / problema / etc va aquí] [22:43] <duck> los trucos de base64 deberían añadirse a las páginas de i2ptricks [22:44] <jrand0m> ooh buen punto [22:44] <duck> podría haber otros trucos también que aún no conozco [22:44] <duck> haré grep en las fuentes por 'main' [22:44] <jrand0m> me siento culpable por no hacer que el instalador permita a alguien obtener automáticamente el hosts.txt y reseedear [22:44] <jrand0m> lol [22:44] <jrand0m> hay muchísimos métodos main(), pero en su mayoría son funciones de prueba [22:45] <jrand0m> ¡oh! [22:45] <jrand0m> una cosa. NO ejecutes el código actual desde cvs y esperes que funcione con routers normales. [22:45] *** joda (--@anon.iip) se ha unido al canal #iip-dev [22:45] <joda> hola [22:45] <jrand0m> los mensajes de la db cambiaron :) [22:45] <jrand0m> hola joda [22:45] <joda> perdón si interrumpo algo [22:45] <duck> me molestó un poco no poder hacer que cvs funcionara [22:45] <duck> pero luego recordé que esto no es freenet [22:45] <joda> solo me preguntaba qué pasó con "anonymail" ? [22:46] <duck> así que no necesitas el cvs más reciente para poder usarlo [22:46] <jrand0m> joda> el usuario que lo ejecuta no parece estar online en este momento. debería volver pronto [22:46] <jrand0m> jeje duck: ¿te falló hoy después de que hice commit, o te refieres a antes de hoy? [22:46] <duck> la semana pasada, por ahí [22:46] <joda> jrand> gracias :) [22:46] <joda> nos vemos :) [22:46] <jrand0m> ah 'k duck [22:46] <jrand0m> l8r joda [22:47] <jrand0m> sí, solo respaldo ejecutar el código liberado [22:47] <duck> ¿la 0.2.3 pondrá los archivos de versión en un directorio? :) [22:47] <jrand0m> la 0.2.3 se deshace de los archivos de versión :) [22:47] <jrand0m> (muchísimos cambios) [22:47] <jrand0m> pero eso significa que la 0.2.3 (y posteriores) requerirá relojes generalmente correctos [22:48] <jrand0m> (actual Router.CLOCK_FUDGE_FACTOR = 30 minutos) [22:48] <duck> ¿cuál será el fudge factor para la 0.2.3? [22:48] <jrand0m> probablemente el mismo [22:49] *** joda ha salido de #iip-dev [22:49] <duck> oh, current = tu código [22:49] <jrand0m> ese tiempo se usará para expirar entradas de la db [22:49] <duck> k [22:49] <jrand0m> ah, claro, sí :) [22:49] <jrand0m> (en la 0.2.2 ese clock_fudge_factor está repartido por media docena de archivos) [22:49] <duck> quizá el instalador podría ser un poco más amigable para el usuario [22:49] <duck> es decir, menos preguntas [22:49] *** Desconexión: nickthief66282 (Excess Flood) [22:50] <duck> incluir urls phttp por defecto, sin limitación de ancho de banda, etc [22:50] <jrand0m> supongo que también podríamos autoadivinar puertos aleatorios [22:50] <jrand0m> tienes razón [22:50] <jrand0m> ¿quieres privilegios de commit? :) [22:50] *** Desconexión: nerox (EOF From client) [22:50] <jrand0m> (si no, puedo actualizarlo para la 0.2.3) [22:51] <duck> un argumento en contra puede ser que los usuarios den por sentadas demasiado fácilmente las configuraciones [22:51] <duck> y que todos usen el mismo relay phttp [22:51] *** nickthief24373 (~chatzilla@anon.iip) se ha unido al canal #iip-dev [22:51] <jrand0m> cierto. aunque los planes para la 0.3.1 incluyen una actualización del código del relay phttp para que los relays hablen entre sí y redirijan a los usuarios a un relay menos cargado [22:52] <jrand0m> en general estoy contento con el proceso de instalación por ahora - hice una nueva instalación 0.2.2 y estaba navegando la página de tc en menos de un minuto [22:52] <jrand0m> (aunque eso es porque sé lo que dice todo el texto y no lo leí...) [22:52] <duck> no me gustan las claves largas [22:53] <duck> especialmente no si tienes que copiar&pegarlas [22:53] <duck> mejor úsalas como archivo [22:53] <jrand0m> ¿hmm? [22:53] <duck> pero distribuir los archivos binarios es un dolor [22:53] <duck> así que tienes que hacer el truco de base64.. [22:53] <duck> ¿podría el i2ptunnel leer también claves de destino en base64? [22:53] <duck> de un archivo, digo [22:53] <jrand0m> justo estaba escribiendo eso ;) [22:53] <jrand0m> sí, eso no sería mucho trabajo [22:54] <jrand0m> quizá incluso 1 línea [22:54] <duck> además, ¿qué hay del armouring? [22:54] <duck> con un header&footer [22:54] <duck> como pgp, etc [22:55] <jrand0m> cierto, sería útil tener ese tipo de validación [22:55] <duck> por supuesto eso es un gadget [22:55] <duck> pero podría ser útil para quienes quieran usar el tunnel [22:55] <jrand0m> aunque la propia estructura Destination es bastante quisquillosa [22:55] <jrand0m> pero tienes razón, un base64 en bruto no es lo más intuitivo ni seguro para pasar por ahí [22:56] <jrand0m> necesitamos un bugzilla [22:56] <jrand0m> para que cosas como esta se puedan publicar como todo [22:56] <jrand0m> por eso dejaría la lista de tareas de mi palm [22:56] <duck> bugzilla tiene requisitos de registro nazis [22:56] <duck> con emails, etc.. [22:56] <jrand0m> cierto [22:57] <duck> pero mejor que nada [22:57] <duck> los demás bugtrackers tienen todos sus carencias [22:57] <jrand0m> sí, en casi todas las empresas en las que he trabajado han acabado construyendo el suyo propio [22:58] <jrand0m> ya veremos. necesitamos un bugtracker para cuando empecemos a hacer qa a fondo (una vez salga la 0.3) [22:58] <jrand0m> así que tenemos unas semanas ;) [22:58] <jrand0m> pero si alguien investigara y encontrara uno realmente bueno, sería genial [22:59] <jrand0m> [no tú específicamente, duck; cualquiera que esté leyendo estos logs de la reunión en casa ;)] [22:59] <duck> hasta ahora phpBugTrackers me ha ido bien [22:59] <jrand0m> hmm no he usado ese [22:59] <duck> sí, tampoco le estoy hablando a jrandom [22:59] <jrand0m> lol [22:59] <duck> sino al grupo de desarrolladores del código de I2P :) [22:59] * jrand0m en realidad son 12 personas actuando bajo un solo nym [23:00] <jrand0m> ok, 1 hora, clavado [23:00] <jrand0m> ¿alguien más tiene algo antes de que saque el *baf*er? [23:01] * duck exige 1 minuto más [23:01] <duck> ya que empezamos a las 21:02 [23:01] <jrand0m> sí, sí [23:01] <jrand0m> la la la [23:01] <jrand0m> ¿qué ceno? [23:01] <jrand0m> hay un buen sitio de falafel al lado... [23:01] <jrand0m> también comí gnocchi al almuerzo [23:01] <jrand0m> hmm... [23:01] <jrand0m> quizá una cena líquida [23:02] <duck> ¿sopa? [23:02] <jrand0m> ¡ooOooo sopa de whiskey! [23:02] * jrand0m cierra la reunión con un *baf* en esa nota