I2P Dev Meeting - December 20, 2005

15:20 <jrandom> 0) hola 15:20 <jrandom> 1) Estado de la red 15:20 <jrandom> 2) actualizaciones de I2PSnark 15:20 <jrandom> 3) Interfaz de blog de Syndie 15:20 <jrandom> 4) ??? 15:20 <jrandom> 0) hola 15:20 * jrandom saluda con la mano 15:20 <jrandom> notas de estado semanales publicadas en http://dev.i2p.net/pipermail/i2p/2005-December/001240.html 15:22 <jrandom> ok, pasemos a 1) Estado de la red 15:22 <jrandom> No tengo mucho que añadir más allá de lo que está en las notas de estado. 15:22 <+Complication> Si no fuera por los OOM ocasionales, me atrevería a llamarlo bueno 15:22 <jrandom> las pruebas de carga se ven bastante prometedoras, lo que sugiere que tenemos mucho margen para mejorar el rendimiento 15:23 <+Complication> Y supongo que los OOM 15:23 <jrandom> je, ¿OOM relacionados con i2psnark? ¿o de antes? 15:23 <+Complication> contribuyen a la inestabilidad, cuando instancias de i2p-bt, i2psnark o i2p-rufus hacen... cosas. 15:24 <zzz> mi teoría es que el aumento del tráfico de torrents está afectando un poco la fiabilidad de IRC 15:24 <+Complication> (quizá no debería llamar OOM a la rareza de SAM, ya que no la he mirado de cerca, pero definitivamente es uno de los factores) 15:24 <jrandom> hmm, no estoy seguro, ya que el estado de irc era similar al de antes de las últimas actualizaciones de snark 15:25 <+Complication> El ancho de banda ha sido sólido, los part. tunnels también sólidos... solo se cae de vez en cuando 15:26 <zzz> En cualquier caso soy optimista: las correcciones en el armado de tunnel que vienen en 0.6.1.8 mejorarán la experiencia de IRC de la gente 15:26 <+Complication> Por razones conocidas, que ojalá desaparezcan cuando llegue el momento :) 15:26 <jrandom> sí, yo también lo creo, zzz, así que probablemente tengamos un lanzamiento en un día o dos 15:26 <+legion> Bueno, puede que irc sea demasiado sensible, quizá usar algo como jabber sería mejor? 15:26 <zzz> especialmente para quienes tienen máquinas y/o conexiones más lentas 15:27 <jrandom> jabber no cambiaría las cosas 15:27 <+Complication> Especialmente con la redundancia de tunnel en 2 15:28 <+bar> diría que irc es un excelente mierdómetro para determinar el clima de la red 15:28 <+legion> Sí, con que sople un poco el viento y irc se va al traste 15:28 <+bar> exactamente :) 15:28 <+Complication> Noto que después del arreglo de la shitlist, "Recent" tiende a superar siempre a "Known" 15:29 <+Complication> ¿Sería porque "Known" no incluye pares en la shitlist, mientras que "Recent" sí? 15:29 <jrandom> sí, irc es una buena ventana a las cosas, ya que ha mostrado variaciones sustanciales según el usuario (p. ej., dreamtheaterfan siempre tiene problemas, etc.) 15:30 <jrandom> hmm, tiene sentido, Complication 15:30 <+Complication> (no estoy seguro de si es así, solo supongo) 15:30 <jrandom> (ya que los pares en la shitlist se eliminan de la netDb, pero sus perfiles no se quitan) 15:32 <+Complication> Entonces los indicadores parecen bien (solo quería preguntar por si no lo estaban) 15:33 <jrandom> ok, ¿algo más sobre 1) Estado de la red? 15:33 <jrandom> si no, pasemos a 2) actualizaciones de I2PSnark 15:33 <tealc_> ¿qué tipo de actualizaciones hay disponibles? 15:34 <jrandom> consulta http://dev.i2p.net/pipermail/i2p/2005-December/001240.html para un listado breve ;) 15:34 <jrandom> básicamente I2PSnark ahora puede manejar múltiples torrents a la vez sobre un único destino de I2P, tiene una interfaz web y está integrado en la consola del router 15:35 <tealc_> estoy ejecutando las últimas compilaciones de cvs y i2psnark está causando muchos errores de heap de memoria o lo que sea 15:35 <+Complication> ...y también maneja torrents creados por Azureus con meta-etiquetas raras. 15:35 <+Complication> Con los que antes se quedaba atascado. 15:35 <jrandom> ah, sí, aún hay algunas cosas que estoy depurando ahí, tealc_ 15:35 <jrandom> (como se mencionó en las notas de estado semanales ;) 15:35 <jrandom> ah, cierto, Complication 15:36 <jrandom> oh, además, la gente de Azureus ha corregido un bug en su tracker que impedía que I2PSnark lo usara 15:36 <jrandom> (así que quienes ejecuten trackers de azureus anteriores a B16 deberían actualizar en cuanto les sea posible) 15:37 <+bar> me gustaría tener la posibilidad de desactivar fácilmente el inicio automático de i2psnark (para escenarios de bajo ancho de banda, etc.) 15:38 <jrandom> eso debería ser bastante fácil de añadir 15:38 <+bar> suena genial 15:39 <jrandom> ok, ¿algo más sobre 2) actualizaciones de I2PSnark? 15:40 <jrandom> si no, pasemos a 3) Interfaz de blog de Syndie 15:40 <zzz> dos pulgares arriba por el nuevo i2psnark: buen trabajo 15:41 <jrandom> gracias, mjw hizo el trabajo duro, haciendo que snark sea tan fácil de ampliar 15:41 <jrandom> ok, como se mencionó en las notas de estado, syndie ahora tiene una nueva interfaz de blog 15:42 <jrandom> Creo que ofrecerá un equilibrio entre listas blancas y listas negras, abordando los distintos problemas de spam que se les presentan a las personas 15:43 <jrandom> lo tendremos desplegado en el próximo lanzamiento, así que en un día o dos podrán ponerse manos a la obra 15:43 <+legion> ¿El spam realmente va a convertirse en un problema serio pronto? 15:44 <+Complication> legion: como alguien estuvo amablemente dispuesto a demostrar, podría ser 15:44 <jrandom> nah, las listas negras se encargan de los autores que inundan, y las listas blancas se encargan de los spammers que crean muchos autores 15:44 <dust> (el anonimato saca lo peor de algunas personas) 15:44 <jrandom> (así que el spam no es un problema) 15:45 <+Complication> (Aunque creo que el tipo estaba regenerando claves para evitar la inclusión permanente en la lista negra, lo cual sí es algo de una ralentización.) 15:45 <+Complication> Aunque no una gran ralentización, y por tanto concuerdo de todo corazón en que las listas blancas también son buenas. :) 15:46 <+bar> quizá alguna solución de hashcash podría ser viable más adelante, si fuera necesario 15:46 <jrandom> si fuera necesario, pero no veo por qué lo sería 15:46 <+bar> de acuerdo, por ahora, yo tampoco 15:46 <+Complication> bar: ¿algo como "no mostrar a menos que se hayan molestado en hacer algunos cálculos"? 15:47 <+bar> sí, algo por esa línea 15:47 <+Complication> Suena posible, aunque probablemente innecesario. 15:47 <+bar> probablemente sí. 15:47 <jrandom> si un grupo de spammers estuviera inundando con muchos autores nuevos todo el tiempo, la gente aún podría avisar a otros sobre nuevos autores publicando sus marcadores y referencias de blogs en su propio blog 15:47 <+Complication> O más bien, con suerte innecesario. 15:48 <+Complication> Podría ser bueno considerar si Syndie puede acomodar tal funcionalidad, por si alguna vez surgiera la necesidad. 15:49 <jrandom> sí, puede, con encabezados en la entrada del blog o en la metainformación del propio blog 15:49 <jrandom> eh, metadatos (¡maldito seas, bt!) 15:51 <jrandom> ok, si no hay nada más sobre 3) Syndie, pasemos a 4) ??? 15:51 <jrandom> ¿alguien tiene algo más que quiera plantear para la reunión? 15:51 <+legion> sí, un par de cosas 15:52 <+legion> primero, clunk 15:52 <jrandom> genial, sí, clunk suena interesante 15:52 <+legion> Como mencioné hoy más temprano en i2p-chat, he estado trabajando para lograr que compile con cygwin y/o mingw. 15:53 <+legion> Por ahora solo el cliente está roto; el resto, incluido el servidor, compila y parece funcionar 15:53 <jrandom> bien 15:54 <tealc_> i2p podría resultar ser un verdadero embrollo para el programa de vigilancia ilimitada de George Bush. Nos vemos en los campos de la muerte, traigan las cartas, ¿sí? 15:54 <+legion> He estado intentando no solo rastrear por qué el cliente está roto, sino también resolverlo. Por el momento estoy atascado. 15:56 <+legion> La otra cosa que quería discutir: ¿se podría incluir en la próxima actualización un tunnel predeterminado hacia mi servidor de jabber? Solo para facilitar las cosas a quien quiera probar jabber. 15:57 <tethra> 20:34:37 <jrandom> si un grupo de spammers estuviera inundando con muchos autores nuevos todo el tiempo, la gente aún podría avisar a otros sobre nuevos autores publicando sus marcadores y referencias de blogs en su propio blog <--- ¿quizá algo en la línea de la forma de polecat de combinar la confianza podría jugar un papel aquí? (es decir, tanto bloquear a los spammers -y- promover a los autores populares.) 15:57 <tethra> </$0.02> 15:58 <+polecat> Eso sería un ejemplo primitivo de mi idea de red de confianza, con una heurística de transferencia de confianza del 100%, sí. 15:58 <jrandom> legion: hmm, agregar una configuración desactivada es bastante fácil para los usuarios nuevos, pero mi duda es respecto al filtrado de protocolo (y qué clientes filtran qué información). ¿cuál es tu experiencia con distintos clientes? 15:59 <jrandom> sí, hay mucho espacio para integrar métricas de confianza en syndie 16:01 <+legion> Bueno, hasta donde sé jeti no filtra, salvo su transferencia de archivos, que de todos modos está deshabilitada en la configuración de mi servidor. Posiblemente la próxima versión de jeti lo haya corregido. Aparte de eso, no conozco el comportamiento de los demás clientes. 16:02 <+legion> Sí sé con certeza que el groupchat es sólido, independientemente del cliente; es solo el contacto fuera del groupchat donde algunos clientes podrían filtrar, aunque no estoy seguro. 16:03 <jrandom> hmm, filtrar no es realmente un booleano, es una cuestión de /qué información/ filtran los clientes, no de si filtran alguna información 16:04 <+legion> Correcto, me refería por supuesto a cualquier información crítica como direcciones IP, aunque los buenos clientes, si llegan a filtrar esa información, solo deberían reportarla como 127.0.0.1 o localhost 16:06 <+legion> Así que recomendaría usar solo clientes conocidos que no filtren, como jeti. 16:07 <zzz> ¿podrías añadir una columna de verificado-no-filtra a tu cuadro de clientes? 16:07 <jrandom> sería útil si pudieras documentar qué filtra y qué no filtra jeti (en la línea de lo que postman armó para el proxy smtp y pop) 16:08 <+legion> Según el desarrollador de jeti no filtra nada que comprometa el anonimato de uno. Eso es seguro sin duda. También he revisado su código fuente y no he encontrado nada que me haga pensar lo contrario. 16:09 <jrandom> que el desarrollador lo diga puede ser seguro, pero lo que el desarrollador entienda por anonimato es otra cuestión ;) 16:09 <+legion> Sí, zzz, podría añadir otra columna de ese tipo 16:09 <jrandom> No dudo de la posibilidad de que jeti se comporte correctamente, pero necesitamos saber qué significa eso 16:10 <zzz> parece que la ausencia de filtraciones solo puede verificarse mediante rastreo del protocolo 16:10 <zzz> no mirando el código fuente ni preguntándole al desarrollador 16:12 <jrandom> ok, ¿alguien tiene algo más para la reunión? 16:12 <+bar> solo un recordatorio de no olvidar jbigi para amd64 16:13 <+bar> (pero apuesto a que está en tu lista de tareas) 16:13 <jrandom> sí :) 16:13 <jrandom> (win amd64, es decir, linux amd64 ya está funcionando) 16:13 <jrandom> pero, si no hay nada más... 16:14 * jrandom concluye 16:14 <+bar> sí, win amd64. 16:14 * jrandom *baf*s cierra la reunión