Reunión de desarrolladores de I2P - 7 de septiembre de 2004

14:09 <jrandom> 0) hola 14:09 <jrandom> 1) 0.4 14:09 <jrandom> 2) Capacidad y sobrecarga 14:09 * cervantes arrastra un taburete de bar 14:09 <jrandom> 3) Actualizaciones del sitio web 14:09 <jrandom> 4) Interfaz web de I2PTunnel 14:09 <jrandom> 5) Hoja de ruta y "todo" 14:09 <jrandom> 6) ??? 14:09 <jrandom> 0) hola 14:09 <nicktastic> ugha, Ah, ni siquiera hace falta -x para ver qué se está resolviendo - qué tonto 14:09 <cervantes> hola 14:09 * nicktastic vuelve a lurkear 14:10 <jrandom> 'hola a todos, perdón por el retraso en las notas - http://dev.i2p.net/pipermail/i2p/2004-September/000437.html 14:10 * jrandom tenía que responder al post E de Derick :) 14:10 <deer> <ugha2p> nicktastic: Correcto. Aunque la reunión ya empezó. :) 14:10 <luckypunk> h wow, no me lo perdí. 14:10 <jrandom> !hi5 14:10 <jrandom> ok, pasamos a 1) 0.4 14:11 <jrandom> por fin lo sacamos, y no parece habernos mordido demasiado 14:12 <jrandom> la red es más grande que nunca (conté 60 conexiones TCP hace unas horas), las eepsites se pueden recuperar, y el irc a menudo es utilizable 14:12 <dm> ¡hey!! ¿reunión? 14:12 <jrandom> hypercubus ha hecho un gran trabajo con la nueva instalación, el systray y el gestor de servicios, lo cual sé que nos ha ayudado mucho 14:13 <modulus> bien 14:13 <hypercubus> aún queda camino 14:13 <hypercubus> pero creo que ya vamos llegando a algo 14:13 <jrandom> de acuerdo, siempre hacia delante :) 14:14 <jrandom> esta versión también trae el despliegue generalizado del ?i2paddresshelper de oOo 14:14 <jrandom> lo tratamos un poco la otra semana [http://dev.i2p.net/pipermail/i2p/2004-August/000419.html ítem 2.3], pero ahora probablemente es buena idea que la gente considere usarlo para sus enlaces 14:15 <hypercubus> ¿funciona con vhosts basados en nombre? 14:15 <jrandom> el i2ptunnel httpclient todavía envía correctamente Host: $base64dest 14:17 <jrandom> sobre eso, se ha hablado más de usar el servidor web incluido para servir algunas eepsites, y creo que si alguien tiene tiempo para averiguar la configuración necesaria, estaría muy bien (evitándonos los problemas de configuración de vhost / apache) 14:18 <jrandom> ok, ¿alguien más tiene algo que comentar sobre 0.4? 14:18 <deer> <baffled> ¿este servidor web está en cvs? 14:18 <demonic_1> ? 14:18 <hypercubus> el servidor web está en 0.4 14:18 <demonic_1> qué me perdí 14:18 <deer> <ugha2p> baffled: Va a estarlo. 14:18 <hypercubus> por ende, CVS 14:18 <jrandom> baffled: sí, está todo en cvs (lib/org.mortbay.*) 14:18 <cervantes> por cierto, experimenté con los manejadores de protocolo de URL de Windows... es muy fácil configurar el registro para que "i2p://base64" se abra en un navegador con un http://site.i2p?i2paddresshelper=base64 ... 14:19 <deer> <ugha2p> Oh, ya lo está. 14:19 <dm> todo esto es muy muy cool 14:19 <hypercubus> ya escribí código para interactuar con el registro 14:19 <hypercubus> podemos usar eso para configurar una asociación .i2p 14:19 <fvw> cervantes: i2p:// no sería del todo correcto, creo. Al fin y al cabo, es http sobre i2p; igual que podrías tener irc:// sobre i2p. 14:19 <cervantes> también puedes especificar seguridad y ajustes de proxy por protocolo 14:19 <jrandom> cervantes: ¿firefox/etc respetan eso? 14:19 <cervantes> sí 14:20 -!- shardy_ ahora se llama shardy 14:20 <jrandom> vaya, hola shardy_ 14:20 <shardy> hola jrandom, cuanto tiempo 14:20 <cervantes> aunque admito que necesito más pruebas... 14:20 <nicktastic> konqueror también debería 14:20 <cervantes> solo estaba jugando en un rato libre ;-) 14:20 <deer> <ugha2p> Opera no. 14:20 <cervantes> aunque dudo que firefox haga caso de la configuración de proxy y seguridad de Windows 14:20 <hypercubus> puedes configurarlo en el archivo ini de Opera 14:21 <hypercubus> hice eso en Opera para que ed2k:// funcionara 14:21 <deer> <ugha2p> hypercubus: Ah, genial. 14:21 <fvw> solo hasta cierto punto. No puedes convertir manejadores de URL en manejadores http:// gestionados por el propio Opera, por desgracia. 14:21 <hypercubus> aunque no lo documentan muy bien 14:21 <deer> <duck> en serio, ¿qué beneficio aporta i2p://? 14:22 <fvw> hypercube: Supongo que lo pasas a una aplicación auxiliar, ¿no? Hice lo mismo, pero no pude encontrar la forma de que Opera mostrara una página de "descarga iniciada". 14:22 <hypercubus> sí, se le pasa a eMule 14:22 <dm> sí, ¿quién quiere orinar en público de todos modos? 14:22 <hypercubus> podríamos pasar i2p:// al eeproxy 14:22 <hypercubus> luego ustedes, los web guys, pueden averiguar el resto desde ahí ;-) 14:22 <Sciatica> ¿no es https simplemente http sobre, ejem, "s"? 14:23 <jrandom> pero, como creo que duck sugiere, ¿ya estaremos ligados al eepproxy de todas formas? 14:23 <deer> <ugha2p> Sciatica: Es HTTP sobre SSL, sí. :) 14:23 <jrandom> Sciatica: http sobre i2p (bueno, cualquier cosa sobre i2p) es segura y autenticada. lo que pasa después de que llega al otro lado está fuera del alcance de i2p 14:23 <deer> <ugha2p> Pero eso es una convención establecida. 14:24 <Sciatica> sí, lo sabía. Solo digo que el argumento en contra de i2p:// no es tan claro como “¿no es simplemente http sobre i2p?” 14:24 <dm> htt2p 14:24 <hypercubus> no sé si i2p:// es necesario, pero sí creo que es posible hacer que al menos los navegadores principales funcionen con eso 14:24 <deer> <ugha2p> jrandom: Creo que se refería al prefijo 'https://'. 14:24 <jrandom> ah, disculpa. 14:24 <deer> <duck> de todos modos necesitamos un filtro anonimizador más http://127.0.0.1:7657/www.duck.i2p/ 14:25 <deer> <duck> con eso no necesitas retocar la configuración del navegador 14:25 <jrandom> pero sí, estoy de acuerdo con fvw, esto suena a sobrecarga excesiva del protocolo URL 14:25 <demonic_1> no aquí>> como un uso simple creo que los enlaces i2p:// serían geniales <<no aquí 14:25 <jrandom> cierto, duck 14:25 <jrandom> jeje 14:25 <cervantes> quizá i2p:// podría hacerse funcionar como un árbitro de protocolo: i2p://irc/base64 14:26 <fvw> uf, eso es feo y abusar de las URLs de la peor forma posible. 14:26 <deer> <ugha2p> cervantes: ¿Cómo funcionaría eso en el caso de IRC? 14:26 <deer> <duck> URIs :) 14:26 <cervantes> de esa forma puedes lanzar distintas apps basadas en un único estándar de url 14:26 <fvw> (no es que haya nada malo en eso) 14:26 <jrandom> ¿no sería más apropiada la modificación de URL irc://i2p/base64/#i2p ? 14:27 <jrandom> pero, ok, estamos un poco fuera de tema... 14:27 <jrandom> ¿algo más sobre 0.4? :) 14:28 <fvw> No creo que los URI permitan especificar el mecanismo de transporte por separado del protocolo, lo cual es una pena. 14:28 <dm> puedes usar el sistema de archivos 14:28 <fvw> Sí, algo así: *aplausos* 14:28 <dm> c:\i2p\irc #i2p 14:29 <dm> ¡ja! Los confundí a todos 14:29 <deer> * mule_iip está de acuerdo con fvw 14:29 <fvw> dm: Voy a hacerte daño seriamente. Quizá no hoy, quizá no mañana, pero pronto y por el resto de tu vida. 14:29 <jrandom> :) gracias, hacemos lo que podemos 14:29 <fvw> </pinky and the brain> 14:29 <jrandom> jeh 14:29 <jrandom> ok, saltamos a 2) Capacidad y sobrecarga 14:30 <deer> <DrVince> Hola a todos 14:30 <jrandom> preferiría no copiar simplemente lo que se publicó en las notas, así que revisen lo que hay :) 14:30 <dm> hola 14:30 <hypercubus> bienvenido a nuestra reunión, DrVince ;-) 14:30 <deer> <ugha2p> Hola, DrVince. 14:31 <jrandom> algo que me gustaría mencionar respecto a 2) fue algo que algunos han visto: una desviación fuerte en los tunnels participantes 14:31 <jrandom> p. ej., alguien con DSL tenía más de 300 tunnels el otro día 14:31 <dm> yo 14:31 <modulus> sí 14:31 <jrandom> (y cuando se caen, eso rompe un *montón* de tunnels) 14:31 <jrandom> el problema es que los tunnels son realmente livianos: 2–20 bps en promedio 14:31 <cervantes> y mi OC3 tiene prácticamente nada 14:31 <hypercubus> yo solo tengo 8 en este momento 14:32 <dm> yo tenía 270+, y estoy en 150 kbps 14:32 <jrandom> en general, la red tiene ~ 20*n tunnels en promedio en un momento dado 14:32 <jrandom> (donde n = # nodos en la red) 14:32 <jrandom> con un promedio de 2 saltos por nodo, eso significa que cada nodo participa en un promedio de 40 tunnels 14:33 <hypercubus> idealmente ;-) 14:33 <jrandom> bueno, ese es el tema, equilibrar así no es lo ideal 14:33 <jrandom> ya que no todos los nodos son igual de rápidos o tienen el mismo ancho de banda 14:33 <jrandom> por otro lado, equilibrar los tunnels para que todos pasen por 2 o 3 peers muy rápidos también apesta 14:33 <jrandom> ya que si uno de esos cae, ¡boom! 14:34 <hypercubus> correcto, entonces ¿por qué la conexión DSL inferior de dm está tan sobrecargada, mientras que mi conexión DSL mucho más rápida ha sido infrautilizada? 14:34 <Sciatica> ¿este problema desaparecerá a medida que el # de nodos en la red crezca más allá de 100, 200, etc.? 14:34 <dm> ¿inferior? :'( 14:34 <jrandom> hypercubus: porque i2p actualmente no responde al ancho de banda disponible, a menos que la gente active la limitación de ancho de banda 14:34 <hypercubus> dm: técnicamente hablando ;-) 14:34 <hypercubus> ok, yo tengo activada la limitación de ancho de banda... ¿dm no debe tenerla? 14:35 <Sciatica> (en algún punto, ¿no quedará muy empequeñecido el número de nodos que un servidor puede alojar en comparación con el número total de nodos [p. ej., tunnels]? 14:35 <ugha_node> ¡Arrr! 14:35 <ugha_node> '(the local message processing time exceeds 1s)' -- No creo que debamos programar constantes de ese tipo en el router. Creo que todos esos valores deberían tomarse del entorno (de la red I2P), para que siga funcionando en caso de que el router caiga en un entorno inesperado. 14:35 <dm> sí, no la tengo, además mi subida es decente: 256 kbps (bajada 150 kbps) 14:35 <Sciatica> mala terminología: tecleo muy lento para estos temas :-) 14:35 <jrandom> Sciatica: no es un problema, es simplemente una realidad. si cada nodo mantiene 20 tunnels en un momento dado, con cada tunnel con un promedio de 2 saltos, no importa cuán grande sea la red, el promedio se mantiene 14:36 <jrandom> ugha_node: de acuerdo; lo de 1 s es un número al azar, pero ¿cómo podemos derivar el valor "correcto"? ¿qué cantidad de retraso es "mucho"? 14:37 <jrandom> tenemos algo de código en RouterThrottleImpl que rastrea "cuánto ancho de banda hemos acordado asignar" 14:37 <jrandom> pero por el momento, no limita en base a eso 14:37 <dm> hmmmm no me gustan estas discusiones de sobrecarga... me recuerdan a freenet. 14:37 <jrandom> (ancho de banda acordado == # tunnels participantes * # mensajes por tunnel en promedio * # bytes por mensaje en promedio) 14:37 <dm> ¿Quizá deberíamos usar estimadores? 14:38 * jrandom le da una patada a dm 14:38 <hypercubus> dm: ¿estás usando la limitación de ancho de banda en tu router? 14:38 <dm> hypercubus: no 14:38 <hypercubus> dm: te recomiendo mucho usarla ;-) 14:38 <dm> jrandom: tres palabras... NGR 14:38 <fvw> En realidad depende del nodo que solicitó el tunnel, ¿no? ¿Qué clase de lag está dispuesto a tolerar? ¿Sería viable convertirlo en uno de los parámetros del tunnel? 14:39 * fvw se pregunta si dm intenta asustarnos o si es un beneficio añadido. 14:39 <jrandom> hmm, eso tiene potencial 14:39 <dm> errr.. ¿eso no movería el umbral arbitrario al router solicitante? ;) 14:39 <dm> ¡No quiero elegir, elige tú! 14:40 <jrandom> sí, dm, pero el router solicitante sabe para qué se usará el tunnel (irc con poco lag vs. bulk con alto lag y alto rendimiento) 14:40 <fvw> sí, pero para algunas cosas 10 s de lag no son un problema (piensa en transferencias de archivos), mientras que otras (irc) requieren baja latencia. 14:40 <dm> sí, ¿entonces haces que la capa de aplicación decida el umbral? 14:40 <jrandom> eso, sin embargo, es peligroso 14:40 <fvw> el único problema es que usar enlaces de alta latencia no aumentará la capacidad, así que al final las transferencias de archivos se llevan todos los recursos. 14:41 <cat-a-puss> ¿puedes confiar realmente en cualquier afirmación de carga hecha por el router? si no, una persona maliciosa podría intentar hacer que el tráfico de otro nodo pase por todos sus routers 14:41 <jrandom> cat-a-puss: esto solo se usa para rechazar solicitudes de participación, no para solicitarlas 14:41 <ugha_node> No puedes. 14:41 <cat-a-puss> ok 14:42 <jrandom> por supuesto, un usuario malicioso puede aceptar tunnels cuando está totalmente sobrecargado, pero lo detectaremos cuando el tunnel falle 14:42 <jrandom> (y el gorrón puede rechazar el tunnel cuando no está cargado, pero, c'est la vie) 14:43 <jrandom> la limitación basada en sobrecarga local es bastante efectiva; sin embargo, no basta 14:43 <dm> maldito avaricioso 14:43 <jrandom> he estado intentando encontrar una forma ideal de decidir si aceptarlo o no, y creo que hay potencial para rechazar probabilísticamente solicitudes que de otro modo aceptaríamos, según cuántos tunnels ya tengamos 14:44 <jrandom> la idea es que el peer quiere que otros asuman parte de la carga 14:44 <cat-a-puss> ¿deberíamos ejecutar tantos routers virtuales como ancho de banda disponible? 14:44 <jrandom> (para distribuir el fallo) 14:44 <jrandom> hmm cat-a-puss? 14:44 <jrandom> ¿estás ejecutando la simulación en la red en vivo? 14:45 <jrandom> en cualquier caso, no, un solo router debería poder manejar la capacidad local 14:46 <deer> <mule_iip> el problema es que el ancho de banda usado en un tunnel puede cambiar significativamente con el tiempo, ¿no? 14:46 <cervantes> lo que no está pasando actualmente... al menos no para mí 14:46 <cat-a-puss> bueno, si todo es aleatorio, ¿cómo puedes aprovechar un OC3 más que un pobre con un 56k? O tienes que anunciarlo: problemático, o ejecutar routers virtuales; de cualquier modo creo que una parte maliciosa podría intentar cercar un nodo para algún tipo de ataque estadístico 14:46 <jrandom> correcto, mule_i2p. necesitamos monitorizar más la actividad de los tunnels 14:46 <cervantes> 14 participantes cada uno con 11.5 mbit ... es un poco desperdicio :) 14:47 <jrandom> cat-a-puss: probabilístico != aleatorio :) 14:47 <jrandom> jeh, cervantes 14:48 <jrandom> la idea básica de rechazar probabilísticamente sería distribuir la carga hacia otros peers. sin embargo, si la red realmente está saturada, la probabilidad no será un problema porque la gente simplemente volverá a preguntar 14:48 <jrandom> el tema es que actualmente tenemos un *exceso* abrumador de capacidad 14:48 <Sugadude> Pobre i2p, con *demasiada* capacidad. No te preocupes, ya me encargo. ;) 14:49 <fvw> suponiendo que todos se porten bien, quizás podrías no rechazar a quienes vuelvan dentro de un intervalo corto tras ser rechazados de forma probabilística? 14:49 <deer> <mule_iip> entonces llena cualquier tunnel con algo de tráfico de cobertura 14:49 <jrandom> jeh, Sugadude :) 14:49 <cervantes> eso es porque las solicitudes de todos las maneja el router de dm ;-) 14:49 <jrandom> fvw: no sabemos quién solicita un tunnel 14:49 <fvw> hmm, buen punto. *se atornilla la cabeza de nuevo* 14:50 <jrandom> fvw: de forma probabilística, las solicitudes subsiguientes se aceptarían; querríamos que el factor de 'rechazo' se mantenga lo suficientemente bajo 14:50 <deer> <mule_iip> lo cual aumentará el anonimato y facilitará el cálculo de carga 14:51 <jrandom> cierto, mule_iip, pero sería bueno que la red funcionara eficazmente sin requerir alta carga :) 14:51 <jrandom> pero ese es definitivamente un escenario interesante para la simulación 14:51 <deer> <mule_iip> en efecto, hacer que i2p use un bitrate constante con tráfico de cobertura. pero eso sería para un lanzamiento futuro, supongo :) 14:52 <jrandom> podríamos usar una asignación al estilo ATM 14:52 <fvw> ¿El uso de ancho de banda no varía demasiado como para que eso sea viable? 14:52 <jrandom> p. ej., supón 5 mensajes por minuto por tunnel a 32KB cada uno, y compáralo con los límites de ancho de banda, y rechaza en consecuencia 14:52 <cervantes> hyper tiene algo de ASCII que podemos usar para rellenar los mensajes 14:52 <hypercubus> hmmmm, no me gusta esa idea de bitrate constante... los ISP filtrarían i2p muy rápidamente si se implementara 14:53 <jrandom> jeh, cervantes 14:53 <deer> <kaji> sí 14:53 * hypercubus no sabe de qué habla cervantes 14:53 * hypercubus esconde su disquete 14:53 <jrandom> fvw: ¿relleno? ¿o asignación? 14:53 <fvw> asignación 14:53 <cervantes> ah, sí, negación plausible, ¿eh? 14:54 <jrandom> hmm, fvw. quizá, pero creo que podemos monitorizarlos estadísticamente y compensar 14:54 <deer> <kaji> bitrate constante suena a Waste 14:54 <jrandom> por ejemplo, http://localhost:7657/oldstats.jsp#tunnel.bytesAllocatedAtAccept 14:54 <hypercubus> de ahí su nombre ;-) 14:55 <jrandom> esa estadística monitoriza cuánto ancho de banda hemos acordado pasar para los tunnels de otras personas 14:55 <jrandom> (usando los últimos 10 minutos como guía) 14:56 <jrandom> así que mi peer con 85 tunnels dice que transferirá 3,676,945.65 bytes durante los próximos 10 minutos para todos esos tunnels combinados 14:56 <deer> <mule_iip> kaji: es desperdicio, y probablemente deberíamos usarlo solo para modelos de amenaza más severos. pero sería bueno para baja latencia como irc. 14:56 <jrandom> eso son 72 bps por cada uno, pero no estoy seguro de cuán sesgado está (probablemente *muy*) 14:57 <jrandom> sin embargo, si todos esos tunnels empezaran a usar muchísimo ancho de banda, el valor total se dispararía, y podríamos limitarlo 14:57 * fvw asiente. 14:57 * fvw señala que de hecho es un problema tremendamente interesante, teóricamente hablando. 14:57 <fvw> (aunque quizá solo soy raro) 14:57 <jrandom> de acuerdo 14:58 <jrandom> (a ambos ;) 14:58 <jrandom> pero sí, no tenemos la Respuesta Correcta todavía. pero es algo en lo que trabajar 14:59 <jrandom> ok, salvo que haya algo más sobre eso, pasamos a 3) Actualizaciones del sitio web 14:59 <fvw> Podríamos, por supuesto, ir totalmente con pérdida y simplemente soltar datagramas cuando estemos sobrecargados, y hacer que la gente ejecute algo como tcp encima. 14:59 <jrandom> probamos eso, y un montón y montón y montón de tunnels fallaron 15:00 <jrandom> (ya que si un tunnel pierde 1 mensaje, lo marcamos como fallido) 15:00 <fvw> sí, no deberías hacer eso si tomas ese enfoque. 15:00 <jrandom> ((y cuando intentamos no ser tan fascistas, no notamos cuando un tunnel falla de verdad)) 15:00 * fvw asiente y se acaricia la barba. Buen punto. (nota mental: dejarse barba para acariciarla en situaciones como esta) 15:01 <jrandom> jeh 15:01 <jrandom> ok, de todos modos, como han visto, nuestro nuevo instalador y la nueva interfaz web son completamente diferentes a la forma antigua de hacer las cosas 15:01 * hypercubus le presta a fvw su barba 15:02 <jrandom> aunque eso es Bueno, ya que la forma antigua era Dolorosa, toda nuestra documentación antigua ahora es tremendamente incorrecta 15:02 <fvw> ¿podemos quedarnos en 2) unos minutos más? Aún tengo algunas malas ideas que quiero que derriben. 15:02 <jrandom> claro 15:02 <dm> no puedo usar Internet... 15:02 <dm> Ancho de banda entrada/salida 15:02 <dm> 1m: 13.32/11.98KBps 15:02 <dm> 5m: 10.74/9.46KBps 15:02 <jrandom> ¿cuántos tunnels, dm? 15:02 <hypercubus> dm: por eso te sugerí que activaras la limitación de ancho de banda de i2p ;-) 15:02 <dm> solo 166 15:02 <jrandom> sí, limítalo a 6KBps 15:02 <jrandom> lol 15:03 <dm> (participando) 15:03 <jrandom> (o quizá 8KBps si eres amable) 15:03 <dm> Lo dejaré así, solo necesito ver esta página 15:03 <jrandom> por cierto, el 13.32 vs 11.98 nos dice que estás descargando aproximadamente 1KBps localmente 15:03 <jrandom> (a través de i2p) 15:03 <fvw> ¿Qué pasa si simplemente hacemos time-out a los tunnels tras un tiempo de inactividad razonablemente grande? Digamos 30 min o algo así. El siguiente protocolo tendría que hacer keepalives, pero ¿no solucionaría eso lo de no detectar tunnels muertos? 15:03 <hypercubus> en realidad está descargando mucho más que eso 15:04 <jrandom> ((aunque ese 1KBps puede ser lo bastante pequeño como para ser netDb)) 15:04 <dm> hypercubus: nuestra transferencia se está atascando bastante, en realidad. 15:04 <jrandom> fvw: los tunnels expiran tras 10 minutos 15:04 <deer> <kaji> un momento, ¿el ancho de banda funciona ahora? si es así, ¿a qué debería ponerlo? 15:04 <dm> decepcionado con la combinación getright/i2p 15:04 <jrandom> no son de larga duración, fvw, a diferencia de TOR 15:04 <fvw> ¿y eso hizo que la mayoría de los tunnels fallaran, incluso con keepalives? 15:04 <hypercubus> dm: periódicamente sí... creo que la solución sería limitar tu subida a unos 8KB/s 15:04 <jrandom> kaji: http://localhost:7657/ 15:05 <hypercubus> ya que parece que estás saturado 15:05 <jrandom> eh, /config.jsp 15:05 <fvw> ok, pero no quieres que desaparezcan en borbotones de pérdida de paquetes. 15:05 <jrandom> cada minuto (en promedio) cada peer prueba cada tunnel para asegurarse de que está vivo (para que otras personas puedan enviarnos datos; sin tunnels, estamos jodidos) 15:06 <fvw> Ok. Necesito leer más sobre cómo i2p funciona actualmente. Por mí, pasemos al 3). 15:06 <deer> <kaji> ahora está en el valor por defecto -1, pero no sé a qué se traduce una conexión 1.5/750@1.2ghz en cuanto a participación máxima en tunnels 15:07 <deer> <kaji> parece que estoy participando en 166 15:07 <jrandom> kaji: tu router nunca tendrá tantos tunnels como para congestionar la CPU ;) 15:07 <deer> <mule_iip> off-topic: ¿no necesitas un tunnel para estar jodido? :) 15:07 <deer> <kaji> *ing 15:07 <jrandom> jeh 15:07 * fvw vota "no" 15:08 <deer> <kaji> jrandom, acabo de terminar de leer la carta sobre tunnels sin ancho de banda, solo que no sabía a qué poner el límite 15:08 <jrandom> ok, de acuerdo, hay mucho más por hacer para resolver estas cosas 15:08 <jrandom> ok, genial, kaji, solo activa tu limitador de ancho de banda a algo como 8KBps 15:08 <jrandom> (o 12 si eres amable :) 15:09 <deer> <kaji> </oftopic> 15:09 <jrandom> ok, pasamos a 3) actualizaciones del sitio web 15:09 <deer> <kaji> ¿entrada y salida? 15:09 <jrandom> sí, kaji 15:09 <jrandom> ok, como decía, necesitamos ayuda con la documentación 15:09 <jrandom> (¡ayudaaaaaaaa!) 15:09 <hypercubus> propongo que cubramos los puestos del equipo, vacantes hace tiempo, de Webmaster y Editor Web 15:10 * jrandom secunda la moción 15:10 <jrandom> (ahora solo falta que alguien se ofrezca ;) 15:10 <hypercubus> sé que cervantes es un tipo ocupado 15:10 <jrandom> depende más del individuo ofrecerse /a sí mismo/, hyper ;) 15:10 <hypercubus> propongo a Curiosity como Webmaster o Editor Web, o ambos si se anima ;-) 15:11 <deer> <ugha2p> Uhh. 15:11 <dm> Vaya, hasta mi CPU empieza a ponerse al 100% por culpa de I2P... 15:11 <dm> Me aman, REALMENTE me aman :'( 15:11 <dm> ups, :') 15:12 * cervantes siente que lo empujan al ruedo 15:12 <jrandom> creo que toda la ayuda posible nos viene bien, y si ella está dispuesta a ayudar, nos encantaría 15:13 <hypercubus> he visto sus diseños web y puedo dar fe de su trabajo 15:13 <hypercubus> y expresó interés, aunque no sé qué decidió al final 15:13 <jrandom> ok, genial 15:13 <dm> ¿ella? 15:13 <cervantes> seguro que podrá dedicarle mucha más atención y cuidado de lo que yo podría 15:14 <dm> esa palabra no debe usarse en nuestro mundo 15:14 <fvw> eso sin contar con que dijo 'cuidado y atención'. 15:15 * jrandom gime 15:15 <fvw> presentes excluidos, por supuesto. 15:15 <jrandom> ok, en cualquier caso, necesitaremos gente que ayude con los documentos: generar nuevos recorridos, documentos introductorios, etc. 15:16 <jrandom> hablaremos con Curiosity sobre en qué podemos hacer que hackee :) 15:16 <hypercubus> puedo encargarme de lo relacionado con la instalación 15:16 <hypercubus> s/on/of/ 15:16 <hypercubus> sé lo mucho que a todos les encanta leer esos manuales barrocos que escribo ;-) 15:16 <jrandom> :) 15:17 <jrandom> una guía/recorrido de instalación sería estupenda 15:17 <fvw> así no se escribe 'broke'. 15:17 <jrandom> jeh 15:17 * hypercubus se ríe por lo bajo, luego le roba la cartera a fvw 15:17 <hypercubus> así se escribe "broke" ;-) 15:17 <deer> <kaji> hyper, ¿en qué sistema estás? yo le daré un intento a la versión WinXP pero no soy muy fiable, puede que vea algo brillante y me rinda 15:17 <deer> * Curiosity está ausente un rato... 15:18 <hypercubus> kaji: ? 15:18 <deer> <kaji> hyper, te preguntaba qué SO usas 15:18 <hypercubus> SOs 15:18 <deer> <kaji> SOSES 15:19 <hypercubus> tengo vmware, así que puedo ejecutar todos los windowses y freebsd y demás 15:19 <hypercubus> también tengo PearPC, así que puedo ejecutar OS X 15:20 <jrandom> ok, si no hay nada más del lado web 15:20 <jrandom> pasamos a * 4) Interfaz web de I2PTunnel 15:21 * jrandom declara que la interfaz web de i2ptunnel es una mierda. funcional. pero una mierda. 15:21 <deer> <DrVince> Podría meterme con la traducción al francés si hay interés tal vez 15:21 <jrandom> duck tenía algunas ideas para mejorarla, pero tuvo que irse, así que voy a pegar unas líneas 15:21 <hypercubus> de nuevo, necesitamos más desarrolladores web ;-) 15:21 <jrandom> oh, traducir páginas web al francés estaría genial 15:22 <jrandom> s/french/french and other langs/ 15:22 <jrandom> aquí van algunas 'duck-adas': 15:22 <jrandom> <duck> reducir la carga de datos en la página general; usar tablas/div para ordenar las cosas 15:22 <jrandom> <duck> proveer una página de edición/detalle con información que a la mayoría no le importa: tunnels, hash del destino, clave completa 15:22 <jrandom> <duck> retroalimentación tras hacer clic en botones, 'elemento guardado', etc. dar el destino como salida cuando se cree uno nuevo 15:22 <jrandom> <duck> (ocultarlo bajo edición/detalles en caso contrario) 15:22 <jrandom> <duck> etiquetar los mensajes de arriba como 'log'; a veces es confuso 15:22 <jrandom> <duck> dejar claro que 'confirmar' solo se necesita para eliminar, no para guardar 15:22 * jrandom está de acuerdo con lo que dice 15:23 <jrandom> también ha habido un montón de correcciones de errores tras bambalinas en la interfaz web /i2ptunnel/ desde 0.4, así que los problemas funcionales deberían estar depurados 15:24 <jrandom> sin embargo, el código que implementa esas páginas es bastante feo 15:24 <jrandom> probablemente el mejor enfoque sería escribir las pantallas en HTML/CSS/imágenes/etc. y luego dárselo a uno de los desarrolladores Java para integrarlo 15:25 <hypercubus> ¿qué fue de los tiempos en que había superabundancia de desarrolladores web? ;-) 15:25 <jrandom> todos están trabajando en McDonald's 15:25 <hypercubus> ah, cierto 15:25 <deer> * Curiosity ha vuelto :) 15:25 <jrandom> de todos modos, si alguien está interesado en ayudar o tiene más sugerencias, por favor pónganse en contacto 15:25 <jrandom> bienvenida de vuelta, Curiosity 15:26 <deer> <Curiosity> ¿debería sacar la idea de la que te hablé, jrandom? 15:26 <cat-a-puss> conozco a alguien que podría ayudar con lo web 15:26 <jrandom> ah, ¿el live cd? 15:27 <jrandom> genial, cat-a-puss, necesitamos toda la ayuda posible 15:27 <deer> <Curiosity> sipa :) 15:27 <deer> <Curiosity> err sí 15:27 <jrandom> Curiosity: sí, por favor, coméntalo cuando lleguemos al punto 6) ??? 15:28 <deer> <Curiosity> ok :) 15:28 <cat-a-puss> ok, los pondré en la lista, y les daré el e-mail de jrandom (curiosity no sé tu correo) 15:28 <jrandom> ok, ¿alguien tiene algo más que mencionar respecto a la interfaz web de I2PTunnel? 15:28 <jrandom> r0x0r cat-a-puss 15:29 <deer> <Curiosity> tampoco me importa ayudar con la edición web, etc. :) 15:29 <jrandom> ok, si no hay nada más, 5) Hoja de ruta y todo 15:30 <jrandom> ¡genial, Curiosity, gracias! podemos charlar un poco después de la reunión sobre conquistar el mundo^W^W^W^Wlas cosas web 15:30 <deer> <Curiosity> ok :) 15:30 <jrandom> como probablemente vieron, hay una nueva página grande y aterradora en el sitio web (http://www.i2p.net/todo) 15:31 <jrandom> que cubre los grandes y aterradores asuntos que tenemos por delante (y ni siquiera menciona todas las apps cliente que necesitamos, etc.) 15:31 <jrandom> como pueden ver, tenemos un montón enorme por hacer, pero la buena noticia es que no tenemos que tenerlo todo hecho de inmediato. 15:32 <jrandom> de hecho, esas cosas son básicamente los puntos con viñetas de la página del roadmap (con un montón de texto introduciendo cada una) 15:33 <jrandom> aunque sé que es mucho para revisar, sería genial que la gente me avisara si se topa con algo que tengamos que abordar y que no esté en esa página 15:34 <jrandom> no es necesario hoy ni esta semana, solo un general "hey, avísennos" 15:35 <jrandom> con la sugerencia de mule (http://www.i2p.net/todo#nat) he estado haciendo mucha reflexión, y probablemente movamos un poco la hoja de ruta 15:35 <jrandom> pero ya veremos. 15:36 <jrandom> si tienen sentimientos fuertes sobre ciertos temas ("¡OMG no podemos funcionar sin X, Y y Z!"), por favor háganmelo saber o publíquenlo en la lista 15:36 <jrandom> aunque no soy adalid de la democracia, estoy abierto a la razón :) 15:37 <jrandom> ok, eso es todo lo que tengo que decir al respecto... ¿alguien quiere aportar algo? 15:37 <deer> <Curiosity> dictadura benigna :) 15:37 -!- Sonium_ ahora se llama Sonium 15:37 <jrandom> bah, no soy dictador: no controlo lo que los demás programan :) 15:37 <cervantes> hegemonía tranquila 15:37 <cat-a-puss> he conseguido dos desarrolladores más 15:37 <jrandom> ¡w00t! 15:38 <cat-a-puss> y tengo grandes planes para un motor de búsqueda distribuido 15:38 <jrandom> oh, qué bien 15:38 <jrandom> ¿sería algo con lo que http://files.i2p/ podría integrarse? 15:38 <jrandom> o, bueno, permíteme decir: oh, qué bien :) 15:38 <cat-a-puss> eh: no puedo llegar ahí (entorno hostil) 15:39 <jrandom> ah 'k 15:39 <cat-a-puss> de todos modos, algo de espacio en CVS estaría bien, cuando lleguemos a eso 15:40 <jrandom> por supuesto, hay espacio disponible en cvs.i2p 15:40 <jrandom> ya sea dentro del directorio i2p/apps/ o en su propio módulo, si lo prefieren 15:40 <jrandom> (cvs.i2p == cvs.i2p.net) 15:40 <cat-a-puss> probablemente debería hablar con la gente que está trabajando en el dht, ¿eh? 15:41 <cat-a-puss> ¿cuál es el estado de eso hasta ahora? 15:41 <jrandom> :) 15:41 <jrandom> no he oído actualizaciones de estado de aum en los últimos días, pero seguro que está trabajando 15:42 <jrandom> la última actualización fue en http://dev.i2p.net/pipermail/i2p/2004-August/000425.html 15:43 <jrandom> ok, supongo que eso nos lleva a * 6) ??? 15:44 <jrandom> Curiosity estaba barajando la idea de un 'live cd' con i2p 15:44 <jrandom> lo cual me parece bastante bueno, y algo que querremos 15:44 <deer> <Curiosity> kewl :) 15:44 <jrandom> aunque aún no somos lo bastante estables para eso, con una versión cada 2 semanas o así 15:44 <hypercubus> de acuerdo... incluso podría integrarse en un ISO de Knoppix 15:45 <deer> <Curiosity> ? 15:45 <hypercubus> Knoppix, una distro de linux en livecd 15:45 <hypercubus> muy fácil de usar 15:45 <deer> <Curiosity> ok 15:45 <jrandom> aunque una vez tengamos la funcionalidad Really Simple Update que sea una descarga de un clic desde http://dev.i2p/i2p/i2pupdate.tar.bz2, puede que no sea tan malo 15:46 <jrandom> Curiosity: ¿tienes algo más que quieras comentar sobre eso? 15:46 <fvw> ...y en cuanto se use mucho, cualquiera que controle dev.i2p puede comprometer la red. 15:47 <jrandom> siempre que la gente use esa funcionalidad Really Simple Update 15:47 * fvw asiente. 15:47 <deer> <Curiosity> solo quería una forma para que la gente lo ejecute sin tener que descargar un montón de cosas en su computadora 15:47 <jrandom> (y si comprometen dev.i2p, ponemos una nueva entrada de hosts.txt para dev.i2p) 15:48 <hypercubus> un livecd de i2p con knoppix sería ideal para usar en cibercafés 15:48 <deer> <mule_iip> jarndom: ¿no tomará un usuario real de i2p el código fuente, estudiará el diff frente a la última versión revisada por pares y compilará desde el código? :) 15:48 <fvw> sí, pero la gente solo pulsará 'update'; no atenderán a discusiones sobre si la nueva versión podría tener vulnerabilidades... 15:48 <demonic_1> ¿hay alguna forma de no necesitar el archivo de hosts? ya sabes, como un servidor DNS? 15:48 <deer> <Curiosity> sí... claro, mule_iip. jaja 15:49 <fvw> pero de todos modos, estaré muy feliz cuando lleguemos al punto donde esto se convierta en un problema. 15:49 <fvw> demonic_l: Es posible, pero seguiría habiendo una autoridad central. 15:49 <hypercubus> demonic_1: actualmente hay un par de propuestas para esa funcionalidad, pero se han descartado los nombres globales 15:49 <jrandom> demonic_1: sí, ve a la lista de correo (discusiones recientes en http://dev.i2p.net/pipermail/i2p/2004-September/000432.html ) 15:49 <jrandom> (y mi postura @ http://dev.i2p.net/pipermail/i2p/2004-September/000435.html :) 15:50 <hypercubus> *nombres globalmente únicos 15:50 <demonic_1> k 15:51 <jrandom> ok, ¿alguien tiene algo más que quiera comentar? 15:52 <deer> <Curiosity> También me gustaría sugerir poner los elementos solo de servicio en una carpeta service... estaba intentando desinstalar i2p (una de tantas) y le estaba dando a la cosa de desinstalación equivocada 15:52 <hypercubus> Curiosity: eso se está haciendo 15:52 <jrandom> w3rd 15:52 <hypercubus> el instalador instalará accesos directos de i2p en el menú Inicio de Windows 15:52 <hypercubus> y opcionalmente en tu escritorio 15:52 <deer> <Curiosity> ok :) 15:52 <hypercubus> entre ellos estará "uninstall" 15:53 <deer> <Curiosity> hablaba de cuando voy a program files/i2p 15:53 <hypercubus> no necesitas hacerlo desde ahí 15:54 <hypercubus> los usuarios de Windows nunca entran en las carpetas de programas ;-) 15:54 <demonic_1> :/ 15:54 <deer> <Curiosity> ¡yo sí! :P 15:54 <jrandom> quizá podríamos añadir un directorio bin/ con todos los scripts 15:54 <jrandom> eh, nada 15:54 <hypercubus> entonces habrías visto la carpeta llamada "Uninstall" ;-) 15:54 * jrandom recuerda las rutas 15:54 <hypercubus> que es donde está el desinstalador 15:54 <jrandom> podemos mover los scripts de servicio a lib, eso sí 15:54 <hypercubus> no estoy seguro de que podamos 15:55 <cervantes> podrías ir por el método 'doze y tener la opción "uninstall" en el instalador ;-) 15:55 <hypercubus> wrapper es muy quisquilloso con dónde pones eso 15:55 <jrandom> como mínimo pueden hacer "cd .." primero 15:55 <hypercubus> veré lo de cambiar su ubicación 15:55 <hypercubus> pero puede que no se pueda 15:55 <jrandom> genial, gracias. estaría bien eliminar parte del desorden en el directorio de instalación 15:55 <hypercubus> de acuerdo 15:55 <jrandom> (la mayoría es culpa mía con todos esos archivos .config :) 15:56 <hypercubus> supongo que podríamos tener un directorio config 15:56 <cervantes> ./conf ? 15:56 <jrandom> vamos, somos geeks. etc/ :) 15:56 <jrandom> eso sería Muy Fácil 15:56 <jrandom> (solo unos pocos parámetros -D en la CLI) 15:56 <hypercubus> entonces tendremos que responder preguntas de usuarios de Windows diciendo que "etc" no es lo bastante obvio ;-) 15:56 <jrandom> la gente no debería tener que tocar su configuración 15:57 <jrandom> para eso está la web 15:57 <cervantes> yo siempre he optado por lo evidente: ./configuration/ 15:57 <hypercubus> cierto, pero los usuarios de Windows tampoco deberían lanzar el desinstalador desde su directorio de programas jejeh 15:57 <jrandom> ./thesefilestellstufftodothings/ 15:57 <cervantes> ./scripts/ 15:57 <cervantes> ./asciipr0n 15:57 <jrandom> ok, pero sí, algo de trabajo que podemos detallar 15:57 <deer> <Curiosity> lol 15:58 <jrandom> ¿alguien tiene algo más que aportar para la reunión? 15:58 <jrandom> si no 15:58 * jrandom se dispone 15:59 * jrandom *baf* cierra la reunión