Reunión de desarrolladores de I2P - 6 de enero de 2004

[22:02] <jrand0m> orden del día: [22:02] <jrand0m> 0) hola [22:02] <jrand0m> 1) http://i2p.dnsalias.net/pipermail/i2p/2004-January/000069.html [22:02] <jrand0m> 2) [discusión] [22:02] <wiht> ¿Puedo añadir el instalador al orden del día? [22:02] <jrand0m> 0) hola [22:02] <jrand0m> ¡oh sí, por supuesto! [22:02] <jrand0m> esta semana estamos probando algo nuevo [22:03] <wiht> Puedes ponerlo al final del orden del día. [22:03] <jrand0m> en lugar del viejo hablarhablarhablarresponderhablarhablarhablar, la publicación http://i2p.dnsalias.net/pipermail/i2p/2004-January/000069.html describe la mayoría de las cosas que pensaba decir [22:03] * mihi_ se ha unido a #i2p [22:04] <jrand0m> en su lugar, esta semana intentamos que la reunión sea más orientada a discusión: cosas de las que la gente quiera hablar a partir de esa publicación, cualquier seguimiento, y/o cualquier otra cosa que la gente quiera comentar [22:04] <jrand0m> como un instalador nuevo [22:05] <jrand0m> dicho esto, la gente debería empezar por revisar ese email/publicación y a partir de ahí seguimos :) [22:05] * mihi_away ahora se llama mihi [22:05] * kaji lee la publicación [22:05] * mihi_ ahora se llama mihi_backup [22:06] <jrand0m> ¡27 usuarios con solo un duplicado! w0w [22:07] * dm ahora se llama dup [22:07] <jrand0m> ok, cuando la gente haya leído eso, ¿quizá podamos empezar por repasar el índice y ver si hay algo que alguien quiera añadir / comentar / discutir? [22:07] <mihi> jrand0m: ¿cómo sabes que no hay más duplicados? [22:07] <jrand0m> je, gracias dm [22:07] <jrand0m> mihi> Instalé keyloggers (registradores de teclas) en las computadoras de todos (bwhahahaha) [22:07] <wiht> Me gustaría añadir el instalador como tema 10, y posiblemente el servicio de nombres (NS) como tema 11. [22:07] * mihi envió el seguimiento a la dirección equivocada :(, reenviando... [22:08] <jrand0m> bien visto, wiht [22:09] <MrEcho> el nuevo DNS de mrecho está en proceso [22:09] <jrand0m> genial, mihi, sí, me lo preguntaba ;) [22:09] <kaji> ¿cómo va el dns? - ah [22:09] <jrand0m> MrEcho> tu publicación, ¿verdad? [22:09] <MrEcho> trabajando en la publicación [22:10] <jrand0m> ok, mientras tanto, ¿alguien tiene algo sobre 1) streaming? ¿o saltamos a 2) I2PTunnel, TunnelManager, e i2pmgr? [22:10] <lucky> dios santo... podría pasarme el resto de mi vida intentando entender estas dependencias. [22:10] <wiht> Entonces pongamos DNS/NS como tema 11. [22:10] <jrand0m> suena bien, wiht [22:10] * duck entra [22:11] <jrand0m> buenas, duck [22:11] <mihi> sobre 1, hice commit de código para i2ptunnel usando la API de streaming [22:11] <jrand0m> ah, cierto, impresionante, mihi :) [22:11] <lucky> hola, duck [22:11] * twosandals ha salido de IRC (Leaving) [22:11] <kaji> jrand0m ¿varios servicios pueden usar la misma clave si están en puertos diferentes? [22:11] <jrand0m> no, kaji [22:11] <mihi> por cierto: ¿por qué tus archivos de Ant siempre borran el jar antes de reconstruirlo? [22:11] <jrand0m> mihi> paranoia [22:12] <mihi> yo diría que me roba tiempo de depuración ;) [22:12] <jrand0m> kaji> en i2p, una clave /es/ un puerto, esencialmente [22:12] <jrand0m> je [22:12] <kaji> ah [22:13] <jrand0m> mihi> si quieres actualizar eso, mientras construya el jar si cambian los archivos .class, está bien [22:13] <mihi> si el archivo es más nuevo que todos los archivos dentro, y podría saltárselo en caso contrario. [22:13] <jrand0m> correcto [22:13] <mihi> y por paranoia es mejor añadir una tarea <depends> [22:13] <jrand0m> de acuerdo [22:13] <FillaMent> yo yo [22:13] <jrand0m> hola, FillaMent [22:14] <jrand0m> ok, 2) i2ptunnel / tunnelmanager / i2pmgr [22:14] * TC se ha unido a #i2p [22:15] <human> hice un poco de hacking para que el TunnelManager devolviera los IDs de trabajo cuando se llaman los comandos "openclient" u "openserver" [22:16] <jrand0m> cojonudo :) [22:16] <human> de esta manera, las apps que usan el TunnelManager saben qué trabajo cerrar después, sin parsear la salida de "list" [22:16] <jrand0m> sí, no me sentía muy cómodo usando el list y close del tunnelmanager, ya que múltiples clientes pueden fastidiarse entre sí así [22:17] <jrand0m> meteremos ese parche justo después de la reunión. gracias, human :) [22:17] <human> implicó hacer que I2PTunnel.runCommand devolviera algunas cosas (actualmente un Property) [22:17] <human> s/Property/Properties/ [22:17] <jrand0m> ah, cierto, hay algunas cosas que modificar ahí antes de meterlo en el código [22:18] <human> pero mihi preferiría añadir algunos callbacks (devoluciones de llamada) asíncronos a la clase Logging, por lo que entiendo... [22:19] <jrand0m> correcto, para que las cosas puedan obtener información de las tareas inmediatamente, sin esperar a que terminen [22:20] * mihi ha salido de IRC (EOF From client) [22:20] <human> jrand0m: la idea es: que I2PTunnel.runCommand() devuelva inmediatamente, y eventualmente usar callbacks para obtener más info, ¿verdad? [22:21] <jrand0m> correcto [22:21] <jrand0m> así las tareas lanzan callbacks cuando haya datos que distribuir [22:21] * mihi se ha unido a #i2p [22:21] <human> bueno, IMHO hay otra pregunta: «¿cuántas apps Java (van a) usar I2PTunnel.runCommand() de forma asíncrona?» Todas las apps que actualmente usan I2PTunnel (incluso vía el TunnelManager) funcionan perfectamente con llamadas .runCommand() síncronas (aunque largas), y volver todo asíncrono solo lo complicaría (IMHO) [22:22] * mihi lo usa vía la GUI [22:22] <human> (bueno, "todas" significa el TunnelManager y apps que parsean la salida del TunnelManager) [22:22] <jrand0m> claro, la GUI se colgará mientras se ejecuta el comando [22:22] <mihi> y meter los siguientes 3 comandos de apertura de tunnel queda bloqueado mientras el primero está corriendo [22:23] <human> mihi: ok, no conocía tu app... entonces necesitamos alguna solución :-) [22:24] <human> mihi: el comportamiento asíncrono de .runCommand() requeriría revisar el TunnelManager [22:24] <mihi> human: ¿cuándo (en tu opinión) debería terminar runCommand? ¿cuando el tunnel está construido, cuando la conexión ha pasado? [22:25] <mihi> "destino inalcanzable" se sabrá después de que se haya hecho el primer intento de conexión. [22:25] <jrand0m> el patrón Command haría que execute() devolviera solo después de completarse. [22:26] <mihi> ¿qué significa *completado*? [22:26] <jrand0m> (así que si seguimos el patrón Command, runCommand bloquearía hasta que todo lo necesario para ese comando estuviera completo) [22:26] <human> mihi: jeje, esa es la pregunta :-) [22:26] <jrand0m> completo para "server 1234 privkeys" sería cuando el servidor puede aceptar conexiones en el puerto 1234 [22:26] <human> mihi: bueno, para TunnelServer IMHO debería devolver tras la creación del tunnel [22:27] <jrand0m> completo para "client 234 peer" sería cuando una conexión al puerto 234 llegue con éxito a peer [22:27] <jrand0m> al menos, esa es mi opinión [22:27] <mihi> ¿cómo puedes determinar lo segundo? [22:27] <jrand0m> realmente no tengo una postura firme [22:27] <jrand0m> ¿quizá un ping? [22:27] * Sciatica se ha unido a #i2p [22:28] <mihi> ¿y si el peer cae justo después del ping? [22:28] <mihi> en mi opinión es imposible hacer apps de red sin callbacks [22:28] <jrand0m> cierto [22:28] <mihi> o con muchos threads, y prefiero callbacks a threads sincronizados hasta la muerte [22:29] <jrand0m> ¿quizá solo debería devolver después de poder /intentar/ conectarse? [22:29] <jrand0m> o quizá el patrón Command no es el patrón deseado [22:29] <mihi> eso es lo que hace ahora. ¿y qué resultado debería devolver entonces? [22:30] <mihi> el punto es que quieres un resultado (distinto de un int para el id de conexión) [22:30] <jrand0m> correcto, para el comando client, uno quiere el trabajo (para poder cerrarlo luego), pero para el comando genkey, uno quiere la clave pública y la clave privada [22:30] * mihi no puede pensar en otra info que se sepa en ese punto. [22:30] <jrand0m> de acuerdo, yo tampoco. [22:31] <dup> ¡0! [22:31] <mihi> ¿y genkey debería esperar? vale, si tú lo crees. [22:31] <human> mihi: bueno, algo como un estado ("ok" o "error") y mensajes de error... [22:31] <mihi> human: los mensajes de error serán "demasiado tarde" IMO [22:31] <mihi> pero haced lo que queráis... [22:32] <mihi> siempre que luego lo hagáis funcionar con la API de streaming también... [22:32] <jrand0m> los puntos dolorosos que aborda human son las chapuzas en el TunnelManager que parsea los mensajes de logging. Pero estoy de acuerdo, mientras podamos exponer esa información vía la interfaz de logging, está bien [22:32] <dup> mihi es sabio. [22:32] <human> human: algunos pueden comunicarse inmediatamente (p. ej., cuando el puerto del tunnel aún está en uso) [22:32] <mihi> human está hablando consigo mismo ;) [22:32] <human> ¡ups! :-) [22:35] <human> quizá deberíamos ver qué tipo de aplicaciones se están construyendo sobre I2PTunnel [22:35] <human> la interfaz asíncrona es lo Correcto(TM), pero es más complicada de usar [22:35] <jrand0m> Creo que sería mejor si pudiéramos mantener la misma funcionalidad para el software actual, incluida la GUI. [22:35] <FillaMent> quizá me meto sin saber, pero quizá un método como se encuentra en muchos que tratan con HTTP: getHeader(String headerName) [22:35] <FillaMent> smake me as needed [22:35] <FillaMent> smack [22:36] * jrand0m le pega a FillaMent [22:36] <human> y el TunnelManager no lo necesita (ya que *nunca* podrá soportar adecuadamente eventos asíncronos, por su naturaleza) [22:36] * kaji tiene una idea totalmente fuera de tema [22:36] * FillaMent se resigna a la defensa =) [22:37] <human> pero si la aplicación de mihi necesita monitorizar el estado de los tunnels, entonces la interfaz asíncrona es Imprescindible(TM) [22:37] <jrand0m> human> java -jar lib/I2PTunnel.jar\n. Necesitamos soportar asíncrono. [22:37] <kaji> i2p como un applet de Java para poder ejecutarlo desde computadoras extrañas rápidamente al ir a un sitio web [22:37] * Sciatica ha salido de IRC (EOF From client) [22:37] <human> jrand0m: sí, entonces debemos rehacer el TunnelManager :-) [22:37] <jrand0m> kaji> i2p 3.0 :) [22:38] <jrand0m> de acuerdo, human, la implementación de tunnelmanager fue una implementación rápida y sucia [22:38] <jrand0m> ¿crees que podrías ver cómo habría que proceder? [22:38] * human puede ofrecerse a adaptar el TunnelManager a la interfaz asíncrona, cuando esté lista [22:38] <jrand0m> w00t :) [22:40] <jrand0m> ok, ¿listos para el punto 3) I2COCP del orden del día? [22:40] <human> si no, sería posible crear métodos síncronos y asíncronos para I2PTunnel [22:40] <jrand0m> cierto [22:40] <jrand0m> pero la duplicación podría ser excesiva cuando un poco de refactoring serviría [22:41] * baffled ha salido de IRC (Leaving) [22:41] <duck> preocupación personal sobre los tunnels: apps que no los cierran, así todo tu tunnelmanager se satura [22:41] <human> jrand0m: sí, deberíamos elegir la solución más fácil entre rehacer el TunnelManager o añadir nuevas APIs a I2PTunnel :-) [22:42] <jrand0m> buen punto, duck. actualmente no hay timeouts / expiraciones, y se asume que las apps que usan el TunnelManager se comportan bien (y que el TunnelManager no tiene bugs [¡ja!]) [22:43] <mihi> a propósito de nuevas APIs: ¿deberían las clases del API de streaming "reemplazar" las viejas o debería ser posible usar ambas (con comandos diferentes)? [22:43] <jrand0m> mihi> creo que las de streaming querrán reemplazar, ya que cuando la API de streaming sea sólida mode=GUARANTEED desaparecerá [22:43] <jrand0m> (y por tanto las viejas no funcionarán) [22:44] * MrEcho ha enviado el email [22:46] <jrand0m> ¿algo más sobre la discusión de tunnels? (obviamente esto no es el fin de las discusiones sobre tunnels ;) [22:47] * dup ahora se llama dm [22:47] <jrand0m> ok, I2COCP [22:47] <jrand0m> esto es algo que human sugirió el otro día y parece cubrir un hueco no cubierto actualmente. pero creo que deberíamos esperar a implementarlo hasta que haya algo que quiera usarlo :) [22:48] <wiht> Ese es un nombre algo largo, incluso abreviado. [22:48] * jrand0m ahora llama a I2COCP "Wilma" [22:48] <human> jrand0m: bueno, iba a escribir lo mismo :-) [22:48] <jrand0m> je, genial [22:49] <jrand0m> ok, saltamos a 4) hoja de ruta [22:49] <human> jrand0m: IMHO, en general, debería haber una forma para que apps no-Java tengan acceso más o menos completo a la red I2P [22:49] <jrand0m> de acuerdo [22:49] <jrand0m> la intención es que usen I2CP [22:50] <jrand0m> (como todas las apps Java, incluido i2ptunnel y la biblioteca de streaming, lo usan) [22:50] <human> jrand0m: sí [22:50] <MrEcho> I2PDNS "Janessa" [22:50] <jrand0m> pero tienes razón, también querrían streaming, así que o tunnelmanager->i2ptunnel o i2cocp->biblioteca de streaming [22:50] * jrand0m nunca ha conocido a una Janessa [22:51] * Sciatica se ha unido a #i2p [22:51] <jrand0m> ok, así que, sí, se ha actualizado la hoja de ruta. Sin cambios grandes, más allá de retrasar 0.3 y 0.3.1 dos semanas, añadir info de 2.0 y más criterios de 1.0 [22:51] <human> jrand0m: sí, deberían existir protocolos tipo "TCP" y "UDP" para I2P, con reporte completo de eventos de protocolo, accesibles desde apps no-Java [22:52] <MrEcho> human, suena bien [22:52] <jrand0m> Quiero que haya todas las interfaces posibles, pero no quiero sobrecomprometer con demasiadas interfaces a soportar [22:52] * human quería I2COCP (o como se llame) para su transporte I2P en twisted (ver http://www.twistedmatrix.com/), pero por ahora hará felizmente un apaño alrededor del TunnelManager :-) [22:53] * w0rmus ha salido de IRC (Lost terminal) [22:53] <jrand0m> palabra. eso sería lo mejor por ahora [22:54] <jrand0m> ok, ¿algún comentario sobre la hoja de ruta? [22:55] <jrand0m> [nada que ver aquí, la la] [22:55] <jrand0m> ok, 5) i2pIM [22:55] <jrand0m> thecrypto no está aquí, así que podemos esperar una publicación a i2p@ con novedades :) [22:55] <wiht> Ahora tenemos Jabber, si no me equivoco. ¿Aún necesitamos i2pIM? [22:55] <jrand0m> sí [22:55] <jrand0m> jabber tiene un servidor que recibe texto en claro. [22:56] <wiht> Oh. Muy bien, entonces; no lo sabía. [22:56] <jrand0m> eso son dos puntos en contra (un servidor, y texto en claro) [22:56] <jrand0m> aunque es una buena solución para algunas cosas, sin duda [22:56] <jrand0m> de hecho, algo en lo que pensé esta mañana fue que si pudiéramos fusionar i2pIM e i2psnark, sería Bueno. [22:57] <jrand0m> (pero una cosa a la vez) [22:57] <jrand0m> de hecho, hablando del diablo, 6) i2psnark :) [22:57] <human> jrand0m: a veces usé jabber con gnupg... [22:57] <jrand0m> ¿para chats de más de 2 personas? [22:58] <jrand0m> para uno a uno, estoy totalmente de acuerdo en que hay soluciones existentes [23:01] <jrand0m> ok, vamos a uno divertido, 7) presentando I.Toopie :) [23:01] <human> ¿cómo implementarías chats cifrados de más de 2 personas? ¿una clave privada compartida? [23:01] <jrand0m> sí, human [23:01] <jrand0m> o mediante ¡n! claves compartidas en el grupo [23:02] <human> bueno, quizá podría hacerse encima del protocolo jabber existente... [23:02] <mihi> human: una clave simétrica compartida enviada a todos los participantes [23:02] <jrand0m> la parte difícil es manejar las entradas y salidas: rotación de claves, etc. [23:03] * Sciatica ha salido de IRC (Ping timeout) [23:03] <jrand0m> no es en absoluto un asunto trivial. es realmente realmente realmente difícil. [23:03] * mihi asiente [23:03] * human está de acuerdo [23:04] <jrand0m> (por eso tener una app diseñada para ello, en lugar de intentar apañarlo encima de otro protocolo, puede merecer la pena) [23:04] <jrand0m> pero thecrypto puede describir mejor sus planes [23:04] <jrand0m> (aunque tengo entendido que aún está abierto a ideas sobre cómo tratar los grupos) [23:05] * Sciatica se ha unido a #i2p [23:06] <jrand0m> ok, seguimos :) [más discusión en i2p@, etc.] [23:06] <wiht> ¿Qué es I.Toopee, entonces? [23:06] <lucky> la mascota... [23:06] <jrand0m> I.Toopie es un tipo sosteniendo una máscara amarilla frente a su cara [23:06] * lucky se estremece. [23:07] <lucky> ajá. [23:07] <lucky> ¿puedo verlo? [23:07] <jrand0m> http://wiki.invisiblenet.net/iip-wiki?I2PLogo [23:07] * mihi_backup ha salido de IRC (EOF From client) [23:07] <lucky> he añadido Java a mi cola de compilación... [23:07] <lucky> pero.. lol [23:07] <lucky> ya tengo 7 cosas corriendo [23:07] <lucky> tardará un rato. [23:08] <lucky> aw, qué mono :P [23:08] <MrEcho> lol [23:08] <jrand0m> ha habido muchos logos geniales (¡no puedo creer que el concurso de logo lleve 3 meses!), y parece que tenemos un potencial fuerte con I.Toopie. por su sencillez, su concepción y su versatilidad. [23:08] <jrand0m> y, sí, es mono ;) [23:08] <mihi> ¿algunas imgs están rotas o mi navegador está bugueado? [23:08] <jrand0m> sí, algunas están rotas [23:09] <jrand0m> (las pusieron en sitios de alojamiento temporal hace 3 meses) [23:09] <MrEcho> el palo de I.Toopie ahora es todo amarillo ... [23:09] <MrEcho> lo cambié anoche [23:09] <jrand0m> ¿ah, sí? [23:09] <jrand0m> entonces la gente debería ACTUALIZAR LA WIKI [23:09] <jrand0m> ;) [23:09] <MrEcho> jeje [23:09] <MrEcho> ya no tengo la imagen .. perdón [23:10] <wiht> Veo las imágenes con Opera, pero no con Mozilla por alguna razón. [23:10] <jrand0m> ¿puedes ver http://img.villagephotos.com/p/2003-10/437060/badass.webp ? [23:10] <jrand0m> (esa es una de las imágenes de esa página) [23:11] <duck> Acceso denegado (Cuenta de usuario deshabilitada) [23:11] <jrand0m> sí, igual aquí. [23:11] <MrEcho> yo puedo verla [23:11] <jrand0m> pero sí, DrWoo ha hecho cosas cojonudas con I.Toopie [23:11] <MrEcho> moz 1.5 [23:11] * soros ha salido de IRC (EOF From client) [23:11] * mihi_away se ha unido a #i2p [23:11] * lucky ha salido de IRC (EOF From client) [23:12] <jrand0m> igual aquí, MrEcho. extraño. [23:12] <wiht> MrEcho: Estoy usando Mozilla 1.4. [23:12] <jrand0m> (igual que en que uso moz 1.5 y me sale acceso denegado) [23:13] * jrand0m espera con ganas un icono de bandeja con i.toopie :) [23:13] <jrand0m> ok, pasamos a 8) servidor de ajedrez [23:14] * Sciatica ha salido de IRC (Ping timeout) [23:14] * ion ha salido de IRC (Ping timeout) [23:14] <jrand0m> el último hosts.txt (http://i2p.dnsalias.net/i2p/hosts.txt) contiene la referencia para chess.fillament.i2p [23:14] <jrand0m> puedes usar cualquier cliente FICS o simplemente telnetear a eso y jugar :) [23:14] <jrand0m> (yay) [23:15] <kaji> ¿hay un buen cliente fics para windows? [23:15] <jrand0m> ni idea, terminé usando telnet [23:15] <wiht> ¿Funciona eboard? [23:15] <jrand0m> (que tuvo una curva de aprendizaje bastante dura para aprender los comandos) [23:15] * ion se ha unido a #i2p [23:16] <jrand0m> ni idea [23:16] * BpX se ha unido a #i2p [23:16] <wiht> Lo probaré luego. [23:16] <jrand0m> genial, si puedes publicar lo que encuentres, estaría bien [23:17] <jrand0m> ok, 9) DHT (tabla hash distribuida) [23:17] * wilde ha salido de IRC (Ping timeout) [23:17] <jrand0m> aún no tenemos un dht, pero quizá esto es una pista de algo que podríamos empezar a portar [23:18] <jrand0m> (usa UDP así que hacer que use I2CP no sería difícil) [23:18] <MrEcho> ¿dht??? [23:18] <MrEcho> me quedé en blanco con eso [23:18] <jrand0m> MrEcho> mira el [10] en el email ;) [23:18] <jrand0m> http://wiki.invisiblenet.net/iip-wiki?DHT [23:18] <Nightblade> entropy es una solución temporal suficientemente buena [23:18] <jrand0m> de acuerdo [23:19] <jrand0m> aunque creo que debemos mirar también una solución a largo plazo [23:19] * soros se ha unido a #i2p [23:19] * lucky se ha unido a #i2p [23:20] * human está preocupado por la compatibilidad gcj/kaffe con DHTs como Bamboo (http://bamboo-dht.org/) [23:20] <jrand0m> sí, bamboo es 1.4 [23:20] <MrEcho> afk [23:20] <jrand0m> para eso está la gloria de I2CP: el router y los tunnels pueden compilarse con gcj, mientras que las cosas que acceden a ellos pueden ser lo que sea [23:21] <jrand0m> es puramente para una app, eso sí, no como parte del núcleo [23:21] <jrand0m> solo intento pensar en cosas que ayuden a los usuarios finales que acaben descargando i2p a hacer algo útil desde el principio [23:22] <jrand0m> (poder publicar contenido muy resistente a la censura de forma anónima sería algo útil) [23:22] <jrand0m> s/uncensorable/very censorship resistant/ [23:23] <human> jrand0m: ah, ok - pensé que bamboo iba a reemplazar Kademlia para la NetworkDB :-) [23:23] <Nightblade> el proxy squid es algo que pueden hacer... para usuarios por ejemplo en china sería algo muy bueno [23:23] <jrand0m> Nightblade> cierto, pero squid no es escalable [23:24] <Nightblade> sí, creo que sería interesante tener una especie de JAP distribuido [23:24] <jrand0m> de acuerdo [23:24] <jrand0m> así que eso también es otra cosa que estaría genial si la gente pudiera investigar :) [23:24] <mihi> Nightblade: el problema es la gestión del abuso - no voy a abrir mi caja para cualquier http saliente [23:24] <jrand0m> estoy seguro de que algunos sí lo harán [23:25] <Nightblade> con una parte adicional en la que un nodo individual pueda elegir qué sitios quiere proxyear para la gente... un cliente podría enviar una petición de "whitehouse.com" y entonces uno de los nodos que hará el proxy y permitirá esa url puede responder [23:25] <Nightblade> sí, creo que tendría que tener algún tipo de control de acceso [23:25] <Nightblade> lista negra o lista blanca [23:25] <jrand0m> correcto [23:25] <Nightblade> de nombres de dominio [23:26] <jrand0m> es el sistema de "política de salida". aunque esto es todo un proyecto en sí [23:27] <MrEcho> podría apoyarse en el sistema DNS... supongo [23:27] <jrand0m> sin duda [23:27] <wiht> mihi: ¿Y si limitas el ancho de banda usado? ¿O son los sitios web accedidos los que podrían meterte en problemas? [23:27] <MrEcho> en una fecha muy posterior lol [23:27] <jrand0m> wiht> muchos proveedores prohíben explícitamente ejecutar servidores de cualquier tipo [23:28] <MrEcho> verizon jode con el puerto 21 seguro... [23:28] <wiht> jrand0m: Oh. Sí, eso es un problema. [23:28] <Nightblade> tendría que haber alguna forma para que los clientes soliciten los sitios que quieren que se les descarguen.. Las peticiones broadcast no son una buena solución, especialmente en i2p [23:29] <mihi> wiht: el problema son los sitios que se pueden acceder. compáralo con la demanda de JAP hace un tiempo. /me vive en el mismo país [23:29] <jrand0m> de acuerdo. aunque el broadcast no es posible sin fuerza bruta de un espacio de claves de ~2^2300 ;) [23:30] <jrand0m> cierto, mihi, la gente en regímenes represivos no podría ejecutar outproxies con seguridad [23:30] <wiht> mihi: ¿Cuál fue la demanda? No la recuerdo. [23:30] * dm ha salido de IRC (Ping timeout) [23:30] <Nightblade> es decir, aunque tuvieras una lista de destinos que proveen proxy web, no querrías tener que hacer broadcast a todos [23:30] <jrand0m> correcto, Nightblade [23:30] <Nightblade> me refiero al broadcast de peticiones [23:31] <mihi> el problema fue que alguien accedió a un sitio de pornografía infantil y pasó por un proxy JAP y no podían decir de dónde venía la petición. esto se interpretó como poner piedras en el trabajo de la policía [23:31] <jrand0m> la gente puede mirar crowds o rewebber para ver otros proyectos que trabajaron en esta misma tarea [23:31] <wiht> mihi: Ah. Gracias por la explicación. Ahora entiendo por qué te preocupa. [23:31] * mihi_away ha salido de IRC (Ping timeout) [23:31] <mihi> e hicieron ese cambio en el software de jap que lo hace posible para atrapar a la gente. que se eliminó más tarde [23:32] <wiht> Eh, entiendo por qué te preocupa. [23:32] <mihi> al final salió que JAP no tendría que revelar los datos, pero no quiero saber lo que costaron los abogados... [23:32] <Nightblade> sí, ¿pero no incautó la policía la información de todas formas? [23:32] <jrand0m> sí [23:33] <mihi> lo hicieron... [23:33] <jrand0m> pero en fin, sí, tanto un DHT escalable como un proxy web escalable serían Cosas Muy Buenas para tener para 1.0 [23:34] <mihi> y no pueden devolverla, ¿o sí? [23:34] * BpX ha salido de IRC (Ping timeout) [23:36] * Sciatica se ha unido a #i2p [23:36] <jrand0m> ok, ¿algo más para el punto 9? ¿o pasamos a 10/11) NS/DNS? [23:36] <wiht> Me gustaría hacer un breve comentario sobre el instalador después del tema 10. [23:37] <jrand0m> vale, quizá toquemos eso ahora, ya que NS/DNS podría no ser súper breve ;) [23:37] <wiht> Muy bien. El router tiene un script de inicio y un script de parada. [23:37] <jrand0m> correcto [23:37] <wiht> Me gustaría que todos los servicios funcionaran así: que tuvieran tanto script de inicio como de parada. [23:37] <jrand0m> la mayoría los tiene [23:37] <jrand0m> ¿no? [23:38] <jrand0m> oh, no scripts de parada [23:38] <wiht> No, solo el router. [23:38] <wiht> De ese modo, los servicios deseados podrían iniciarse al arrancar el ordenador, igual que el router. Envié una publicación a tal efecto a la lista de correo. [23:38] <jrand0m> aum está trabajando en i2pmgr, que va a ser tanto una consola como un centro de control GUI para los servicios y el propio router [23:38] <wiht> Digamos que quiero iniciar el eep y nntp al arrancar. Actualmente, no puedo hacerlo. [23:39] <jrand0m> correcto, necesitarías nohup startEepProxy.sh & [23:39] <wiht> Muy bien. Por cierto, ¿dónde están esos scripts en CVS? [23:39] <MrEcho> ok, he vuelto [23:39] * mihi_away se ha unido a #i2p [23:39] <jrand0m> wiht> los scripts están en el Install.java (aka hackeado) [23:39] <wiht> jrand0m: Gracias./ [23:40] <jrand0m> pero buen punto, queremos que sea lo más simple posible iniciar al arranque, así como iniciar bajo demanda [23:41] <jrand0m> ok, pasamos a 10/11) ns/dns [23:41] <MrEcho> bueno, miren mi email [23:41] <MrEcho> hay algunas cosas que olvidé poner [23:41] <jrand0m> por desgracia tu email no se llevó bien a la interfaz web :/ [23:41] <MrEcho> como nombres "temporales" [23:41] <MrEcho> ?? [23:42] * Sciatica ha salido de IRC (Ping timeout) [23:42] * ion ha salido de IRC (Ping timeout) [23:42] <jrand0m> MrEcho> http://i2p.dnsalias.net/pipermail/i2p/2004-January/000072.html [23:42] <MrEcho> por el gif o algo [23:42] <MrEcho> mierda .. lo firmé [23:43] <MrEcho> perdón [23:43] <jrand0m> la lista de correo está pensada para ser solo texto. las firmas pgp están bien (otros han enviado cosas firmadas) [23:43] <kaji> ¿cuál es un buen antivirus gratuito y pequeño? [23:43] * ion se ha unido a #i2p [23:43] <jrand0m> kaji> linux [23:43] * Sciatica se ha unido a #i2p [23:43] <wiht> LOL. [23:43] <kaji> que funcione con mi hardware [23:43] <wiht> kaji: Prueba AVG Antivirus para Windows. [23:44] * MrEcho_ se ha unido a #i2p [23:44] * MrEcho ha salido de IRC (EOF From client) [23:44] <MrEcho_> puto iip [23:44] <jrand0m> MrEcho / (y cualquiera interesado en el tema NS/DNS)> ¿has leído http://zooko.com/distnames.html ? [23:44] <MrEcho_> j, ¿debería reenviar el email? [23:44] <jrand0m> llegó bien a la lista, solo que no se archivó correctamente en la web [23:44] <MrEcho_> ya [23:45] <wiht> jrand0m: Aún no lo leí. [23:45] <MrEcho_> le echaré un vistazo más tarde [23:45] * mrflibble se ha unido a #i2p [23:45] <jrand0m> para los que no están en la lista, he guardado el email de MrEcho_ en http://i2p.dnsalias.net/~jrandom/mrecho_dns.txt [23:46] <MrEcho_> gracias, J [23:46] <kaji> es gay, quiere una dirección de email [23:46] <jrand0m> me preocupa la seguridad y escalabilidad del servicio de nombres. una vez que encontremos una solución que satisfaga esas necesidades, fantástico, pero hasta que lo hagamos, deberíamos ser cuidadosos con soluciones provisionales. [23:47] <jrand0m> kaji> las listas de correo suelen querer una dirección de email, sí ;) [23:47] <kaji> me refiero a AVG Antivirus [23:47] <jrand0m> oh ;) [23:48] <wiht> MrEcho tiene varias buenas ideas que no tenía en mi especificación, como una lista de veto para clientes malos. [23:49] <MrEcho_> no es realmente una lista de veto [23:49] <jrand0m> una vez haya 1000 clientes, ¿significa eso que llevaría 125 búsquedas encontrar un valor? [23:49] <MrEcho_> no [23:49] <wiht> No una lista, pero vetar clientes malos es algo que no tenía. [23:50] <MrEcho_> 2-4 clientes para comprobar [23:50] <jrand0m> ¿así que cada cliente tendrá 250 entradas? [23:50] * mihi_away ahora se llama mihi_backup [23:50] <MrEcho_> no [23:50] <wiht> Con lo que tengo, sería una búsqueda, posiblemente reenviada un par de veces para llegar a un servidor autoritativo. [23:50] <MrEcho_> los clientes solo tendrán lo que necesiten [23:51] <MrEcho_> seguirá consultando a otros Clientes hasta que obtengan datos que coincidan para la comprobación [23:51] <jrand0m> así que con 4 peers, haría una búsqueda aleatoria y de media llevaría 125 búsquedas [23:51] <jrand0m> (1000/4/2) [23:51] <jrand0m> ¿o los peers son un DHT? [23:52] <jrand0m> (¿con algún protocolo de mantenimiento?) [23:52] <jrand0m> ¿o un árbol de búsqueda? [23:52] <MrEcho_> en cierto modo, sí [23:52] <MrEcho_> tendré un corte en las búsquedas de clientes, simplemente consultará al MS [23:53] <jrand0m> el nombrado distribuido y seguro es un problema bastante estudiado: lo que haría que tu propuesta fuera más fácil de analizar en seguridad y escalabilidad sería si pudieras hacer comparaciones y validar variaciones frente a otros enfoques, quizá [23:54] <MrEcho_> si no encuentra / o no obtiene suficientes datos de Clientes dentro de un rango establecido entonces simplemente consultará al MS. [23:54] <jrand0m> tal como está, no hay suficiente detalle para que tenga confianza en la escalabilidad o seguridad de la arquitectura. no digo que no pueda salir bien, solo que aún no veo que lo vaya a hacer. [23:54] <MrEcho_> ¿puedes dejar de escribir un segundo? [23:54] * jrand0m deja de escribir. [23:55] <MrEcho_> va a funcionar .. tendrá escalabilidad, tendrá seguridad [23:56] <MrEcho_> cuantos más usuarios, mejor será [23:56] <jrand0m> ¿o sea "confía en mí", eh? [23:56] <MrEcho_> ¿confías en el sistema DNS de Internet? [23:56] <jrand0m> para algunas tareas. [23:57] <jrand0m> para muchas, no. [23:57] <jrand0m> (es bastante fácil para gobiernos / etc. cambiar registros: los casos judiciales ordenan a los registradores actualizar todo el tiempo) [23:58] <MrEcho_> la única otra manera de hacerlo es tener listas enormes de Nombres y mucho crypto en cada cliente [23:58] <MrEcho_> y siendo dinámico .. olvídalo [23:59] * mrflibble ha salido de IRC (EOF From client) [23:59] <jrand0m> sugiero revisar el artículo de zooko antes de seguir, y responder a su punto final 5 ("por qué estoy equivocado") Session Time: Wed Jan 07 00:00:00 2004 [00:01] <jrand0m> ok, eso probablemente es todo para el punto 10/11 (mucha discusión futura aún ahí, por supuesto) [00:02] <jrand0m> ¿alguien tiene otros pensamientos, etc.? [00:02] <wiht> Sí. [00:03] <jrand0m> ¿quieres compartir con la clase? :) [00:03] <wiht> Reescribiré la especificación que hice. Me gustaría usar un servidor SQL local para almacenar datos, no archivos. [00:03] <jrand0m> ah, guay [00:03] <jrand0m> (las mismas preocupaciones valen para la spec que escribiste también: si pudieras responder a la última pregunta de zooko, eso sería clave :) [00:03] * mrflibble se ha unido a #i2p [00:03] <wiht> Que MySQL o un servidor similar gestione el almacenamiento de datos, y que Java consulte a ese servidor. [00:04] <duck> ¿eh? ¿especificaciones de zooko? [00:04] <wiht> Creo que será más fácil de implementar. [00:04] <jrand0m> duck> no, solo estoy señalando a su artículo viejo "Names: Decentralized, Secure, Human-Meaningful: Choose Two" [00:04] <duck> ah, ese [00:04] <Nightblade> wiht: ¿qué especificación es esa (me perdí mucho de la reunión)? [00:04] * MrEcho se ha unido a #i2p [00:04] <jrand0m> (mucho más fácil que rehacer por qué los supernodos/servidores centralizados dan miedo en seguridad ;) [00:05] * MrEcho_ ha salido de IRC (EOF From client) [00:05] * mihi tendría algo para el log también ;) [00:05] <mihi> algo más largo ;) [00:05] <mihi> *** Resultados de I2Ping: [00:05] <mihi> + + + eco.i2p [00:05] <mihi> + - - jabber.duck.i2p [00:05] <mihi> - + + i2pcvs.i2p [00:05] <mihi> - + + duck.i2p [00:05] <mihi> - + - jap.eco.i2p [00:05] <jrand0m> Nightblade> se publicó en iip-dev allá por... ¿agosto? [00:05] <mihi> - + + irc.duck.i2p [00:05] <mihi> - + + human.i2p [00:06] <mihi> - - + nntp.duck.i2p [00:06] <mihi> - - - tc.i2p [00:06] <mihi> - - - dyad.i2p [00:06] <mihi> - - - bozo.i2p [00:06] <mihi> - - - ogg.aum.i2p [00:06] <mihi> - - - fcp.entropy.i2p [00:06] <mihi> - - - http.entropy.i2p [00:06] <Nightblade> jrandom: oh, antes de mi tiempo.. :) [00:06] <mihi> - - - www.mail.i2p [00:06] <mihi> - - - mp3.aum.i2p [00:06] <mihi> - - - smtp.mail.i2p [00:06] <wiht> Nightblade: Lo publiqué el 15 de septiembre. [00:06] <mihi> - - - pop.mail.i2p [00:06] <mihi> - - - mp3.tc.i2p [00:06] <mihi> - - - lp.i2p [00:06] <mihi> - - - kaji.i2p [00:06] <mihi> - - - nm.i2p [00:06] <mihi> - - - squid.i2p [00:06] <mihi> - - - chess.fillament.i2p [00:06] <mihi> - - - mesh.firerabbit.i2p [00:06] <mihi> - - - nightblade.i2p [00:06] <mihi> - - - aum.i2p [00:06] <MrEcho> caray, ¿alguien está en marcha? [00:06] <mihi> - - - fillament.i2p [00:06] <mihi> *** Terminado. [00:06] <mihi> ¿por qué hay tantos hosts caídos...? [00:06] * jrand0m no está ejecutando mis servidores ahora mismo [00:07] <FillaMent> Puedo conectarme a mí mismo tanto en eep como en chess [00:07] * mrflibble ha salido de IRC (Ping timeout) [00:07] <jrand0m> oh espera, i2pcvs está arriba, qué bien [00:07] <Nightblade> mihi: el mío no está arriba porque i2ptunnel se me cae tras unas horas [00:07] <mihi> así que mi router está roto (o son los problemas habituales de I2P...) [00:08] <jrand0m> ¿en serio, Nightblade? por favor reporta caídas de i2ptunnel (bugzilla estaría bien) [00:08] <Nightblade> está en el bugzilla [00:08] <lucky> hola [00:08] <Nightblade> espera.. [00:08] <FillaMent> Nightblade: ¿qué JVM? [00:08] <Nightblade> #39 [00:08] <wiht> Mi router lleva corriendo más de 12 horas, aunque tuvo un problema registrándose. [00:09] <Nightblade> java version "1.4.2-p5" [00:09] <Nightblade> en freebsd... podría ser un problema de la jvm, no lo sé. el soporte java no es muy bueno en freebsd [00:09] <jrand0m> tienes razón, Nightblade, mi culpa [00:09] <jrand0m> es el bug de i2cp bastante infrecuente [00:09] <jrand0m> ¿te pasa de forma consistente? [00:09] <Nightblade> el router es muy estable para mí, solo el tunnel server de i2ptunnel me da problemas [00:09] <Nightblade> sí, pasó varias veces [00:10] <Nightblade> aunque no lo he probado recientemente [00:10] * jrand0m acaba de tirar del eepsite de fillament [00:10] <jrand0m> (a la primera, acabo de notar que se completó la ventana) [00:10] <FillaMent> Sí,, acabo de jabber con duck, wiht está intentando entrar a chess [00:10] <jrand0m> ah, genial [00:10] <jrand0m> pero sí, aún hay problemas de fiabilidad que tratar en la red. [00:10] * FillaMent empuja a la gente con el guiño incluido, "Probablemente querrá jugar." [00:10] * human su eepsite sigue arriba - significa que 'killall java' realmente ayudó... :-) [00:10] <wiht> Acabo de conectarme con éxito al servidor de ajedrez. [00:10] <duck> ¿sí? [00:11] <jrand0m> lol, FillaMent [00:11] * mrflibble se ha unido a #i2p [00:12] <Nightblade> ¿es seguro correr la versión de cvs de i2p? [00:12] <jrand0m> /me obtiene con éxito el "1984-2004: twenty years of GNU!" de human :-) [00:12] <jrand0m> sí, Nightblade [00:12] <FillaMent> no pude obtener eco... [00:12] <Nightblade> ok, quizá pruebe eso [00:12] <duck> ¡con freenet deberías ejecutar siempre la última versión de cvs! [00:13] <duck> solo entonces no tiene bugs [00:13] <duck> s/freenet/i2p/ [00:13] * jrand0m ha tirado de eco.i2p [00:13] <FillaMent> acabo de obtener duck [00:13] <jrand0m> "Jan 4: First field test of I2PSnark. Pretty catastrophic: no transfer at all. Guess my single router test environment wasn't very representative :-) Back to the drawing board... " [00:13] <jrand0m> vaya [00:13] <duck> bueno, en realidad funcionó [00:13] <duck> ardvark pudo snarkear algo de mí [00:14] <jrand0m> bt precrea los archivos - ¿los archivos eran realmente válidos? [00:14] <duck> pero se dio cuenta al día siguiente [00:14] <duck> porque estaba oscurecido en los logs [00:14] <jrand0m> ¿qué, quieres decir que los logs que genera i2p son bastante demenciales? noooo [00:14] <duck> no [00:14] <duck> la salida de i2psnark [00:14] <jrand0m> ah [00:15] <duck> además, sospecho que snark hace demasiado trabajo innecesario [00:15] <duck> el cliente bittorrent normal parece más sencillo [00:15] <duck> también las altas demoras en i2p podrían causar bloques prematuros [00:16] * mrflibble ha salido de IRC (Ping timeout) [00:16] <duck> lo último es que tuvimos que reiniciar i2ptunnel unas cuantas veces :/ [00:16] <jrand0m> de acuerdo [00:16] <human> pregunta final sobre I2PTunnel / I2PTunnelManager (sí, ya sé, soy un pesado): ¿qué hay de mi parche para que "openclient" y "openserver" devuelvan un jobId significativo? [00:16] <jrand0m> así que, sí, mucho trabajo por hacer [00:16] <human> 1. aceptémoslo para que el TunnelManager funcione hasta que la nueva arquitectura asíncrona esté de lujo [00:17] <human> 2. tu patch apesta, vete a la mierda, y que le den al TunnelManager [00:17] <human> 3. ... [00:17] * MrEcho_ se ha unido a #i2p [00:17] * mihi vota por la 3 ;) [00:17] * MrEcho ha salido de IRC (EOF From client) [00:17] <jrand0m> 4. ¿veamos cómo podemos actualizar el tunnel manager para que sea asíncrono? no debería ser muy difícil [00:17] <jrand0m> el parche es bueno, pero mihi tiene un punto [00:18] <human> jrand0m: sí, de acuerdo [00:18] <jrand0m> aún nos quedan más de 1 semana hasta 0.3, así que tenemos tiempo hasta la próxima release completa [00:18] <human> jrand0m: pero mi duda es: ¿cuánto tardará en tenerse la interfaz asíncrona implementada en el TunnelManager? [00:18] <jrand0m> el propio tunnelmanager fueron 2 horas, podría añadir asíncrono esta noche [00:19] <jrand0m> (todo lo que hace falta es una actualización a BufferedLogging para aceptar llamadas .set) [00:19] <human> jrand0m: (con "tener" también quiero decir "tenerla implementada incluso en I2PTunnel) [00:19] <jrand0m> (o .nofity/etc) [00:19] <jrand0m> correcto [00:19] * mrflibble se ha unido a #i2p [00:20] <jrand0m> si prefieres, podría empezar con tu parche (que añade el id de trabajo) y fusionarlo con las actualizaciones para asíncrono [00:21] <human> jrand0m: podría añadir yo mismo la interfaz asíncrona al TunnelManager, pero la interfaz aún no existe :-) [00:22] <jrand0m> correcto, solo añade public void notifyEvent(String eventName, Object value); a Logging.java [00:22] <human> jrand0m: sugeriría "fusionemos el hack sucio para hacer que los job ids en la 0.3 funcionen algo, y luego trabajemos en la interfaz asíncrona" [00:23] <jrand0m> 0.3 aún queda [00:23] <mihi> 0.3 debería tener la API de streaming de todos modos, ¿no? [00:23] <human> jrand0m: hablo del peor de los casos [00:23] <wiht> jrand0m: ¿Quizá debería haber otra versión antes de la 3.0 para asentar estos temas? [00:23] <jrand0m> sí, mihi [00:23] <mihi> human: el peor caso es "cvs rollback && patch -p0 your.patch" [00:24] <jrand0m> ok, ¿qué tal esto? Implementaré y haré commit de lo asíncrono esta noche, si tú pudieras mirarlo mañana, human, y ver qué hace falta para meter tu actualización ahí [00:26] <FillaMent> jrand0m: ¿tienes trabajo? [00:27] <jrand0m> i2p [00:27] <duck> ¡saca 1.0! [00:27] <FillaMent> Me refiero a una fuente de ingresos [00:27] <jrand0m> :) [00:27] <FillaMent> por la que tengas que trabajar [00:27] <jrand0m> los ingresos están sobrevalorados. [00:27] * jrand0m despedí a mi jefe [00:27] <Nightblade> "programo por comida" - ese es mi lema [00:27] <Nightblade> lol [00:27] <human> mihi: bueno, pero a mí y a aum (que está trabajando en una app en python para el TunnelManager) nos gustaría tener jobIds ASAP... [00:28] <human> jrand0m: ok, trabajaré en tus cambios más tarde/mañana [00:28] <FillaMent> Trabajo/Dinero, sueño/higiene, comida, proyectos paralelos, vida social: Elige 3 cualesquiera [00:29] * jrand0m solo elige uno. [00:29] <jrand0m> vale, human [00:30] <FillaMent> ¿Alguien tiene otras ideas de servicios "solo hacer tunnel a" que estaría bien tener en la red? [00:30] * jrand0m aún quiere un Adventure por telnet :) [00:30] <jrand0m> o un BBS Waffle [00:30] * duck ahora se llama enduser [00:30] * jrand0m patea a enduser [00:31] <jrand0m> (maldita sea, sin ops) [00:31] <FillaMent> Para OS/2 había un driver de comunicaciones que podía mapear un puerto COM a un puerto TCP =) [00:31] <enduser> ¿qué diferencia veré como usuario final cuando I2PTunnel use la API de streaming? [00:31] * enduser ahora se llama duck [00:31] <jrand0m> ninguna [00:31] <human> lol [00:31] <FillaMent> FillaMent: un amigo mío llevó un BBS así durante un tiempo [00:31] <jrand0m> rendimiento, y quizá anonimato [00:31] * human querría un tunnel I2P a un rootshell [00:32] <human> ¿algún voluntario? :-) [00:32] <duck> rootshell en un UML [00:32] <jrand0m> rootshells en chroot estarían bien [00:32] <jrand0m> o con UML :) [00:32] <FillaMent> human: si tuviera un boxen de sobra, lo haría [00:32] <jrand0m> jeje, FillaMent [00:32] <duck> ¿conexión vnc a mi vmware win98? [00:32] <FillaMent> en serio, chicos... [00:32] <wiht> Un servidor de correo electrónico también sería bueno. ¿O ya lo tenemos? [00:32] <FillaMent> wiht: creo que TC tiene pop y SMTP [00:33] <jrand0m> ese es aum, pero están offline, ya que su caja está offline [00:33] * human podría ofrecer cuentas telnet en su sistema GNU/Hurd... [00:33] <jrand0m> ooOOoo [00:33] <FillaMent> bueno, no me entusiasma configurar acceso SMTP abierto aún [00:33] <jrand0m> comprensible [00:34] <FillaMent> quizá cuando la red sea más estable y tenga dinero para subir mi ancho de banda [00:34] <wiht> ¿Qué tal un servidor de claves PGP? [00:34] <mihi> FillaMent: podrías configurar un tunnel apuntando a un remailer en claro [00:34] <FillaMent> wiht: eso sí que es una gran idea =) [00:35] <FillaMent> mihi jeh... Podría simplemente apuntar el tunnel a mi caja SMTP del ISP =) [00:35] <mihi> FillaMent: esto te haría responsable del abuso... [00:35] <mihi> s/be// [00:35] <duck> http://www.mit.edu/people/marc/pks/pks.html [00:36] <duck> en serio, ¿debería duck enterprises considerar ejecutar un servidor de claves pgp? [00:37] <FillaMent> duck: yo estaba mirando eso también... ¿quieres encargarte? [00:37] <duck> hemos sido uno de los proveedores de servicio más estables según los logs de ping independientes de mihi [00:37] <jrand0m> jeje [00:37] <wiht> duck: Sí, por favor considéralo. [00:37] <jrand0m> por cierto, duck, ¿cómo haces eso? ¿reinicias periódicamente o simplemente corres en un SO y JVM fiables? [00:38] <FillaMent> pregunta: ¿la JVM cachea resoluciones DNS? [00:38] <duck> reiniciar es para actualizaciones del kernel [00:38] <jrand0m> sí, pero puedes hacer algunas marranadas para evitarlo, FillaMent [00:38] * wiht observa que la reunión lleva ya 2h40m. [00:38] <jrand0m> oh sí, [00:39] * mrflibble levanta la mano [00:39] <jrand0m> eh, el log de esta reunión va a ser enorme. y yo pensando que publicar cosas por adelantado iba a /acortar/ la reunión [00:39] <jrand0m> ¿qué pasa, mrflibble? [00:39] <FillaMent> jrand0m: ok... porque no tengo caídas pero mi IP cambia periódicamente... mi script de actualización de dyndns corre cada hora, así que máximo 60+~10min de mi dirección en named no apuntando a mi IP... [00:39] <FillaMent> ¿cómo afectaría eso la presencia de mi router en la red? [00:40] <mrflibble> mi caja podría estar disponible para alguna cosa tipo demonio [00:40] <jrand0m> genial, FillaMent, no debería ser mucho problema, mientras apuntes a tu dyndns [00:40] <wiht> mrflibble: ¿tipo demonio? [00:40] <mrflibble> supongo que depende de cuánto ancho de banda usaría la cosa [00:40] <mrflibble> daemony [00:40] <jrand0m> w3rd, mrflibble - ¿te ha estado funcionando fiable el router, o solo estás siendo un buen samaritano? :) [00:41] <mrflibble> no realmente, pero es porque mi ancho de banda local está saturado por el momento [00:41] <mrflibble> no lo estoy corriendo en mi colo aún [00:41] <mrflibble> quiero trastear con él localmente primero [00:41] <jrand0m> ah, genial. sí, i2p no está aún listo para despliegue amplio, es principalmente para pruebas [00:42] <FillaMent> Je.. Apuntaré un tunnel a mi servidor CUPS y tendréis impresión anónima =) [00:42] <jrand0m> rofl [00:42] <mrflibble> si hay algo que quieras que ejecute que use <40gb de ancho de banda al mes, avisa [00:42] <FillaMent> solo incluye una página de banner para saber a dónde mandar la copia impresa =) [00:42] <mrflibble> jeje [00:43] <jrand0m> wikked, mrflibble, seguro que te tomamos la palabra :) [00:43] <mihi> banner | lpr ? ;) [00:43] <FillaMent> mihi puedes configurar CUPS con una página de banner [00:43] <mrflibble> okidoki! [00:43] <mihi> banner probablemente creará muchas páginas ;) [00:43] <jrand0m> ok, antes de llegar a la discusión mixminion->impresora->oficina de correos, cerremos esta reunión ;) [00:44] * jrand0m prepara el *baf* [00:44] * jrand0m cierra la reunión con un *baf*.