Reunión de desarrolladores de I2P - 17 de enero de 2006

15:40 <jrandom> 0) hola 15:40 <jrandom> 1) Estado de la red y 0.6.1.9 15:40 <jrandom> 2) Criptografía de creación de tunnel 15:40 <jrandom> 3) Blogs de Syndie 15:40 <jrandom> 4) ??? 15:40 <jrandom> 0) hola 15:40 * jrandom saluda 15:40 <jrandom> notas semanales de estado publicadas @ http://dev.i2p.net/pipermail/i2p/2006-January/001251.html 15:41 <@cervantes> pfff, menos mal que i2p es más fiable que la NASA 15:41 <jrandom> je 15:41 <tethra> jaja 15:41 <jrandom> (aunque llego 20 minutos tarde... ;) 15:41 <jrandom> en fin, vayamos con 1) Estado de la red y 0.6.1.9 15:42 <wmpq> NSA o NASA, no son tan diferentes, ¿no? 15:42 <@cervantes> Dije I2P, no jrandom ;-) 15:42 <jrandom> buen punto, cervantes ;) 15:42 <tethra> no digas tonterías, ¡jrandom ES i2p! ;D 15:42 <@cervantes> oh, pensé que era una forma de pensar 15:42 <wmpq> [redact] 15:43 <jrandom> je, bueno, en fin, 0.6.1.9 ya está por ahí, con el 70% de la red actualizado (gracias a todos) 15:43 <Pseudonym> mmmm, sabroso lanzamiento nuevo 15:44 <+zzz> el éxito de construcción de client tunnel se mantiene <30% 15:44 <jrandom> No he oído muchos informes de un aumento sustancial del caudal de extremo a extremo, aunque algunos routers están más que saturando líneas T1 15:44 <+zzz> bajó desde ~40% 15:44 <+Complication> El ancho de banda parece normal, un poco más alto que en el último CVS antes del lanzamiento. Los conteos de pares parecen un poco más altos. 15:45 <jrandom> hmm, sí, no me preocupa mucho eso, zzz, ya que todo se va a rehacer por completo para 0.6.2 15:45 <+zzz> el BW promedio subió de ~12K a ~20K 15:45 <jrandom> 0.6.1.9 no debería elegir pares más propensos a aceptar (es decir, de alta capacidad), sino enfocarse en aquellos que tienen mayor caudal 15:46 <+Complication> El porcentaje de retransmisiones (anotado en 7% la noche del lanzamiento) ha bajado a seis coma algo 15:46 <jrandom> sí, con routers empujando 1–300 KBps, va a haber un sesgo 15:46 <jrandom> hmm, esa es una tasa bastante loca, Complication, yo solo he visto 2–3% 15:46 <jrandom> (pero no dudo de lo que ves) 15:47 <+Complication> Estoy llevando mi salida al máximo, prácticamente 15:47 <+Complication> (y me refiero a saturar la capacidad de la línea) 15:47 <jrandom> ah, eso lo explicaría 15:47 <+zzz> sigo recibiendo NULLs antes de los gets, lo que resulta en 405 bad method, la tasa puede estar disminuyendo, difícil asegurarlo 15:48 <jrandom> sí, zzz, hay algunas cosas que hay que resolver en la biblioteca de streaming, pero probablemente no llegue a eso hasta después de las reformas de tunnel de la 0.6.2 15:48 <jrandom> (pero si alguien quiere meterse a fondo antes de eso, sería genial, claro) 15:49 <jrandom> Complication: si reduces tu limitador de bw a algo como el 70% de la capacidad de tu línea, ¿la tasa de fallos vuelve a un valor razonable? 15:49 <+zzz> Sigo pensando que fue algo que entró en el código justo antes de Año Nuevo, así que mejor verlo antes de que se olviden esos cambios recientes :) 15:50 <+zzz> Visto por primera vez el 29 de dic. 15:50 <jrandom> sí, zzz, ciertamente fue así. probablemente relacionado con cómo ahora respetamos los timeouts. 15:51 <+Complication> jrandom: de hecho, estoy probando eso ahora mismo :) 15:51 <+Complication> Lo ajusté unos segundos antes de que lo preguntaras, pero no lo sabré muy pronto, supongo 15:51 <jrandom> pero hay un trabajo considerable que hay que hacer ahí para limpiarlo, y es más importante implementar el nuevo código de creación de tunnel (lo que mejorará sustancialmente las tasas de éxito de construcción de tunnel, además de añadir todo un conjunto de mejoras de anonimato) 15:51 <jrandom> genial, Complication, sí, dale 3–6 horas 15:51 <jrandom> (para purgar los valores / conexiones antiguos) 15:52 <+zzz> ~ 1% - 3% de los GETs están corruptos actualmente 15:54 <jrandom> entonces, ¿sugieres revertir los cambios en la biblioteca de streaming (para que i2psnark haga OOM a todos sus usuarios en 12–48 horas) y posponer más retrabajo de la biblioteca de streaming hasta después del trabajo de tunnel de la 0.6.2, o aplazar el trabajo de tunnel de la 0.6.2 una o dos semanas mientras renovamos la biblioteca de streaming? 15:55 <+zzz> desde luego, no reviertas 15:56 <+zzz> tú decides 15:56 <+Complication> Es un bug bastante escurridizo, es lo único que puedo decir 15:58 <jrandom> hay otros bugs en la biblioteca de streaming, así que si voy a arremangarme, querría abordarlos todos juntos (ya que ninguno de los bugs restantes es evidente). 15:59 <jrandom> por otro lado, tendremos una reducción sustancial del uso de ancho de banda, un mayor porcentaje de éxito de construcción, mejor anonimato y una capacidad mejorada para monitorizar el balanceo de carga en la red en vivo si vamos primero con el trabajo de tunnel 15:59 <Pseudonym> si es solo una tasa de fallos del 1–3% al navegar, diría que puede esperar, pero es solo mi opinión. 16:00 <jrandom> me inclino por hacer primero el trabajo de tunnel, ya que después de desplegarlo podemos monitorizar la red pasivamente mientras renovamos activamente la biblioteca de streaming 16:01 <jrandom> (también me gustaría construir una GUI para editar/publicar en Syndie, pero eso puede esperar hasta después de que ambas cosas estén resueltas ;) 16:01 <+Complication> Así es la tasa aquí también 16:02 <+Complication> (en mi eepsite) 16:04 <jrandom> Ok, creo que sería genial si pueden mantener un ojo en las cosas para ver si esas tasas cambian, pero mientras tanto continuaré con la renovación de tunnel, tras lo cual vendrá la renovación de la biblioteca de streaming (ambas estarán listas antes de la 0.6.2) 16:05 <jrandom> (o, si alguien quiere profundizar en la biblioteca de streaming [o ver si hay alguna interacción extraña con i2ptunnel], ¡avísenme!) 16:06 <+Complication> jrandom: por curiosidad, ¿se podría excluir i2ptunnel con una aplicación de prueba? 16:07 <+Complication> p. ej., si algo como la app de ejemplo de jnymo *también* recibiera nulls, ¿eso exoneraría a i2ptunnel de la lista de causas sospechosas? 16:07 <jrandom> se podría cablear una implementación ligera (en la VM) de I2PSocket para hacer eso, sin duda 16:07 <+Complication> Ya que, si no me falla la memoria, ese ejemplo usaba la biblioteca de streaming directamente... 16:08 <+Complication> (o casi directamente) 16:08 <jrandom> sí, claro, si algo que use la biblioteca de streaming puede reproducirlo, eso exoneraría a i2ptunnel 16:10 <+Complication> Hmm, a menos que alguien se adelante (intentaré terminar primero con lo de la webcache) quizá pruebe a emular HTTP con algo así... 16:10 <jrandom> brutal, gracias, Complication 16:10 <jrandom> ok, ¿algo más sobre 1) Estado de la red y 0.6.1.9? 16:11 <jrandom> si no, vamos a 2) Criptografía de creación de tunnel 16:11 <+Complication> Nah, puede no llevar a nada útil, o puedo tropezar a mitad de camino... pero es una posibilidad que me intriga 16:11 <jrandom> sí, definitivamente vale la pena explorarlo, Complication 16:12 <jrandom> (y las exploraciones no tienen que tener resultados positivos para que valgan la pena :) 16:12 * cervantes ve una excepción de “moo” en los cambios del código previos a Año Nuevo... ¿quizá sea eso? :) 16:13 <jrandom> ok, hay una nueva especificación de criptografía de creación de tunnel referenciada en el email, basada en la discusión que toad, Michael y yo tuvimos en la lista de correo el octubre pasado 16:14 <jrandom> échale un vistazo y cuéntame tus impresiones: no se desplegará en la red en vivo por un tiempo, ya que hay otras cosas que implementar primero, pero viene 16:14 <+Complication> ¿“moo” es una palabra reservada para Java? ;P 16:14 <+zzz> sobre el punto 2) ayudaré a revisar las referencias en el correo de estado 16:14 <+Complication> Sobre el tema de la cripto de tunnel, ¿te importa comprobar si el siguiente reformulado es correcto? Solo quiero asegurarme de que lo entendí bien... 16:14 <jrandom> gracias, zzz 16:15 <+Complication> "Each hop encrypts all records with their reply key, which they decrypted from their record, using their ElGamal private key, and by encrypting in such fashion, reverses one layer of decryption (or should I say, encryption) done by the tunnel owner, rendering the next participants' record readable with the next participant's ElGamal private key?" 16:15 <jrandom> Complication: sí 16:15 <+Complication> ¿O mi reformulación es simplemente incorrecta? 16:16 <+fox> <jme___> y demasiado complicada, si se me permite 16:16 <jrandom> creo que es correcta, pero sí, demasiadas oraciones subordinadas :) 16:16 <+Complication> No pensé en una mejor forma de visualizarlo. Ya fue bastante difícil así. :P 16:16 <jrandom> (o jme___, ¿estás diciendo que el algoritmo es demasiado complicado?) 16:17 <+fox> <jme___> no, intenté leer rápidamente el doc y me rendí porque demasiadas cosas requieren conocimiento previo 16:17 <+fox> <jme___> por otro lado, no lo intenté mucho :) otras cosas que hacer 16:17 <jrandom> Complication: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/java/src/net/i2p/router/tunnel/BuildMessageProcessor.java?rev=HEAD 16:18 <+fox> <jme___> ¿esta revisión por pares es una formalidad o realmente te preocupa/no estás seguro de ello? 16:19 <+Complication> Bueno, siempre es bueno saber qué hace un mecanismo subyacente... 16:19 <jrandom> Estoy seguro de que hace lo que pretendo que haga, pero estoy sinceramente interesado en si alguien puede ver un problema 16:20 <+fox> <jme___> si es lo segundo, podría dedicarle tiempo, pero mis conocimientos están anticuados y no los tengo frescos 16:20 <+fox> <jme___> si no, confío :) 16:20 <jrandom> la sección de notas tiene algunas preguntas - http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.notes 16:22 <jrandom> no hay prisa, probablemente pasará una o dos semanas antes de que esta nueva cripto se use realmente en el router 16:22 <@cervantes> jrandom: sobre eso, ¿habría mucha penalización de rendimiento al inyectar un retardo aleatorio entre saltos? 16:22 <@cervantes> ya que parece la opción más sensata para prevenir ataques de temporización 16:23 <jrandom> es creación de tunnel, así que un retardo no haría daño, aunque podría causar expiración prematura del lease set bajo fallos catastróficos 16:25 <jrandom> bueno, no estoy seguro de cuán efectivos serían esos retardos. pueden ayudar sustancialmente, pero puede que no. sin embargo, los tunnels en vivo pueden simplemente usar blending para detectar pares coludidos en ese tunnel de todos modos, así que no estoy seguro de que importe 16:25 <+fox> <jme___> ok, releyéndolo 16:27 <jrandom> gracias. ok, sin prisa, pero si/cuando alguien tenga alguna idea, mándenla hacia mí (o a la lista, o a su blog, etc.) 16:27 <jrandom> ok, ¿algo más sobre el punto 2, o pasamos al 3) Blogs de Syndie? 16:29 <jrandom> (considéranos ya pasados) 16:29 <jrandom> ok, cosas blogueras nuevas y chulas en Syndie, métanse ;) 16:29 <@cervantes> muy guay 16:30 <jrandom> los grupos de la izquierda pueden contener enlaces a URLs arbitrarias, así como enlaces a blogs, entradas dentro de blogs o adjuntos a entradas dentro de blogs 16:30 <jrandom> también hay toda una ristra de posibles mejoras, como añadir estilos por blog o por etiqueta para las entradas, iconos, etc. si alguien quiere meterse con eso, sería estupendo (y tendría un impacto muy visible :) 16:31 <@cervantes> por cierto, los enlaces externos definidos en comentarios también deberían tener un atributo title establecido a la URL de destino (como has hecho en el panel izquierdo) 16:31 <@cervantes> comentarios/entradas 16:32 <jrandom> ah, buena idea 16:33 <jrandom> (método net.i2p.syndie.sml.BlogPostInfoRenderer renderLinks(...) :) 16:34 <@cervantes> *toma nota* 16:35 <jrandom> ¿qué más necesitan los blogs de Syndie para ofrecer una alternativa funcional a los eepsites informativos? obviamente, Syndie es contenido estático, así que no se pueden hacer algunas cosas, pero puedes publicar contenido y dejar que la gente comente 16:36 <jrandom> ¿hay personalizaciones concretas que quieran poder hacer? si es así, avísenme 16:37 <DoubtfulSalmon> jrandom: ¿actualizar contenido existente vía script? 16:37 <@cervantes> archivo por fecha 16:37 <jrandom> DoubtfulSalmon: ¿vía script? 16:37 <jrandom> cervantes: ah, ¿como un pequeño widget de calendario, en lugar de los enlaces de “5 entradas más antiguas”? 16:38 <@cervantes> sí 16:38 <DoubtfulSalmon> jrandom: digamos que quiero que este archivo/texto reemplace aquel archivo/texto. ¿Cómo hago eso? 16:38 <jrandom> ok, genial, sí, eso debería ser muy fácil (si alguien prepara el HTML :) 16:38 <@cervantes> o más simplemente “ver las entradas del mes pasado” 16:39 <@cervantes> jrandom: solo necesitas una tabla 7x6 con algunos números dentro ;-) 16:40 <jrandom> DoubtfulSalmon: cambiar contenido que ya se ha publicado es una dirección interesante. en general, no siempre funcionaría, ya que tendría que operar como los mensajes de control de Usenet (cancelar una entrada antigua, etc.) 16:40 <jrandom> DoubtfulSalmon: por otro lado, puedes simplemente publicar un nuevo archivo/entrada y cambiar los enlaces del lado izquierdo para que apunten al nuevo archivo/entrada 16:40 <jrandom> (de esa manera, el contenido antiguo sigue ahí, pero se dirige a la gente al contenido nuevo) 16:41 <DoubtfulSalmon> jrandom: sí, estaría bien si el contenido antiguo siguiera ahí, siempre que los enlaces de todos apuntaran al contenido nuevo, sin que tengan que cambiar su contenido. 16:41 <jrandom> construir un wiki completo con ello, esencialmente publicando diffs con Syndie renderizándolos como resultado, es posible, pero puede ser excesivo 16:41 <jrandom> hmm, ok, veo lo que dices 16:42 <jrandom> entonces, quieres la capacidad de tener enlaces redirigibles, en lugar de los enlaces existentes a versiones exactas del contenido 16:43 <jrandom> quizá eso se podría hacer enlazando al bookmark de un blog, y la versión exacta se encuentra cargando los bookmarks actuales de ese blog y viendo adónde apunta 16:44 <jrandom> por otro lado, la versión nueva podría marcarse como respuesta a la entrada antigua, de modo que cuando la gente siga un enlace, puedan seguirlo hasta la respuesta que reemplaza el contenido 16:44 <jrandom> (aunque eso probablemente no sea tan transparente) 16:44 <DoubtfulSalmon> sí: digamos que quiero tener un enlace, por ejemplo, a una imagen de radar actual o algo así que se actualizará cada 10 min. Está bien si el contenido no se propaga por toda la red, pero si alguien más enlaza a mi página, el usuario debería ver la imagen actual. 16:45 <jrandom> bueno, eso depende de lo que quieran hacer: ¿quieren enlazar a la imagen tal como era cuando la referenciaron, o quieren enlazar al servicio que genera la imagen cuando el lector la ve? 16:45 <+Complication> cervantes: rareza del día :D Última entrada en: http://forum.i2p/viewtopic.php?t=1199&start=15 16:46 <+Complication> Parecía que podía ser otro de nuestros señores robóticos :P 16:46 <jrandom> pero es buena idea admitir ambos conceptos, y no creo que sea mucho problema 16:46 <@cervantes> gracias 16:46 <jrandom> aunque necesitaría una pequeña extensión a sml (p. ej. [blog bloghash="ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=" bookmark="radar.webp"]) 16:47 * cervantes actualizará las defensas del foro si empezamos a recibir muchos 16:47 <@cervantes> (ya sé cómo parar ese) 16:47 <DoubtfulSalmon> jrandom: deberían poder enlazar tanto a una versión estática de ello, siempre que el sindicador no haya borrado el contenido, como a una URL genérica que apunte a la última versión 16:47 <jrandom> (que miraría el meta post actual de ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c= para bookmarks, extrayendo el URI exacto del que se llama “radar.webp”) 16:48 <DoubtfulSalmon> jrandom: ¿se podría hacer ahora con algo como: "Ver 1 entrada más reciente con la etiqueta <weird string>" 16:48 <jrandom> ah, buen punto: sí, se podría 16:49 <jrandom> eso incluso podría restringirse a “Ver la entrada más reciente de $author con la etiqueta $tag” 16:49 <jrandom> (para que otras personas no pudieran suplantarlo) 16:49 <DoubtfulSalmon> así que quizá poner algún tipo de UI para que el usuario no tenga que ver etiquetas raras y demás 16:50 <jrandom> hay un ejemplo de cómo se ve eso ahí arriba, aunque no tengo el URI a mano... pero sí, es un enlace alrededor del texto enlazado 16:50 <DoubtfulSalmon> Supongo que toda esa información puede venir en forma de URL. 16:51 <jrandom> pero esto es definitivamente complicado para escribir el SML fuente, por eso una GUI para crear SML sería útil 16:51 <jrandom> son atributos en las etiquetas SML, no URLs 16:52 <@cervantes> y una GUI de SML será complicada sin JavaScript 16:52 <DoubtfulSalmon> pero puedes marcar como bookmark un resultado de búsqueda, ¿verdad? 16:52 <jrandom> ¿qué es un resultado de búsqueda? 16:52 <jrandom> ¿y a qué te refieres con bookmark? 16:52 <@cervantes> (o una extensión del navegador ;-) 16:52 <jrandom> oh, bookmarks del lado del navegador, sí 16:52 <+Complication> ¿Un resultado de filtro? 16:53 <jrandom> pero esos bookmarks no son, en general, compartibles 16:53 <DoubtfulSalmon> eh: un «get most resent 1 post by X with tag Y» 16:53 <jrandom> (en realidad, la mayoría sí lo son, pero no es universal, ya que son URLs, no URIs)) 16:53 <DoubtfulSalmon> sí, estaría bien si otros bolgs también pudieran enlazar a esos 16:54 <jrandom> DoubtfulSalmon: pueden, con sml 16:54 <jrandom> [blog tag="Y" bloghash="X"] 16:54 <DoubtfulSalmon> oh, qué bien 16:55 <jrandom> cervantes: JavaScript, o XUL, o Java, o alguna otra app cliente específica del SO 16:57 <@cervantes> ah, genial, así que no te importa una dependencia de scripting o de plugin 16:57 <jrandom> (cuando nuestro sitio web se renueve para la 0.6.2, Syndie definitivamente tendrá un sitio web que explique qué demonios es todo esto de Syndie, y cómo puede hacer de todo menos lavar los platos ;) 16:57 <@cervantes> (siempre que degrade con elegancia) 16:57 <jrandom> cervantes: Syndie debería ser function con Lynx, pero hay mucho margen para clientes ricos 16:58 <jrandom> (s/function/functional/) 16:58 <@cervantes> bien... así que los usuarios de Lynx obtendrían una tabla de referencia de SML, pero nada más 16:58 <jrandom> sí, como tenemos ahora 16:58 <jrandom> aunque quizá un sml simplificado, no sé. 17:01 <+Complication> jrandom: ¿crees que podría ser siquiera remotamente plausible... que el bug del null pueda estar relacionado con la codificación gzip? 17:01 <+Complication> Estaba pensando en cómo desactivar el gzipping para mi eepsite tunnel... 17:01 <+Complication> ¿O eso sería completamente inverosímil? 17:01 <@cervantes> se añadió algo de material del compresor HTTP justo antes de Año Nuevo en i2ptunnel 17:03 <jrandom> sí, podría: puedes desactivarlo en el lado cliente con i2ptunnel.gzip=false (en /configadvanced.jsp). actualmente no creo que puedas desactivarlo en i2ptunnelhttpserver, eso sí 17:03 <+zzz> es en el lado de la petición donde no hay ninguna compresión 17:03 <+zzz> el servidor no comprimirá si el cliente está puesto a false 17:03 <+Complication> zzz: oh, cierto, olvidé eso 17:04 <jrandom> (pero sin demasiada dificultad podrías añadirlo a I2PTunnelHTTPServer [línea 310, etc) 17:04 * Complication es un tonto, y se disculpa por ello 17:04 <@cervantes> (o podrías usar un tunnel normal) 17:04 <+Complication> Ajá, gracias... 17:05 <jrandom> hmm, aunque para cuando i2ptunnelhttpserver recibe el GET, el null ya está ahí 17:05 <+zzz> sí, logré mover orion de vuelta a un HTTP tunnel, lo que ayuda mucho a los tiempos de carga de sus páginas ya que ahora vuelven a estar comprimidas 17:05 <+Complication> De alguna forma olvidé por completo que el gzipping empieza cuando el cliente y el servidor han *acordado* hacerlo 17:05 <jrandom> así que puede estar en el lado cliente, pero definitivamente no en el lado servidor 17:05 <jrandom> sí, zzz, ahora es absurdamente rápido :) 17:05 <+zzz> está en el lado de la _request_ no en el de la _response_ - podría estar en el lado cliente o servidor 17:06 <jrandom> cierto 17:09 <jrandom> ok, ¿alguien más tiene algo sobre 3) Blogs de Syndie? 17:09 <jrandom> si no, pasemos a 4) ??? 17:09 <jrandom> ¿alguien tiene algo más que plantear para la reunión? 17:10 <cat-a-puss> Complication: el gzip stream de Java + I2P tunnels. NO funciona y es un bug de Sun 17:10 <jrandom> hmm, ¿cat-a-puss? ¿en serio? 17:10 <+zzz> Actualización de conexiones HTTP persistentes: lado cliente mayormente hecho, lado servidor avanzando bien, queda mucho de blindaje y pruebas por hacer, fin estimado 2–4 sem 17:10 <jrandom> ¡bien ahí, zzz! 17:11 <cat-a-puss> jrandom: sí, hablé contigo sobre eso hace mucho, probablemente podría encontrar la explicación larga de por qué, pero probablemente sea mejor simplemente documentarlo en algún sitio ya que no hay razón para hacerlo. 17:12 <jrandom> hmm, estoy fuera de contexto, ¿qué exactamente no funciona? ¿cuál es el bug de Sun? 17:14 <dust> obtengo logs raros como este: 21:21:59.816 WARN [%d0%a2%d1%4f] net.i2p.util.EepGet : ERR: status <html> 17:14 <jrandom> hmm, interesante 17:15 <jrandom> ¿qué tracker? 17:15 <cat-a-puss> jrandom: por lo que recuerdo, Sun usa zips sin cabecera y algún número mágico para indicar que es un zip stream. Pero el número resulta ser negativo, así que si terminas creando un zip stream dentro de un zip stream por alguna razón, lee los datos del stream como una secuencia de bytes sin signo y entonces el número mágico se convierte en algún otro número positivo. (probablemente me falte algún detalle, pero esa es la idea) 17:16 <dust> por ejemplo el OSDevWithCVS_3E.pdf.torrent 17:17 <dust> d8:announce540:http://YRgrgTLGnbTq2aZOZDJQ... 17:17 <jrandom> hmm, no sé nada de eso, y no estoy seguro de cómo afectaría al gzip stream sobre i2ptunnel (si lo /hiciera/, todos fallarían, porque comprimimos todo con gzip) 17:19 <jrandom> ok, genial, dust, entonces el tracker de postman. hmm, ¿estás en 0.6.1.9, dust? 17:20 <cat-a-puss> jrandom: sí, ha pasado casi un año desde que tuve ese problema, así que no lo recuerdo muy bien, y no sé si está arreglado en la 1.5, pero tuve un auténtico infierno intentando averiguar por qué todo tipo de stream normal funcionaba, pero en cuanto los envolvía en un stream comprimido todos fallaban. 17:20 <dust> sí 17:20 <jrandom> cat-a-puss: hemos cambiado las cosas drásticamente para la compresión sobre i2p en el último año ;) 17:21 <jrandom> (y yo personalmente no uso la 1.5) 17:21 <jrandom> pero hacemos nuestro propio zip encoding explícitamente, en lugar de usar su stream empaquetado (pero por razones de anonimato/eficiencia, no de compatibilidad) 17:22 <@cervantes> zzz: ¿dónde exactamente en la petición ocurre el null? ¿justo después de GET? 17:22 <+Complication> Antes, si recuerdo bien 17:23 <+fox> <lordalbert> hola 17:23 <+Complication> Nota al margen: un Celeron 300 muestra un porcentaje de retrans. dos veces menor que un Sempron 17:23 <jrandom> 'lo lordalbert 17:23 <jrandom> genial, Complication, 2–3% es razonable (aunque preferiría menos, claro) 17:23 <@cervantes> sería interesante lanzar un montón de peticiones HEAD o algo así... 17:24 <jrandom> sí, un conjunto de pruebas locales estaría genial, aunque si mal no recuerdo, Complication lo intentó hace tiempo sin errores 17:24 <+fox> <lordalbert> ¿alguien puede hacer un tracker anónimo? Lo intento pero no entiendo cómo usar el tunnel 17:24 <+Complication> cervantes: una vez intenté provocarlo, con un wget recursivo entre mis 2 nodos 17:24 <+Complication> Me cansé antes de que ocurriera 17:25 <@cervantes> je 17:26 <+fox> <lordalbert> 'lo b0unc3 ;) 17:26 <+fox> <b0unc3> lordalbert, :D 17:26 <+Complication> lordalbert: ¿sobre qué parte necesitarías asesoramiento? 17:27 <+Complication> Sobre configurar trackers, por desgracia no sé. 17:27 <+Complication> Sobre I2PTunnel, podría intentar explicarlo... 17:27 <+fox> <lordalbert> he instalado BTtracker y funciona perfectamente 17:28 <+Complication> También debería señalarse que, para que el tracker *permanezca* anónimo, probablemente deba ejecutarse con una configuración bastante cuidadosa 17:28 <+fox> <lordalbert> ahora, me gustaría anonimizarlo 17:28 <+fox> <lordalbert> así que 17:28 <jrandom> seguro que podemos ayudar a resolverlo después de la reunión. no deberías usar trackers genéricos, necesitas uno construido para el anonimato 17:28 <+fox> <lordalbert> acabo de hacer un i2ptunnel 17:29 <jrandom> (p. ej., la modificación de bytemonsoon que puedes encontrar en cualquiera de los trackers de i2p, o en el CVS) 17:29 <+fox> <lordalbert> ahora, me gustaría saber cómo usar este tunnel. Ya he hecho un tunnel 17:29 <jrandom> ok, ¿alguien tiene algo más para la reunión? 17:30 <jrandom> lordalbert: http://localhost:7657/i2ptunnel/ debería permitirte crear un 'http server tunnel' apuntando a tu servidor web/tracker, pero tu tracker no funcionará a menos que haya sido modificado para uso anónimo 17:30 <+fox> <lordalbert> jrandom, ¿qué tracker debo usar? 17:31 <+Complication> postman usa una versión modificada de ByteMonsoon, creo 17:32 <jrandom> i2p-bytemonsoon ha sido modificado para uso anónimo: hay un zip en @ http://i2p-bt.postman.i2p/, y está el CVS en http://dev.i2p.net/cgi-bin/cvsweb.cgi/bytemonsoon/, pero realmente no sé mucho al respecto 17:32 <+fox> <lordalbert> ¿no está obsoleto bytemonsoon? 17:32 <jrandom> si funciona, no está obsoleto. funciona 17:33 <+fox> <lordalbert> ok XD 17:33 <jrandom> hay muchos trackers ahí fuera, y si algún desarrollador quiere modificarlo para que funcione de forma segura y anónima, sería genial 17:33 <+Complication> Puede ser bastante viejuno... pero definitivamente funciona con destkeys en lugar de IPs... 17:33 <+Complication> No puedo hablar sobre la seguridad y la ausencia de fugas 17:34 <jrandom> (lo modificaron duck y otros por anonimato y seguridad) 17:34 <+Complication> Pero ha estado en línea un tiempo, y parece apañárselas... 17:35 <jrandom> ok, si no hay nada más para la reunión... 17:36 * jrandom se dispone a terminar 17:36 * jrandom *baf* da por cerrada la reunión