Reunión de desarrollo de I2P - 16 de marzo de 2004

13:12 < jrandom> orden del día: 13:12 < jrandom> 0) hola 13:12 < jrandom> 1) administrivia 13:13 < jrandom> 2) estado de la 0.3 13:13 < jrandom> 3) perfilado/selección de pares 13:13 < jrandom> 4) arquitectura web 13:13 < jrandom> 5) ??? 13:13 < jrandom> 0) hola 13:13 * jrandom saluda al grupo con la mano 13:14 < deer> * jrandom_ saluda desde I2P 13:14 < deer> * wilde da un hi5 13:15 < deer> <ughabugha> ¡Hola! 13:15 < deer> * duck está leyendo 13:15 < deer> <human> ¡yo! 13:16 < jrandom> w0rd, perdón por el retraso al subir esas notas de estado en (http://i2p.net/pipermail/i2p/2004-March/000165.html) 13:18 < jrandom> 1) administrivia 13:19 < jrandom> por simplicidad, y para evitar los problemas que tuvimos la semana pasada con varias redes poniéndose de mala leche, se hizo algo de magia y esta reunión se está llevando en tres redes de irc 13:19 < deer> <duck> (¡increíble!) 13:19 < jrandom> #i2p de iip, #i2p de la red de irc i2p de duck/baffled, y #i2p de freenode 13:19 < jrandom> :) 13:19 < deer> <baffled> ¿quién es paranoico? 13:20 < deer> <ughabugha> Ok, ya terminé de leer las notas de estado. 13:20 < deer> <ughabugha> jrandom: ¿Qué hay de eso? 13:20 < deer> <ughabugha> ¿O de ellas? 13:21 < jrandom> solo lo mencionaba, para que la gente que tenga problemas con una pueda usar otra 13:21 < deer> <mihi> bien. terminado con las notas de estado también 13:21 < jrandom> además, el servidor drupal debería volver a estar en línea este fin de semana (cruzando los dedos) 13:22 < deer> <ughabugha> Oh, ok. ¿Hay algo que discutir en el punto 1)? 13:22 < deer> <ughabugha> ¿O esperamos a que la gente termine de leer? 13:22 < deer> <ughabugha> jrandom: Bien. :) 13:22 < jrandom> no, a menos que alguien tenga alguna administrivia que quiera plantear 13:23 < deer> * mihi quiere marcar un punto en el punto 3 13:23 < jrandom> bandera puesta ;) 13:23 < deer> * duck en el punto 2 13:23 < deer> <duck> err, ¿qué índice usamos? 13:24 * jrandom supone que podemos pasar al punto 2 del orden del día) estado de la 0.3 13:25 < jrandom> acabé escribiendo mucho más de lo habitual para las notas de estado de la 0.3, así que en vez de repetirlas aquí, ¿alguien tiene preguntas/preocupaciones que quiera plantear? 13:25 < deer> <ughabugha> Adelante. 13:26 < deer> <duck> ¿por qué fallan tan a menudo las descifraciones ElGamal/AES+SessionTag? 13:26 < jrandom> duck> debido a sobrecarga y latencia. si un mensaje encaminado mediante garlic se retrasa más allá de la vida útil de ese sessionTag, el descifrado fallará 13:27 < deer> <duck> k 13:27 < jrandom> además, si el mensaje encaminado mediante garlic se descifra bien, pero el contenido se retrasó tanto que los cloves (submensajes en garlic) expiran, también es un descifrado desperdiciado 13:28 < deer> <duck> de algún modo esa frase me hizo creer que había una causa aparte de la sobrecarga/latencia 13:28 < deer> <tro|l> ce zi e azi? 13:28 < jrandom> bueno, ha habido algunos problemas con bloques de respuesta con encaminamiento de origen fallando al descifrar, aunque como van a desaparecer en 0.3.1, no vale mucho la pena depurarlos 13:29 < deer> <kaji> ¡wow funciona! 13:29 < jrandom> (y un ElG fallido probablemente es lo más intensivo en CPU que hace I2P) 13:30 < deer> <jrandom_> heh bienvenido a i2p #i2p :) 13:30 < deer> * kaji elogia 0.2.5.1 13:30 < deer> <jrandom_> ¿0.2.5.1? sheeit, consigue 0.2.5.4 :) 13:30 < jrandom> ok, ¿algo más sobre el estado de la 0.3? 13:31 < deer> <kaji> .. 13:31 < deer> <duck> . 13:31 < deer> <kaji> ¿ping? 13:31 < jrandom> p0ng 13:31 < mihi> pung 13:31 < deer> <mihi_backup> pung2 13:32 < deer> <Pellinore> gamba 13:32 < jrandom> ok, pasando a 3) perfilado/selección de pares 13:32 * mihi mueve la bandera al otro número 3 ;) 13:32 < jrandom> (tío, es un poco gracioso que no haya sustitutos vegetarianos de marisco...) 13:32 < deer> * kaji elogia 0.2.5.4.1 13:32 < deer> <duck> todo lo del perfilado de pares parece magia, ¿cómo planeas depurarlo? 13:32 < deer> <Pellinore> Hay carne de cangrejo vegetariana. 13:32 < jrandom> ah, cierto, pellinore. 13:32 < deer> <wilde> jrandom: y sushi veg 13:33 < jrandom> duck> ¿qué parte te parece magia? 13:33 < deer> <duck> toda la clasificación, etc. 13:33 < deer> <Pellinore> Y juraría que vi algún sustituto de filete de pescado tipo pollo, pero puedo estar equivocado. 13:33 < deer> <duck> Quiero decir, ¿cómo sabes que estás haciendo lo óptimo? 13:33 < jrandom> el organizador de pares (que mueve perfiles entre los distintos grupos) es un componente muy simple y separable 13:33 < jrandom> oh, buen punto. 13:34 < jrandom> estuve haciendo algunas pruebas de rendimiento el otro día, ejecutando el organizador con 10,000 perfiles, y los estaba organizando todos en ~50 ms 13:34 < jrandom> (organizar == ejecutar los calculadores y moverlos entre grupos) 13:34 < jrandom> los perfiles también consumen solo ~3-4 KB para un perfil completo, y un perfil mínimo ocupa ~200 bytes 13:35 < deer> <duck> sí, pero ¿cómo sabes que tienes razón con 'respuesta de 0.597s' para el grupo 1 13:35 < deer> <duck> y que no debería ser 0.603s 13:35 < jrandom> (así que mantendremos un perfil completo de los 1000 mejores pares, y mínimos de los siguientes 10,000) 13:35 < jrandom> ah, ok, buena pregunta. 13:36 < jrandom> ese es el componente Rate 13:36 < jrandom> obviamente habrá cierta variación, y no seremos muy exactos. el objetivo es estar en el orden de magnitud y organizarlos en consecuencia 13:37 < deer> <duck> Vi que usa promedios 13:37 < jrandom> p. ej., encontrar los routers en T3 con cuatro procesadores, y mantenerlos separados de routers en 386 con módems de 2400 bps 13:37 < deer> <duck> así que si metes 100 nodos de mierda, influyes mucho en el promedio 13:37 < jrandom> de acuerdo: hay dos aspectos distintos de eso que podemos ajustar 13:38 < jrandom> primero, podemos hacer que el umbral use el 10% superior para determinar lo "rápido" vs "no rápido" 13:38 < jrandom> (o el 90% superior, lo que sea) 13:38 < jrandom> segundo, podemos ajustar el componente Rate para mantener varias estadísticas: en lugar de un simple promedio, puede ignorar el sesgo, calcular la desviación estándar, etc. 13:39 < jrandom> el componente Rate actualmente es bastante básico, y me encantaría que alguien bueno con estadística pudiera echarle un ojo y mejorarlo 13:39 < jrandom> (uno de los objetivos clave, sin embargo, es que no dependa de la escala: si recibimos 100,000 eventos, no tiene que mantener todos esos puntos de datos en memoria, etc.) 13:40 < deer> <duck> ok, entonces ¿qué evita que ocurra otro desastre de NGRouting? 13:40 < jrandom> pero tienes toda la razón: los calculadores y los algoritmos de selección de pares van a ser un foco principal de futuras mejoras de la red 13:40 < jrandom> ngrouting intentó hacer dos cosas distintas: encontrar datos concretos y encontrar pares disponibles. 13:40 < jrandom> nosotros solo necesitamos encontrar pares disponibles 13:41 < deer> <duck> bien 13:41 < jrandom> (y colocar nuestros tunnels allí) 13:41 < deer> * duck quita el breakpoint 13:41 < jrandom> :) 13:41 < mihi> pero también tenemos que encontrar tunnels. 13:41 < jrandom> cierto, mihi: la netDb es un punto importante 13:42 < deer> <Pellinore> Se me da bien la matemática de la estadística, pero fatal los aspectos técnicos de traducir los datos a datos útiles para computadora. 13:42 < deer> <Pellinore> Pero con gusto me asociaría con alguien y contribuiría si puedo. 13:42 < jrandom> ¡genial, pellinore! 13:43 < jrandom> la clase principal rate está en http://i2p.net/cgi-bin/cvsweb.cgi/i2p/code/core/java/src/net/invisiblenet/i2p/stat/Rate.java?rev=1.3&content-type=text/x-cvsweb-markup y podemos hablar más tarde para comentarlo :) 13:43 < deer> <Pellinore> k 13:43 < jrandom> (lo sé, no espero que leas el código, solo lo menciono) 13:44 < deer> <Pellinore> Lo leeré, pero será como mi perro leyendo a Kierkegaard. 13:44 < jrandom> hehe 13:45 < deer> <Pellinore> Pero estoy aprendiendo. 13:45 < deer> <Pellinore> En fin, por favor sigue — no quiero retrasar las cosas. 13:45 < jrandom> (ofrecerse a ayudar no retrasa las cosas ;) 13:46 < jrandom> un punto que olvidé mencionar sobre el código de perfilado/selección de pares es que el rank 'integration' solo se usa en la base de datos de red para 'exploración', no para búsqueda/almacenamiento 13:46 < jrandom> seguimos haciendo búsqueda/almacenamiento kademlia (bastante) tradicional con todos los pares que no fallen 13:46 < jrandom> además, dentro de cada grupo de pares, siempre elegimos *aleatoriamente* 13:46 < jrandom> (o sea, no elegimos siempre al más rápido del grupo de rápidos, etc.) 13:47 < jrandom> eso es por razones tanto de seguridad como de balanceo de carga 13:48 < jrandom> (seguridad, para que un atacante no pueda simplemente crear un router muy rápido y ver cómo todos lo usan: tendrían que crear un gran número de routers muy rápidos, sesgar toda la distribución a su favor, etc.) 13:49 < jrandom> ok, ¿tenemos algo más para 3) perfilado/selección de pares? 13:49 < deer> <duck> . 13:50 < deer> <ughabugha> No lo parece. 13:50 < jrandom> ok, pasando a 4) arquitectura web 13:52 < jrandom> la nueva biblioteca de streaming de mihi nos da mucha flexibilidad, además ha mencionado varias veces el deseo de separar el código de httpclient en algo más robusto. además, human ha empezado a actualizar cosas para permitir proxying transparente squid (o tor-www) y proxying de eepsite dentro del mismo cliente 13:52 < jrandom> dados todos estos factores distintos, y la probabilidad de que la funcionalidad tipo web sea importante para la base de usuarios de i2p, creo que deberíamos dar un paso atrás e intentar imaginar cómo debería encajar todo 13:53 * mihi tiene algo de código volando por mi HD para ese código de httptunnel. pero está lejos de estar terminado 13:53 < mihi> para mí httptunnel == httpclient + algunos filtros 13:53 < mihi> por supuesto usando mi API de naming y streaming. 13:54 < mihi> el código por ahora solo permite diferentes "perfiles de anonimato". 13:54 < jrandom> ¿alguna idea sobre el estilo de human de conmutar por fallo a outproxies (proxy de salida) como squid/etc? 13:54 < mihi> es decir, enviar todas las peticiones por una destination, multiplexarlas hasta 10, multiplexarlas a un dest por hostname, etc. 13:54 < jrandom> ah, interesante 13:55 < mihi> pero esos dests aún no se usan ;) 13:55 < jrandom> w3rd. sí, hay una gran advertencia: tener muchas destinations en un router aumenta la carga de CPU de forma no trivial 13:55 < jrandom> (ya que cualquier fallo de garlic tendrá que fallar una vez por dest antes de fallar por completo) 13:56 < jrandom> creo que queda algo de magia que se puede usar para minimizar eso, de todos modos 13:56 < deer> <ughabugha> ¿Seguro que el proxying transparente de squid es buena idea desde el punto de vista del rendimiento? Quiero decir, la gente podría volverse demasiado perezosa y no apagar su eepproxy después de navegar sitios I2P o usar el squid de I2P, desperdiciando así ancho de banda de I2P en cosas que no requieren anonimato. 13:56 < jrandom> ughabugha> todas las cosas requieren anonimato :) 13:57 < jrandom> (y si no pueden notar la diferencia, bueno, sheeit...) 13:57 < mihi> mi intención para httptunnel es que los enlaces http se reescriban (similar a fproxy) de modo que no necesites un proxy sino solo un servlet. 13:57 < deer> <ughabugha> jrandom: Heh. De ese modo, I2P nacería muerto. No va a haber suficiente ancho de banda disponible en la red para todo lo que probablemente consumirían los nodos finales. 13:58 < mihi> en esa página de info se podría añadir una función para navegar el sitio a través, por ejemplo, de squid. 13:58 < jrandom> no estoy muy seguro de seguirte. Entiendo y estoy de acuerdo con los problemas de DNS involucrados (aunque creo que podemos rodearlos de algunas maneras) 13:58 < jrandom> ah, ok, mihi 13:58 < deer> <aum> buenos días a todos 13:58 < jrandom> mihi> ¿como una página "Unable to reach peer" mucho más avanzada? 13:59 < mihi> más bien una página de "advertencia de anonimato" como en Freenet ;) 13:59 < jrandom> ughabugha> si no podemos manejar la navegación web, ¿cómo vamos a manejar BT/compartición de archivos? 13:59 < jrandom> hmm, mihi, ¿pero queremos eso, para gente que quiere navegar la web anónimamente? ¿o no usarían httpclient para eso? 14:00 < jrandom> 'buenos días aum, justo a tiempo para la reunión de dev :) 14:00 < mihi> jrandom: si alguien solo quiere navegar la web anónimamente, 14:00 < deer> <ughabugha> jrandom: Hmm... Buen punto. ¿Vamos a hacerlo en absoluto? ;) 14:00 < deer> <aum> jrandom: no estás en iip, ¿no estás en irc.duck.i2p ?!? 14:00 < jrandom> ughabugha> debemos. 14:01 < mihi> podría configurar httptunnel para hacerlo (httptunnel seguirá funcionando como un proxy, así que es bastante trivial añadirlo) 14:01 < mihi> y probablemente alguien que navegue la web "anónimamente" querrá algunos filtros de contenido, supongo ;) 14:01 < jrandom> mihi> creo que human ya lo hizo :) 14:01 < jrandom> de acuerdo, mihih 14:01 < jrandom> /hih/hi/ 14:02 < mihi> cuando digo httptunnel, no me refiero a httpclient ;) 14:02 < jrandom> ah ok 14:02 < deer> <jrandom_> estoy aquí aum ;) 14:02 < mihi> pero *realmente* deberíamos mover I2PTunnel a usar la API de streaming lo antes posible, lo que reducirá el número de archivos que debemos mantener 14:03 < jrandom> de acuerdo 14:03 < mihi> human solo parcheó la versión antigua, yo parcheé la nueva versión personalmente 14:03 < jrandom> nos topamos con algunos bugs esta tarde, no sé si human ya te pasó logs 13:03 < deer> <wilde> otra cosa para la lista: outproxy estaba ocupado, pero más como i2p2i 14:04 < mihi> no he recibido logs aún de nadie... 14:04 < jrandom> mihi> nos pondremos con el código de streaming lo antes posible, podemos hablar de ello después de la reunión si tienes un momento, ¿o por correo? 14:04 < deer> * aum pasó parte de ayer mirando apps p2p con vistas a ejecutarlas en i2p 14:04 < jrandom> wilde> ¿hmm? 14:04 < jrandom> wikked aum, ¿algo prometedor? 14:04 < deer> * aum se inclina actualmente por favorecer la compartición de archivos tipo 'push', p. ej. konspire2b 14:05 < jrandom> i2psnark podría modificarse para usar la nueva API de streaming de i2ptunnel bastante fácilmente también 14:05 < deer> <human> mihi: enviando los logs (mihi@i2p.net, ¿cierto?) 14:06 < mihi> no sé si mihi me hizo un redirect 14:06 < deer> <mihi> s/mihi/jrandom 14:06 < jrandom> hmm aum, ¿crees que el modelo freenet/insert realmente funcionaría de forma más efectiva? 14:06 < deer> <wilde> jrandom: estaba pensando en usar un i2p webserver -> proxy -> internet, para que la gente pueda navegar un sitio i2p, pero quizá un tunnel ordinario pueda gestionar el tráfico 14:06 < jrandom> mihi> ¿quieres que lo reenvíe a ti? 14:06 < mihi> jrandom: no tengo nada en contra ;) 14:07 < deer> <ughabugha> aum: ¿Tipo 'push'? ¿Qué es eso? 14:07 < deer> <aum> lo que me gusta de konspire2b es que elimina la expectativa de entrega instantánea/rápida, y reduce el ancho de banda requerido, solo emitiendo anuncios de contenido, y luego dejando que la gente 'se suscriba' a 'feeds de contenido' 14:07 < jrandom> mihi> hecho. 14:08 < deer> <aum> así que en lugar de solicitar un archivo, quedarte esperando, enfadarte esperando a que llegue, simplemente te 'suscribes' al 'canal' de la fuente, y luego sigues con otras cosas 14:08 < deer> <aum> konspire2b.sf.net 14:08 < jrandom> aum> ¿pero no es increíblemente ineficiente, ya que tienes que gestionar una red de superposición (broadcast) para la lista de cosas disponibles y luego reenviarlas? 14:09 < jrandom> ¿no sería un sistema de swarming directo mucho más útil/eficiente? 14:09 < deer> <ughabugha> Heh. Eso suena prometedor para I2P. 14:09 < deer> <aum> jrandom: ¿algún ejemplo de swarming directo? 14:09 < jrandom> wilde> oh, ¿como el cgiproxy en duck y el sitio de janonymous? 14:09 < jrandom> aum> bittorrent 14:10 < deer> <ughabugha> aum: ¿Querías decir http://konspire.sourceforge.net/? 14:10 < jrandom> donde obtienes el torrent en algún sitio, y consigues bloques de contenido directamente de los pares que lo tienen 14:10 < deer> <aum> ughabugha: supongo que sí :) 14:10 < mihi> argl... $me->brother eliminó el port forward para i2p... 14:10 < jrandom> d'oh 14:10 < deer> <aum> jrandom: ¿alguien está probando bt/i2p actualmente? 14:11 < deer> <baffled> aum, ¿has mirado de cerca mnet? 14:11 < jrandom> aum> eco avanzó algo con i2psnark 14:11 < deer> <aum> le he echado un vistazo, pero no de cerca 14:11 < jrandom> (aunque está MIA por el momento) 14:12 < jrandom> hmm, mnet con metatrackers en eepsite y el transporte i2p/twisted de human podría funcionar 14:12 < deer> <duck> pruebas intensivas por janonymous y por mí parecen mostrar que los problemas actuales de i2psnark son 50% causados por i2p y 50% por snark 14:12 < jrandom> duck> ¿cuán recientes fueron esas pruebas? 14:12 < deer> <duck> la semana pasada 14:12 < jrandom> aunque no tengo reparos en explorar potencialmente otras implementaciones de BT 14:12 < jrandom> ah ok 14:13 < deer> <duck> sobre mnet, _creo_ que primero tendrías que arreglar mnet en sí antes de poder hacer que eso funcione 14:13 < deer> <duck> así que podrías igual arreglar Freenet y usar eso 14:13 < jrandom> heh 13:13 < deer> <aum> arreglar freenet, ¡ok! justo después de traer la paz mundial ;p 14:13 < deer> <duck> pero pregunta en #mnet @ freenode 14:13 < deer> <Pellinore> mnet=? 14:13 < deer> <Pellinore> ¿Mute? 14:14 < jrandom> en ese sentido, ¿quizá un mod de azureus para i2p podría funcionar? 14:14 < deer> <wilde> no, un enfoque p2p basado en mercado 14:14 < jrandom> pellinore - mnet.sf.net, un almacén de datos distribuido sin anonimato 14:14 < deer> <baffled> En realidad, estoy usando mnet bastante confiablemente en unas cinco máquinas. 14:14 < jrandom> cierto, el sucesor de Mojonation 14:14 < deer> <baffled> No puedo usar freenet de manera confiable en una sola máquina. 14:14 < deer> <duck> baffled: ¿0.6 o 0.7? 14:14 < deer> <duck> (0.7 es con twisted iirc) 14:16 < deer> <Pellinore> jrandom -- gracias. 14:16 < deer> <Pellinore> No puedes usar Freenet de forma confiable en ninguna máquina. 14:17 < deer> <baffled> 0.6.[23]. 14:17 < deer> <Pellinore> Es decir, entre otras razones, por eso estamos aquí. :) 14:17 < deer> <aum> encuentro que entropy funciona bien... ¡eventualmente! 14:17 < jrandom> no sé, aún creo que Freenet podría ser una buena base sobre la que trabajar para el DHT de i2p (cuando podamos recortar la mayor parte del código y quedarnos con el almacén de datos / SSK/CHK) 14:18 < jrandom> para compartir archivos, deberíamos aprender de la gente de filesharing qué funciona mejor 14:18 < deer> <aum> pero desde mi artículo de linuxworld sobre entropy, ahora hay montones de nodos entropy, y la red ha adquirido algunas características de rendimiento de freenet 14:18 < deer> <Pellinore> Me gusta el diseño básico y las características de Freenet, solo que el cabrón no funciona, especialmente si uno usa una conexión dialup. 14:18 < jrandom> p. ej., clones de DC, BT, [¿o qué más usan esos locos de la compartición de archivos?] 14:19 < jrandom> heh aum, maldito seas ;) 14:19 < deer> <duck> además están las cosas que Newsbyte señaló sobre entropy... 14:19 < deer> <aum> ¿anonimato más débil, por ejemplo? 14:19 < deer> <baffled> Sí, pero hay problemas de inestabilidad con 0.7. 14:19 < deer> <baffled> Creo que esta conexión se ha vuelto inestable otra vez. 14:19 < jrandom> y problemas de seguridad. creo que, por desgracia, podemos pasar de usar entropy 14:21 < jrandom> pero, erm, estamos en el punto de discusión 4, arquitectura *web*, así que por el momento volvamos a eso ;) 14:21 < deer> <aum> otra idea loquísima de compartición de archivos: ¿y si usamos nntp, con n personas ejecutando nntpds enlazados, y usar una de esas libs que descomponen archivos en trozos b64 y los publican, y libs para recuperarlos? 14:22 < jrandom> NNTP sería realmente interesante: es jodidamente fiable y probado por el tiempo 14:22 < deer> <duck> ¿enlazando los servidores? 14:22 * jrandom le encantaría tener un innd ejecutándose con i2p ;) 14:23 < deer> <aum> y como i2p se encarga del anonimato, no hay necesidad de que nntp lo tenga 14:23 < jrandom> cierto, la línea de feed de innd podría apuntar a un proxy i2ptunnel local 14:23 < deer> <aum> y la gente con diferentes servidores puede configurar los servidores para almacenar en caché su propia elección de grupos 14:23 < mihi> dependiendo de con qué frecuencia hagan peering sería posible censurar artículos creando colisiones de Message-ID 14:23 < deer> <duck> (¿has intentado configurar innd?) 14:24 < jrandom> muchas veces, duck, pero hace muuuucho tiempo 14:24 < deer> <aum> ¿es difícil configurar innd? 14:24 < deer> <duck> oh bueno, eres dios 14:24 < jrandom> mihi> de acuerdo: ese no es un medio de distribución a prueba de censura 14:24 < jrandom> aum> es un dolor 14:25 < jrandom> como squid: es bueno en lo que hace, pero probablemente necesitamos algo muy simple (un clic, ojalá) para empaquetar 14:25 * jrandom nos arrastra de vuelta al tema 14:26 < deer> <aum> y otro enfoque p2p/compartición de archivos: me parece recordar haber visto una app p2p que funciona vía http, encadenando servidores http 14:26 * mihi supone que la mayoría de los usuarios no saben cómo configurar un proxy en su navegador... 14:26 < deer> <aum> perdón, ¿cuál es el tema? 14:26 < jrandom> punto 4 del orden del día) arquitectura web ;) 14:26 < aum> ¿como, servidores web dentro de i2p? 14:26 < mihi> aum: sí 14:26 < jrandom> es un buen punto, mihi: un sistema web querrá lo básico (scripts .bat, .sh) para arranque/parada 14:27 < jrandom> hmm, ¿no incluye Mozilla una URL de JavaScript que puedas usar para configurar el proxy? 14:27 < jrandom> p. ej., ¿podríamos tener una página de config en httptunnel para hacer clic "on"/"off"? 14:28 < jrandom> me doy cuenta de que hoy no vamos a tomar decisiones sobre cómo debería funcionar la funcionalidad web, pero deberíamos fijar algunas direcciones 14:28 < aum> ¿cuál es el problema con la configuración actual de eepproxy? 14:29 < jrandom> p. ej., filtrado, proxies de entrada (eeproxies), servidores de salida (servidor normal de i2ptunnel), proxies de salida (outproxies al estilo squid o tor-www) 14:29 < mihi> aum: requiere bastante pericia tanto para ofrecer como para solicitar eepsites 14:29 < jrandom> además, el sistema actual de outproxy apesta. 14:29 < jrandom> es totalmente no escalable 14:29 < jrandom> necesitamos algo que permita/fuerce distribuir la carga de peticiones web salientes entre múltiples outproxies 14:30 < mihi> ¿cómo pueden los usuarios conseguir esos outproxies? ¿archivo de config (como en hosts.txt?) 14:30 < jrandom> y una razón por la que la gente normal querría ejecutar outproxies es por la negación plausible: incluso si ELLOS están solicitando "cosas malas", pueden decir "lo hizo i2p" 14:31 < jrandom> esa es una opción, mihhi 14:31 < mihi> jrandom: hehe 14:31 < jrandom> s/hh/h/ 14:31 < aum> pero ¿no hace eepproxy conexión http 'directa' al servidor solicitado, es decir, tan 'directa' como lo son las conexiones i2p? 14:31 < deer> <wilde> . /castvote DHT ala Freenet 14:31 < mihi> aum: el problema son las urls web "normales". 14:31 < jrandom> ./castvote 3 developers x 1 month x 12h / day 14:32 < deer> * human añadió soporte de httptunnel a TunnelManager, por cierto 14:32 < deer> <human> s/httptunnel/httpclient/ 14:32 < deer> <aum> ¿qué es eso? 14:32 < deer> <aum> oh, ¿soporte de http client? 14:32 < deer> <human> aum: sí 14:32 < jrandom> correcto, necesitamos encontrar una forma de dejar que la gente navegue slashdot.org vía i2p 14:32 < deer> <aum> ¿así que tunnelmgr ahora habla http? 14:32 < jrandom> ¡bien ahí, human! 14:32 < jrandom> aum> ¿recuerdas el proxy de squid? 14:33 < deer> <aum> sí 14:33 < deer> <wilde> jrandom: ¿entonces aprox. 4 meses-hombre para un DHT? 14:33 < deer> <human> aum: yup: openhttpclient <port> [<outbound WWW proxy>] 14:33 < jrandom> wilde> creo que es razonable, sí. 14:34 < deer> <aum> human: ¿lo has escrito en algún sitio? 14:35 < jrandom> aum> todo lo que hace es decir "if !eepsite { send through $outboundWWWproxy } else {send to eepsite}" 14:35 < deer> <human> aum: iba a hacer commit, luego me quedé atascado con un bug en StreamingI2PTunnelServer... 14:36 < jrandom> una buena solución a corto plazo sería un "outproxies.txt", al estilo hosts.txt 14:36 < deer> <aum> human: ¿y qué hace exactamente 'openhttpclient <port> [<outbound WWW proxy>]'? 14:36 < jrandom> aunque deberíamos empezar a pensar en soluciones a medio y largo plazo 14:37 < deer> <human> human: abrirá un proxy escuchando conexiones, que redirigirá al WWW-proxy todo lo que vaya a URLs que no terminan con .i2p 14:38 < deer> <Pellinore> Eso sí que es interesante. 14:38 < deer> <aum> human: ahh, bien, ¿así que separaste un hilo dentro de tunnelmgr? 14:38 < deer> <human> human: es decir, puedes usarlo para navegar tanto eepsite como la web normal 14:38 < deer> <human> human: sí 14:38 < deer> <human> s/human/aum/ :-) 14:39 < deer> <aum> un poco fuera del 'alcance' de tunnelmgr, pero oye, no hay otro sitio más apropiado en el código de i2p: buen trabajo d00d 14:39 < deer> <aum> human: ¿así que hablas python y java? ¿te está dañando el cerebro? 14:39 < deer> <human> aum: lo hice para evitar lanzar otra JVM más para el EepProxy 14:40 < jrandom> (bueno, el código está implementado en el httpclient de i2ptunnel, human solo lo ha expuesto recientemente a través de tunnelmanager también) 14:40 < deer> <aum> sí, siempre es bueno mantener al mínimo las instancias de la jvm 14:40 < jrandom> ((y en mi humilde opinión httpclient es exactamente donde debería ir ;) 14:40 < jrandom> (((hasta que salga el NextGen httpclient [httptunnel] de mihi))) 14:41 < deer> <aum> ¿está httpclient en cvs, de modo que me construya como parte de i2p update/build? 14:41 < jrandom> sí, eepProxy usa httpclient 14:42 < deer> <aum> *tío esto es tan esquizofrénico: tengo 3 sesiones de xchat abiertas (irc.duck.i2p,iip,freenode)) 14:42 < jrandom> :) 14:42 < deer> <aum> latencia brutal en irc.duck.i2p 14:42 < jrandom> ok, sin cierre hoy sobre la arquitectura web, obviamente, pero una discusión que valió la pena 14:43 < jrandom> sí, aum, unos 15s para mí 14:43 < jrandom> ¿algo más sobre la arquitectura web por ahora, o pasamos a 5) ??? sección de discusión abierta? 14:43 < deer> * human está pensando en un I2PSocksTunnel 14:44 < jrandom> uf, eso sí que estaría guay 14:44 < deer> <human> (bueno, quizá pertenezca a 5) 14:44 < deer> <aum> ¿socks? ¿hay manera de 'calzar' clientes sin soporte socks a través de una interfaz socks? 14:44 < deer> <human> aum: apt-get install tsocks :-) 14:45 < aum> discusión web: una última cosa: ¿y si bifurcamos/parcheamos un cliente web existente? 14:45 < mihi> aum: sockscap para windwos 14:45 < jrandom> aum> da miedo. muy potente, pero da miedo. 14:45 < jrandom> [odiaría tener que mantener eso] 14:45 < aum> incluso por ahora, un navegador tontísimo como dillo 14:46 < jrandom> [[aunque podría hacerse 'uber seguro', etc. pero aun así, muy, muy aterrador]] 14:46 < aum> o mejor, el control de navegador en wxwindows, es multiplataforma 14:46 * jrandom recuerda con nostalgia los flinks originales, cuando tenía un navegador de freesites integrado 14:47 < aum> pero de nuevo, los n00bs se quejarán si no pueden surfear sus sitios habituales infestados de JavaScript específico de M$ 14:47 < jrandom> cierto, aum, y los hackers también si no soporta el código más reciente compatible con estándares 14:47 < aum> oye, deberíamos pedir a Microsoft el código fuente de IE6, luego lo parcheamos ;p 14:47 < jrandom> construir un navegador == buena manera de desperdiciar miles de horas-hombre 14:47 < jrandom> heh 14:47 < deer> * human es bastante feliz usando privoxy 14:48 < aum> quizá incluyan el código de ie6 como parte del acuerdo punitivo europeo 14:48 < deer> <human> (http://www.privoxy.org/) 14:48 < aum> s/toos/toss/ 14:48 < jrandom> human> ¿cómo funcionaría eso para ambos lados del proxy? 14:48 < jrandom> p. ej., querremos que el contenido se filtre localmente, no en el extremo de salida 14:49 < deer> <human> jrandom: se podría animar a los usuarios a instalarlo 14:49 < jrandom> (pero el extremo de salida querrá filtrar algo de contenido para evitar abusos, etc.) 14:49 < deer> <human> jrandom: o podría ser parte de la instalación por defecto de I2P 14:49 < aum> ¿y si un DWP (proxy web distribuido) usara un DHT para su caché? 14:49 < jrandom> animar == solo geeks. empaquetar :) 14:49 < jrandom> eso estaría bien, aum 14:49 < deer> <human> jrandom: eheheh, de acuerdo :-) 14:49 < deer> <human> jrandom: por cierto, privoxy también corre en windogs 14:50 < jrandom> word. sí, necesitamos algún tipo de filtrado de contenido: privoxy, muffin, lo que sea. 14:50 < deer> <wilde> reunión larga... 14:50 * jrandom capta la indirecta.. 14:51 < deer> <Pellinore> wilde: Mucho que decir. 14:51 < jrandom> ¿alguien más tiene algo que quiera plantear? siempre tenemos la lista de correo para más cosas 14:51 < deer> <Pellinore> Y mucho que hacer, por supuesto. 14:51 < deer> <Pellinore> Tengo un par de preguntas pequeñas. 14:51 < aum> ¿podríamos bifurcar privoxy y 1) hacerlo funcionar sobre i2p, 2) hacer que use DHT para caching? 14:51 < deer> <Pellinore> Pero igual de fácil tratarlas en privado. 14:51 < jrandom> pellinore> ¿qué pasa? 14:51 < deer> <Pellinore> Nada, perdona que dijera nada. 14:51 < jrandom> aum> lo más probable es que no necesitaríamos bifurcar 14:52 < deer> <Pellinore> Hablaré contigo sobre ello en privado, o con duck, en otro momento. 14:52 < deer> <Pellinore> No es realmente material específico de desarrollo. 14:52 < deer> <duck> 10+16+7=33 horas-hombre desperdiciadas en esta hora extra :) 14:52 < jrandom> pero construir un DHT requiere mucho esfuerzo. totalmente increíblemente valioso 14:52 -!- Irssi: #i2p: Total de 10 nicks [0 ops, 0 halfops, 0 voces, 10 normales] 14:52 * aum va de nuevo a visitar las páginas wiki de infoanarchy.org sobre DHTs 14:52 < jrandom> ¿hay 16 personas en iip? 14:53 < deer> <human> aum: no hace falta bifurcar, solo: web browser <-> privoxy <-> httpclient <-> i2p <-> outbound proxy <-> www.pr0n.com 14:53 < deer> <wilde> un DHT genérico que funcione fuera de I2P también, y que permita otro binding además de http 14:53 < jrandom> aum> mira el enlace que duck añadió al wiki de i2p, listando varios 14:54 < deer> <human> aum: puedes configurar privoxy para que se conecte a otro proxy HTTP/socks (así es como funciona mi privoxy I2P-a-tor) 14:54 < deer> <duck> (http://www.bamboo-dht.org/) 14:54 < aum> no estoy seguro de que me guste la idea de un dht funcionando fuera de i2p: el mejor dht es uno sin anonimato (y la sobrecarga del anonimato) que pueda trabajar de forma más óptima dentro de i2p 14:54 < jrandom> hrm duck, ¿qué pasó con esa lista de 'ellos'? 14:54 < deer> <duck> aum: más fácil de probar 14:55 < deer> <duck> jrandom: algún comunista la eliminó, supongo 14:55 < jrandom> heh 14:56 < jrandom> google++ : http://www.etse.urv.es/~cpairot/dhts.html 14:56 < jrandom> (no es la misma página, pero interesante) 14:56 < jrandom> oh, aquí está la página: http://himalia.it.jyu.fi/ffdoc/storm/pegboard/available_overlays--hemppah/peg.gen.html 14:57 < jrandom> pero sí, un DHT que no intente implementar anonimato, además de un DHT que soporte tanto contenido estilo CHK como estilo SSK sería lo mejor 14:58 < jrandom> (el estilo SSK no es estrictamente necesario, pero joder sería muy útil) 14:58 < jrandom> pero, en fin 14:58 < jrandom> ¿alguien tiene algo más que quiera sacar? 14:59 < deer> <duck> mañana es el Día de San Patricio 14:59 < deer> <wilde> tema 5) ? 14:59 < deer> <duck> así que todos a beber cerveza irlandesa 14:59 < jrandom> buen punto 14:59 < deer> <Pellinore> Mañana es tanto el aniversario de mi relación actual, como de mi segundo matrimonio. 14:59 * jrandom toma nota para evitar pubs irlandeses mañana 15:00 < jrandom> oh, felicidades, pellinore :) 15:00 < jrandom> wilde> estamos en 5) ??? 15:01 < jrandom> (y a punto de estar en 6) [baf]) 15:01 * jrandom va a ir a iip en breve [si puedo] 15:01 * jrandom concluye 15:01 * jrandom *baf* cierra la reunión