Reunión de desarrolladores de I2P - 08 de marzo de 2005

13:06 <@jrandom> 0) hola 13:06 <@jrandom> 1) 0.5.0.2 13:06 <@jrandom> 2) actualizaciones de mail.i2p 13:06 <@jrandom> 3) actualizaciones de i2p-bt 13:06 <legion> entonces, ¿está relacionado con los servidores de IRC? 13:06 <@jrandom> 4) ??? 13:06 <@jrandom> 0) hola 13:06 <@jrandom> notas de estado semanales publicadas @ http://dev.i2p.net/pipermail/i2p/2005-March/000633.html 13:07 <fedo> hi 13:07 <+postman> hi 13:07 <frosk> buen día 13:07 <@jrandom> legion: no, relacionado con bugs de i2p, se está trabajando en ellos 13:07 <bla> hi 13:07 <legion> ok 13:07 <@jrandom> hablando de bugs en los que se está trabajando, pasemos a 1) 0.5.0.2 :) 13:07 <cervantes> hola 13:07 <cervantes> -- Desconectado 13:08 <@jrandom> je 13:08 <ant> <mihi> hola a todos 13:08 <@jrandom> 0.5.0.2 ya salió, y aunque tu conexión de IRC pueda tener lag a veces, se recuperará ;) 13:08 <@jrandom> guau, hola mihi 13:09 <cervantes> hey mihi 13:09 <@jrandom> las notas de estado dan una visión general de dónde estamos y las prioridades más inmediatas 13:10 <@jrandom> lo preocupante que estoy tratando de rastrear se puede ver en http://localhost:7657/oldstats.jsp#router.invalidMessageTime 13:10 <bla> En lo que a mí respecta, puedo decir que 0.5.0.2 ya mejoró la fiabilidad _enormemente_ comparado con 0.5.0.1: los errores donde no se podían contactar destinos casi ya no ocurren 13:10 <@jrandom> esos números deberían ser muy muy pequeños, pero no lo son, por desgracia 13:10 <@jrandom> genial, bla 13:11 <@jrandom> sí, 0.5.0.2 es definitivamente una mejora, y todos deberían actualizar cuanto antes 13:11 <bla> 375,932.22 en los últimos 10 minutos aquí.... 13:11 <@jrandom> bueno, el valor en sí no es realmente el problema, es su frecuencia 13:11 <@jrandom> (eventos por período) 13:12 <@jrandom> esos mensajes probablemente se puedan atribuir a routers 0.5, y parte a routers 0.5.0.1, por eso quiero que la gente actualice cuanto antes 13:12 <@jrandom> podría ser que fuera otra cosa, pero me gustaría descartarlo 13:12 <bla> jrandom: aquí me llegan unos 200 por hora 13:13 <@jrandom> bla: ahora mismo tengo 93 esta hora, pero el pico mucho más alto (miles) 13:13 <@jrandom> de todos modos, esta estadística en particular se publica en el netdb 13:13 <bla> jrandom: ¿Qué tal excluir 0.5-0 de la red por software al lanzar 0.5.0.3? 13:14 <@jrandom> así podemos mirar y ver qué valores tienen los demás ;) 13:14 <@duck> 309,854.24 pico 5,473,314.59 13:15 <@duck> pegando el equivocado, ¿eh? 13:15 <@jrandom> bla: definitivamente. Añadí algo de código en la revisión 0.5.0.2 para cierta compatibilidad hacia adelante que 0.5.0.1 y 0.5 no tienen 13:16 <@jrandom> duck: es difícil tener un número no entero de eventos ;) 13:16 <bla> jrandom: Bien. Al menos eso te permite probar tu hipótesis de que los mensajes inválidos se deben a 0.5-0 de forma controlada 13:16 <@jrandom> bla: sí, aunque sería genial si la gente actualizara antes ;) 13:17 <@jrandom> (así que para los que leen en casa: http://www.i2p.net/download es su amigo ;) 13:17 <maestro^> jr: ¿esos números de desviaciones de router.invalidMessageTime están en ms? 13:17 <@jrandom> maestro^: sí 13:18 <@jrandom> (o sea, valores realmente desfasados de locura) 13:18 <legion> Aquí hay un pequeño informe de la red [version|Número de nodos][0.5|6][0.5.0.1|39][0.5.0.2|107] 13:18 <@jrandom> sí, han sido geniales actualizando 13:18 <legion> Así que aún hay algunas personas con 0.5 y muchas con 0.5.0.1 13:18 <maestro^> entonces, ¿alguna idea de dónde podrían estar fallando? 13:18 <bla> jrandom: Freenet tiene un indicador (flag) en cada versión que especifica la versión mínima de nodo con la que se comunicará. ¿El nuevo código de compat. hacia adelante es algo así? 13:19 <@jrandom> maestro^: muchísimas ideas de por qué los usuarios de 0.5 y 0.5.0.1 están teniendo retrasos. 13:19 <@jrandom> bla: similar 13:19 <maestro^> ¿o es deriva del reloj en los nodos? 13:20 <@jrandom> maestro^: skew del reloj, algunos bugs de serialización, el bug de CPU al 100% 13:20 <@jrandom> ok, ese es en general mi enfoque ahora mismo, intentar recuperar la fiabilidad de los mensajes 13:21 <@jrandom> ¿Alguien tiene preguntas/comentarios/preocupaciones sobre 0.5.0.2? 13:21 <ant> * mihi tiene un router 0.4.2.5 aquí en el disco duro que no se inicia desde el 22 de dic... pero cree que mejor lo borra... 13:21 <@jrandom> je 13:21 <@jrandom> sí, ese no hablará con demasiados routers ;) 13:21 * postman tiene una copia de respaldo de su última instalación 0.4 :) 13:21 <ant> <mihi> la pregunta para mí sería actualizar o borrar. 13:22 <@jrandom> borrar 13:22 <@jrandom> (respaldando cualquier clave de destino) 13:22 <@jrandom> ya no hay procedimiento de actualización desde antes de 0.5 13:22 <legion> Quizá sacar otra actualización, digamos 0.5.0.2-1, que solo permita conexiones desde 0.5.0.2 o más nuevo, ¿sería bueno? 13:22 <@jrandom> legion: eso segmentaría la red 13:22 <@jrandom> la gente simplemente debería actualizar. 13:23 <@jrandom> (y deberíamos sortear a quienes no lo hagan) 13:24 <legion> sí, hasta que la gente que ejecuta nodos desactualizados actualice ;) 13:24 <@jrandom> segmentar la red nos perjudica a todos, no solo a ellos 13:25 <legion> Quizá si hubiera una notificación de actualización en la consola del router o algo que les hiciera saber que están ejecutando versiones desactualizadas? 13:25 <@jrandom> sí, eso sin duda estaría muy bien 13:25 <@jrandom> ojalá eso se pueda vincular también con el actualizador 13:26 <legion> sí, lo sé, la segmentación es mala... 13:26 <@jrandom> smeghead está trabajando en algunos componentes clave de eso, aunque no estoy seguro si incluye la notificación/descarga 13:26 <@jrandom> (¡así que si alguien quiere ayudar con eso, pónganse en contacto!) 13:27 <@jrandom> ok, pasando a 2) actualizaciones de mail.i2p 13:27 <@jrandom> postman: ping 13:27 <+postman> sí 13:27 <bla> jrandom: smeghead estaba haciendo cosas relacionadas con firma si mal no recuerdo (IIRC) (para que cuando recibas un aviso de actualización, al menos sepas que es real, y no una cosa de phishing/spyware/basura) 13:28 * postman toma el micrófono 13:28 <legion> hmm, quizá si hubiera una función de autoupdate integrada, donde las actualizaciones se descargarían a través de i2p y los nodos simplemente descargarían la actualización, luego harían un reinicio elegante. 13:28 <@jrandom> cierto, bla 13:28 <ant> <Gatak> Ah, por cierto. ¿Funcionaría I2P detrás de NAT incluso si no puedes abrir un puerto? 13:28 <@jrandom> Gatak: aún no. algunas personas podrán en 0.6, otras en 2.0 13:29 <@jrandom> legion: parches bienvenidos 13:29 <ant> <Gatak> 2.0 caray, eso está muy en el futuro =) 13:29 <@jrandom> (http://www.i2p.net/roadmap#2.0 ;) 13:29 <+postman> ehm, ¿empiezo ahora? 13:29 <aum> buenos días a todos 13:30 <@jrandom> el micro es todo tuyo, postman (perdón ;) 13:30 <@jrandom> hola, aum, llegaste a la reunión 13:30 <@jrandom> (¡d'oh! /me se calla de nuevo) 13:30 <cervantes> Gatek: http://www.i2p.net/roadmap 13:30 <+postman> primero, quería decir que ya alcanzamos 300 cuentas registradas en postman.i2p 13:30 <@jrandom> w00t 13:30 <+postman> el número de correos desde/hacia Internet está creciendo de forma constante y una vez más demuestra que necesitamos avanzar 13:31 <cervantes> *squeeeel* 13:31 <+postman> tras hablar con jr hace unas semanas acordamos publicar v2mail junto con I2P 1.0 13:31 <+postman> el estado reciente es: el proxy SMTP basado en Java diseñado para ejecutarse en cada nodo está terminado 13:31 <@jrandom> ¡genial! 13:32 <+postman> el proxy POP3 basado en Java está al 80%, faltando solo el motor de maildir 13:32 <+postman> habrá un gestor web que aún necesita bastante ajuste (15% hecho) 13:32 <+postman> la comunicación entre nodos va al 40%: probamos algún intercambio de registros de datos con HTTP/XML 13:33 <+postman> parece funcionar bastante bien e incluso rápido 13:33 <+postman> incluso si un nodo relé falla/estuvo apagado unos días, se sincronizará en pocos minutos tras volver a estar en línea 13:33 <@jrandom> buenísimo 13:33 <+postman> creo que vamos bastante en camino 13:34 <+postman> una cosa es notable 13:34 <bla> postman: ¡Buen trabajo, hombre! Una pregunta: muchos nodos no pueden recibir o enviar datos por el puerto 25 (no directamente, al menos). ¿Los propietarios de nodos podrán especificar esto (o se detectará automáticamente)? 13:34 <cervantes> cool 13:34 <+postman> bla: más adelante 13:34 <+postman> en v2mail habrá una aplicación web local 13:34 <+postman> con esto podrás gestionar tus proxies locales Y solicitar una “relayaccount” (cuenta de relé) 13:35 <+postman> esta relayaccount se usará para asociar tu dirección/dominio a los relés 13:35 <+postman> los relés sincronizarán la información automáticamente 13:35 <@jrandom> cool 13:35 <+postman> incluso funciones como la libreta de direcciones / claves públicas y demás funcionarán con la interfaz LOCAL 13:36 <+postman> así que la idea es tener un gestor centralizado donde puedas hacer todo lo relacionado con tu correo 13:36 <+postman> los datos relevantes se transfieren a UNO de los relés y luego se sincronizan entre los relés 13:36 <+postman> y este gestor basado en web se ejecutará en tu propio nodo 13:37 <+postman> cuando tu nodo esté en línea, los relés entregarán los correos en cola para tu destino/dominio/dirección 13:37 <+postman> se entregará a tu proxy SMTP local 13:37 <+postman> incluso puedes activar todo con ETRN :) 13:37 <aum> hola de nuevo 13:37 <aum> me gustaría plantear un punto de discusión en esta reunión, si está bien 13:37 <+postman> eso es todo por el futuro, gente :) 13:37 <+postman> . 13:38 <@jrandom> suena de lujo, postman 13:38 * postman devuelve el micrófono 13:38 <@jrandom> aum: genial, debería haber tiempo en 4) 13:38 <+postman> sí, estoy extasiado :) 13:38 <@jrandom> postman: entonces, para el usuario normal, el proxy SMTP tendrá el maildir local, y el proxy POP3 leerá/etc., ¿cierto? 13:39 <+postman> sí, el proxy SMTP tiene un MDA 13:39 <+postman> y entregará el correo en maildirs locales 13:39 <+postman> incluso se pueden crear varias cuentas/usuarios localmente 13:39 <cervantes> postman: ¿los relés llevarán control de tus cuotas, etc., y propagarán esa info entre ellos? 13:39 <+postman> y se mapearán a cuentas de tu dominio 13:39 <+postman> cervantes: sí, lo harán 13:39 <septu_ssh> perdón, ¿puedo preguntarle a postman sobre mecanismos de pago/anti-spam en el nuevo modelo? 13:40 <+postman> septu_ssh: ¿has leído alguno de los documentos en la página web? 13:40 <+postman> cervantes: no es en tiempo real perfecto 13:40 <+postman> cervantes: pero estoy bien con un intercambio de información de cuotas que tarde unos minutos 13:40 <septu_ssh> postman: en la cola de lectura :/ 13:40 <septu_ssh> pero si está documentado, está bien 13:40 <cervantes> postman: sí, me lo imaginaba 13:41 <+postman> septu_ssh: www.postman.i2p/inout.html 13:41 <+postman> septu_ssh: www.postman.i2p/mailv2.html 13:41 <+postman> cervantes: esto no es ningún drama realmente: la cuota es un límite razonable 13:41 <cervantes> postman: incluso que alguien pueda enviar a nrelays * destinatarios de cuota no es algo malo 13:41 * septu_ssh es bungle 13:41 <+postman> cervantes: sí 13:42 <+postman> el objetivo es solo impedir que alguien abuse realmente del servicio 13:42 <+postman> en las pruebas que hice, 3 relés han sido realmente rápidos 13:42 <@jrandom> postman: olvidé, ¿esto tendrá soporte para que el relé SMTP local hable directamente con el relé SMTP de otra persona, en lugar de rebotar a través de tus nodos? 13:42 <+postman> cervantes: en 10 segundos se han sincronizado :) 13:43 <@jrandom> (o quizá eso sea para más adelante) 13:43 <+postman> jrandom: los relés de correo de i2p serán operados por varias personas y son los destinos preferidos para enrutar correo 13:43 <cervantes> postman: podrías introducir un retraso exponencial en la cola de envío 13:43 <cervantes> si se convierte en un problema 13:43 <+postman> jrandom: así que enviar a otros destinos podría ser útil en ciertas circunstancias 13:44 <@jrandom> sí, aunque peligroso en otras 13:44 <cervantes> así, cuanto más correo envíes, mayor será el tiempo que el correo permanezca en cola... debería dar tiempo a los relés para alcanzarte 13:44 <+postman> jrandom: pero si el propietario de un nodo divulga su destino IMIO podría ser spameado sin control :) 13:44 <@jrandom> exacto 13:44 <@jrandom> por otro lado, lo mismo si los relés de correo i2p son hostiles 13:45 <+postman> jrandom: en efecto, es una construcción tipo WOT 13:45 <@jrandom> </tinFoil> 13:45 <+postman> jrandom: no puedo impedir que un operador de relé distribuya una cuota de 0 para tu dirección 13:45 <@jrandom> ok, genial. sí, no hay que preocuparse por eso por ahora 13:45 <+postman> :) 13:46 <+postman> ok 13:46 <+postman> . 13:46 <@jrandom> ok, genial, gracias por la actualización. cosas realmente emocionantes 13:46 <@jrandom> ok, pasando a 3) actualizaciones de i2p-bt 13:46 <@jrandom> duck: ping 13:46 <@duck> hi 13:47 <@duck> Ayer se publicó BitTorrent 4.0.0 13:47 <ant> <dm> suena alemán 13:47 <@duck> que más o menos estábamos esperando antes de empezar con 0.2 13:47 <@duck> escribí una lista de tareas / todo: http://pastebin.ca/raw/7037 13:47 <@duck> (perdón, mi www está caído ahora mismo) 13:48 <@jrandom> genial 13:48 <legion> ¿de qué calendario hablamos para 0.2? 13:48 <@duck> el objetivo era 4 semanas 13:49 <legion> genial 13:49 <@duck> como pueden ver, RawServer (la parte que se comunica con i2p) es la tarea más grande 13:50 <@duck> . 13:50 <@duck> una encuesta rápida: 13:50 <legion> sí, soy muy consciente de eso :) 13:50 <@duck> ¿quién planea crear un fork de i2p-bt? 13:50 <@jrandom> genial, ¿hay algo que la gente pueda hacer para ayudar? 13:50 <@jrandom> je 13:51 <ant> <dm> yo 13:51 * jrandom agarra una cuchara 13:51 <ant> <dm> estoy dispuesto a ayudar 13:51 <legion> yo 13:51 <ant> <dm> soy gay 13:51 <legion> estoy trabajando en un fork 13:52 <@duck> bien, entonces ya sé a quién no tomar en serio. 13:52 <@duck> en serio, me parece una tontería; unir recursos puede llevarles mucho más lejos 13:53 <@jrandom> o quizá si hay mejores formas de hacerlo, pueden convencer a duck de trabajar así? 13:53 <named> Voy a escribir un fork en QBasic, por favor tómame en serio. 13:53 <@duck> Intentaré hacer el proceso más abierto, para que otros puedan ver lo planeado, etc. 13:53 <ant> <dm> tu apertura no nos conmueve. ¡FORK! ¡FORK! ¡FORK! ¡FORK! 13:53 <@duck> si tienen otras sugerencias 13:54 <ant> * dm alza a legion sobre sus hombros. 13:54 <legion> hmm, puede ser cierto, aunque con lo que estoy haciendo dudo que quieran que contamine el proceso principal de desarrollo de i2p-bt ;) 13:54 <ant> <dm> ¡FORK! ¡FORK! ¡FORK! ¡FORK! 13:54 <@jrandom> legion: ¿qué estás haciendo que duck no querría apoyar? 13:55 <@duck> legion: felicidades, si googleas 'i2p bittorrent', entonces un anuncio de “Windows I2P Bittorrent Version 1.0” es el #1 13:55 <@jrandom> jesús 13:56 <bla> jrandom: ¿Sí? 13:56 <+postman> jrandom: sí, pronto van a destrozar esta red :) 13:56 <bla> ;) 13:56 <named> ¿1.0? Maldición, ¡yo uso 0.1.8! 13:56 <Ragnarok> oy 13:57 <legion> omfg, ¿en serio? No puedo creerlo... eso es una locura. 13:57 <@duck> en fin, no creo que haya mucho nuevo que decir sobre esto 13:57 <legion> mi versión 1.0 está basada en 0.1.8; si estás usando 0.1.8 estás bien. 13:58 <@jrandom> (y la versión 1.0 es un .exe que nadie ha revisado, tu experiencia puede variar) 13:58 <legion> Lo nombré y numeré mal, perdón, de nuevo por eso. 13:58 <ant> <dm> 1.0>> 0.1.8 13:58 <ant> <dm> cualquier día de la semana 13:59 <@duck> ligeramente relacionado: 13:59 <@jrandom> ok, ¿algo más sobre 3) i2p-bt, o pasamos a 4) ??? 13:59 <+postman> legion: ¿cuándo habrá código fuente descargable? 13:59 <frosk> “I2P-BT 0.1.8 funciona bastante bien y es estable hasta ahora. Personalmente no veo razón para actualizar a I2P-BT 1.0” (visto en el foro) 13:59 * jrandom suspira 13:59 <@duck> el mes pasado Bram Cohen dio una charla sobre BitTorrent en alguna universidad 14:00 <@duck> bastante interesante: http://netnews.nctu.edu.tw/~gslin/tmp/050216-ee380-100.wmv.torrent 14:00 <@duck> (lecciones aprendidas sobre grandes programas P2P, además de algunos detalles de BitTorrent explicados) 14:00 <@duck> . 14:01 <@jrandom> cierto 14:01 <@duck> postman: legion ha publicado algo de código fuente 14:01 <ant> <dm> ¿es él el inventor de BT? 14:01 <@duck> pero según smeghead no es el mismo que el .exe 14:01 <@jrandom> dm: sí 14:01 <legion> Hay un código fuente para desarrolladores que puedes descargar de http://legion.i2p/archives/Itorrent_1_x_Developer_Source.zip.bz2 14:02 <+postman> ok, le echaré un vistazo 14:02 <ant> <dm> ¿el exe es una compilación directa de ese código? 14:03 <legion> aunque realmente el código 1.0 es solo 0.1.8 con un patch de smeghead, compilado y bien empaquetado. 14:04 * cervantes camina hacia 4)??? y espera a que todos lo alcancen 14:04 <ant> <dm> la pregunta sigue sin respuesta 14:04 <ant> <dm> Legion, ¿ordenaste o no ordenaste un código rojo??? 14:04 <@jrandom> *tos* 14:04 <legion> Quizá deberíamos volver al tema, mi discusión del cliente BT se movió a #itorrent 14:05 <@jrandom> ok, 4) ??? 14:05 <@jrandom> ¿algo más que la gente quiera plantear? 14:05 <@jrandom> aum: ¿tenías algo? 14:06 <ant> <dm> ¿stasher ha vuelto? 14:06 <legion> estoy viendo un comportamiento raro con 0.5.0.2 en periodos de tráfico intenso... 14:06 <aum> sí 14:06 <aum> me gustaría plantear la cuestión de la creación/gestión automatizada de tunnels 14:07 <ant> <dm> continúa 14:07 <+detonate> hay una NullPointerException en lo de la bandeja del sistema en Windows, acabo de notarlo 14:07 <aum> es 1337 que la consola web ahora permita a humanos crear/eliminar/gestionar tunnels manualmente 14:07 <@jrandom> detonate: ¿podrías ponerlo en el Bugzilla? 14:07 <aum> pero también creo firmemente que siempre debería haber una forma fiable y cómoda para que los programas gestionen tunnels también 14:08 <@jrandom> aum: nadie discrepa. lo necesitamos, y lo tendremos. solo que aún no. 14:08 <ant> <dm> ¿no puedes hacer eso a través de SAM? 14:08 <aum> noté en mi reciente regreso a i2p que la librería pysam ya no funciona 14:08 <septu_ssh> tengo una pregunta rápida también después de aum 14:08 <aum> lo cual fue una decepción 14:08 <@jrandom> el protocolo SAM funciona, pysam no 14:08 <Ragnarok> ¿alguna vez funcionó? 14:09 <aum> correcto 14:09 <aum> pysam solía funcionar de maravilla 14:09 <legion> Durante esos periodos hay más de 1000 tunnels en los que participa mi nodo y varios segundos de lag y retraso. 14:09 <@jrandom> legion: sí, el número de tunnels se debe a builds antiguas 14:09 <cervantes> ah mi modestia 14:09 <cervantes> eemm pymodesty 14:09 <aum> actualmente estoy escribiendo un módulo 'i2ptunnel.py', que define clases que permiten una gestión fácil de tunnels 14:10 <legion> entonces, si no se conectara a builds más antiguas, ¿la red iría mucho más fluida? 14:10 <@jrandom> ok, no sé si esa es la solución correcta a largo plazo, pero si te sirve de puente ahora, bien 14:10 <@jrandom> legion: esos tunnels no son el problema 14:11 <aum> bueno, las interfaces de clase pueden permanecer aunque cambie el mecanismo subyacente 14:11 <@jrandom> ok 14:11 <legion> ¿no lo son? 14:12 <legion> Cuando hay pocos tunnels, hay muy poco lag y retraso... 14:12 <cervantes> legion: perdón, aum solo está planteando algunas preguntas, si puedes esperar un minuto 14:12 <legion> me parece raro. 14:13 <legion> ok 14:13 <@jrandom> solo me preocupa que necesitamos tener en cuenta lo que ha tenido éxito en el pasado: la configuración web funciona y se mantiene porque todos la usan. quizá sería mejor hacer que cualquier app en la que estés trabajando funcione con creación manual de tunnels primero, eso sería más eficiente? 14:13 <@jrandom> solo para que siempre haya algo usando i2ptunnel.py, para estresarlo 14:13 <aum> parece que estamos en un bloqueo mutuo 14:13 <+detonate> jrandom:claro 14:14 <ant> <dm> sigamos entonces 14:14 <aum> no quiero invertir tiempo en desarrollar mi app hasta tener una API de gestión de tunnel en la que pueda confiar 14:14 <septu_ssh> \o. - punto a plantear 14:14 <cervantes> realísticamente no puedo imaginar que la interfaz de tunnel se rehaga en los próximos meses... 14:14 <@jrandom> pero seguro ves que podemos añadir una trivialmente 14:14 <cervantes> así que una solución de compromiso es viable 14:15 <named_> ¿No podría la config web tener algún tipo de API que el programa de aum manipule? 14:15 <@jrandom> named_: sí 14:16 <@jrandom> es trivial añadir algo para permitir control seguro vía URLs, pero solo tiene sentido si hay algo que lo necesite 14:16 <@jrandom> de lo contrario solo se pudrirá 14:16 <aum> named_: eso estaría bien, y podría funcionar si hubiera una contraseña hardcodeada en la configuración que los programas cliente deban enviar por POST junto con los campos de control del tunnel 14:16 <cervantes> personalmente me gustaría ver todo el sistema de tunnel completamente renovado; si incluyes una interfaz de gestión de tunnel desde el inicio entonces no tendrás que preocuparte por el esfuerzo extra de mantener una interfaz separada 14:17 <@jrandom> sí, los proxies necesitan bastante trabajo, del que me he estado escondiendo tanto como he podido :) 14:17 <aum> SAM es bueno para algunas situaciones, malo para otras 14:17 <cervantes> pero eso es más adelante... 14:17 <fedo> ( 14:18 <@jrandom> aum: pero como solución temporal, ¿no podrías usar uno de los tres métodos disponibles? 14:18 <cervantes> es decir, si la propia interfaz web usa la API entonces no hay sobrecarga de mantenimiento 14:18 <@jrandom> correcto. la interfaz web usa el TunnelControllerGroup 14:19 <aum> el uso de SAM se complica cuando se quieren usar librerías existentes que dependen extensamente de sockets TCP estándar 14:19 <aum> la CLI de I2PTunnel no funciona para abrir tunnels de servidor, así que actualmente estoy escribiendo código para usar TunnelControllerGroup 14:19 <@jrandom> aum: las librerías existentes deben ser auditadas cuidadosamente. por ejemplo, la utilidad gzip en sí expone datos sensibles 14:19 <aum> programando mientras hablamos 14:21 <@jrandom> estoy seguro de que la CLI funciona para tunnels de servidor, pero usar el TunnelControllerGroup es preferible, si lo necesitas así 14:21 <@jrandom> ok, ¿alguien más tiene algo que plantear? 14:22 <septu_ssh> Mi pregunta se refiere a una versión distribuida de hosts.txt; actualmente se usa una tabla DHT para routerInfo, ¿no podría extenderse a una versión distribuida de DNS? La DHT de DNS podría contener mapeos de www.bla.i2p al SHA del eepsite, y las entradas estarían firmadas por un 'registrador de I2P'... ¿comentarios? ¿réplicas? 14:22 <mancom> una pregunta sobre la hoja de ruta: ¿0.6 sigue programado para abril? 14:22 <@jrandom> septu_ssh: datos que no son de enrutamiento van en el netDb sobre mi cadáver ;) 14:23 <septu_ssh> jrandom: no la misma base de datos 14:23 <septu_ssh> una base de datos distribuida diferente 14:23 <aum> jrandom: ¿viste mi informe de bug? el comando 'server' de la CLI /no funciona/ 14:23 <maestro^> septu_ssh: no hay ningún registrador de i2p 14:23 <@jrandom> septu_ssh: hay muchos aspectos peligrosos del nombrado, con algunos compromisos clave. ¿has visto la discusión de nombres en ugha.i2p? 14:24 <@jrandom> septu_ssh: ah, una DHT sobre I2P ciertamente podría usarse para distribuir entradas, aunque esos nombres no serían seguros si se trataran como entradas globales 14:26 <@jrandom> aum: lo usé a diario hasta hace unas semanas, ¿viste mi respuesta? 14:26 <@jrandom> maestro^: ese es el plan 14:26 <@jrandom> eh, mancom: 14:26 <cervantes> aum: tengo una respuesta a ese correo de i2plist de jr, ¿no te ha llegado aún, o el problema sigue? 14:26 <septu_ssh> la única razón por la que sugiero un 'registrador' es porque de lo contrario pueden producirse colisiones 14:26 <@jrandom> septu_ssh: abraza las colisiones :) 14:26 <@jrandom> el nombrado globalmente único, legible por humanos, distribuido y seguro no existe 14:27 <septu_ssh> también puede pasar en host.txt si se edita manualmente, pero el problema sigue siendo el mismo 14:27 <@jrandom> descarta el primer parámetro, y estás hecho 14:27 <aum> jrandom: sí vi tu respuesta, y SÍ tengo streaming.jar en mi cp 14:27 <septu_ssh> postman gestiona un nodo central para correo, así que hay algún elemento de confianza en la red, ¿seguro que alguien no confiaría en un registrador para gestionar el espacio de nombres? 14:27 <@jrandom> ok, genial, ¿y aún te devuelve ese stacktrace, aum? 14:28 <aum> sí 14:28 <@jrandom> septu_ssh: postman solo actúa como elemento central para los outproxies e inproxies de postman 14:28 * Ragnarok realmente necesita ponerse a escribir esa documentación de la libreta de direcciones... 14:28 <aum> esto es cuando ejecuto la CLI manualmente, hago un genkeys, luego hago un 'server' usando el privkeyfile generado por genkeys 14:28 <@jrandom> septu_ssh: nadie confiará en nadie para gestionar un espacio de nombres. censura == ejercer presión sobre ese registrador. 14:28 <maestro^> cada quien es realmente su propio registrador 14:29 <maestro^> tú confías en tus amigos y ellos confían en ti 14:29 <aum> oh mierda, tomé un classpath antiguo 14:29 * aum prueba de nuevo 14:30 <ant> <dm> ok, seré el registrador. 14:31 <ant> <dm> seré lo menos sesgado que pueda... ¿va? 14:31 <septu_ssh> hmmm, ok, de vuelta a la proverbial mesa de dibujo entonces... 14:31 <@jrandom> septu_ssh: un buen lugar para revisar es http://zooko.com/distnames.html :) 14:32 <@jrandom> todos lo quieren, pero lo que quieren simplemente no es seguro. tenemos una solución que sí lo es, pero renunciamos a la unicidad global 14:33 <septu_ssh> hmmm, ok 14:33 <@jrandom> ok, ¿alguien más tiene algo que plantear para la reunión? 14:33 <cervantes> septu_ssh: http://forum.i2p.net/viewtopic.php?t=134 14:33 <aum> jrandom - ahora la CLI 'server' funciona, pero nunca obtuve un 'job number' para el tunnel 14:34 <@jrandom> hmm, cierto, se ejecuta para siempre 14:34 <aum> ah, tengo que hacer 'list' para obtener el número de job 14:36 <@jrandom> ok, genial, si no hay nada más... 14:36 * jrandom va preparando el cierre 14:36 * jrandom *baf* cierra la reunión