Reunión de desarrollo de I2P - 18 de enero de 2005

13:04 <jrandom> 0) hola 13:04 <jrandom> 1) Estado de la red 13:04 <jrandom> 2) 0.5 13:04 <jrandom> 3) i2pmail.v2 13:04 <jrandom> 4) azneti2p_0.2 13:04 <jrandom> 5) ??? 13:04 <ant> <duck> (el sonido de la charla de criptografía pasando zumbando junto a mis oídos) 13:04 <jrandom> :) 13:04 * jrandom saluda 13:04 <cervantes> hola 13:04 <jrandom> ¡tú también puedes escuchar el sonido de la charla de criptografía pasando junto a tus oídos! nota de estado semanal publicada @ http://dev.i2p.net/pipermail/i2p/2005-January/000559.html 13:05 <bla> hola 13:05 <jrandom> vamos al lío, ya que de todos modos estamos interrumpiendo una discusión interesante... 1) estado de la red 13:05 <jrandom> realmente no tengo nada que añadir más allá de lo que hay en el correo; ¿alguien tiene algo que quiera plantear con respecto al estado de la red? 13:06 <bla> Aparte de que hemos visto, por primera vez, nodos en *todos* los continentes salvo la Antártida, no. 13:06 <jrandom> w00t! 13:07 <jrandom> vale, pasemos a 2) cosas de la 0.5 13:07 <mule> oye, mi padre está de camino a la Antártida, debería haberle dado un nodo 13:07 <ant> <duck> malditos antárticos 13:07 <Xan> ¿No hay antárticos? :( 13:07 <jrandom> jajá, bien 13:07 <jrandom> aunque no creo que haya mucho conjunto de anonimato allí 13:07 <Frooze> culpen a la Antártida 13:08 * cervantes monta una plataforma petrolera en la Antártida para poder financiar un nodo allí 13:09 <jrandom> ok ok, hay mucho material de la 0.5, así que podemos ir por partes 13:09 <jrandom> primero, gracias a quienes recopilaron un día de estadísticas: muchos datos interesantes @ http://dev.i2p.net/~jrandom/messageSizes/ 13:09 <postman> un placer :) 13:10 <cervantes> con respecto al estado de la red... he visto a bastantes personas con problemas para poner I2P en marcha últimamente (en los foros, etc.) - no sé si se debe simplemente al aumento de usuarios o quizá a más aplicaciones basadas en i2p con las que algo pueda fallar 13:10 <+protokol> jrandom: ¡MENTIROSO! ¡dijiste que los datos eran interesantes! 13:10 * jrandom le lanza barro a protokol 13:11 <ant> <duck> cervantes: también he visto informes de gente que lo pone en marcha en un par de minutos 13:11 <ant> <duck> Creo que NAT está causando la mayoría de los problemas 13:11 <cervantes> duck: cierto... 13:11 <ant> <dmdm> ¿quién es NAT? 13:11 <jrandom> cervantes: todavía hay algunos asuntos feos, sin duda. El tema de NAT y OS X ha sido un poco dolor de cabeza últimamente, pero la ayuda de Jhor con esto último debería mejorar lo último 13:12 <cervantes> sí 13:12 <cervantes> *ejem* entonces... 0.5 13:13 <Xan> dmdm: traducción de direcciones de red 13:13 <jrandom> jeje, vale. básicamente, la motivación de esas estadísticas de tamaños de mensaje es explorar los problemas de relleno (padding) 13:14 <jrandom> por desgracia, la estrategia que armé eligiendo números a dedo fue pésima, dando un 25% de sobrecarga solo con datos de relleno 13:14 <jrandom> si seguimos una de las propuestas para el cifrado de la 0.5 (tunnels-alt.html), no tendremos ese problema 13:15 <jrandom> (ya que obligará a tamaños pequeños fijos con fragmentación) 13:15 <mule> ¿Qué tipo de mensajes quieres rellenar, los que ve un router o los que ve un observador externo? 13:15 <jrandom> mule: pregunta importante 13:15 <jrandom> si solo nos preocupa el observador externo, podemos dejar los mensajes sin relleno, haciendo cualquier generación de chaff (ruido) en la capa de transporte 13:16 <Teal`c> http://microsoft.i2p/david_hasselhoff_05_christmas_album__silent_night.mp3 13:16 <jrandom> por otro lado, si nos preocupan participantes del tunnel haciendo análisis de flujo, debemos preocuparnos por el relleno a lo largo del tunnel 13:16 <@duck> con 5-6 saltos, ¿qué tan grande es el peligro de que un router haga análisis de tráfico? 13:16 <cervantes> Teal`c: reunión ahora mismo... ¿puedes usar #i2p-chat para anunciar el mp3? ;-) 13:17 <Teal`c> perdón 13:17 <cervantes> :) ¿por David Hasselhoff? 13:18 <jrandom> depende del nivel de análisis, duck. Si de algún modo han averiguado en qué tunnel están (p. ej., son la puerta de enlace del tunnel entrante y han recolectado la netDb, correlacionándolo con un destino), esos son datos nada triviales. Por otro lado, no es una exposición directa, pero sí da algo de información 13:18 <jrandom> más importante aún que el relleno en el tunnel es el relleno extremo a extremo, ocultando los datos de flujo de mensajes a las puertas de enlace y extremos. 13:19 <jrandom> si estuviéramos locos/tontos, podríamos llegar hasta un pipenet, usando tasa de bits constante en todas partes 13:19 <+polecat> ¡lo tengo! 13:19 <jrandom> (y terminar sin usuarios ejecutando i2p) 13:19 <+polecat> ¡Lo que necesitamos es hacer tunnel de i2p sobre email! 13:19 <cervantes> ¿Qué probabilidad hay de que routers confabulados acaben en el mismo tunnel en una red suficientemente grande? 13:19 <+polecat> ¡Ningún ISP sería tan tonto como para bloquear el email! 13:20 * jrandom espera la implementación net.i2p.router.transport.gmail 13:20 <postman> polecat: vaya, esto es absurdo 13:20 <postman> :) 13:20 <bla> cervantes: N^(-h) (N es el número de nodos rápidos, h = número de saltos). Parece 13:20 <+polecat> =3 lo sé. 13:21 <cervantes> ¿es mucho? :) 13:21 <jrandom> no el número de nodos rápidos, ya que la gente externa no conocerá tus perfiles 13:21 <+polecat> Pero en serio, abusando sin vergüenza de servicios IP existentes, podríamos hacer tunnel de i2p de muchas formas ingeniosas. 13:21 <jrandom> c^2/N^h para meter dos pares en el mismo tunnel 13:21 <jrandom> de acuerdo, polecat. esa es una de las razones por las que no tenemos tunnels bidireccionales 13:22 <jrandom> algunos transportes (p. ej., email) son malos para comunicación bidireccional 13:22 <bla> jrandom: c = ? 13:22 <jrandom> c == número de pares confabulados 13:23 <+polecat> Hmm, punto interesante. 13:23 <ant> <duck> en cuanto a la hoja de ruta, ¿cuál es el impacto de que i2p tome una dirección equivocada y elija una solución criptográfica incorrecta? 13:23 <+polecat> O protocolo de palomas mensajeras, nada bidireccional. 13:23 <+polecat> la cripto ya es modular, ¿no? 13:23 <jrandom> duck: es solo un punto de la 0.5 y una subsección del documento tunnels*.html. Hay mucho más en el enrutamiento de tunnel que solo cómo envolvemos los datos 13:24 <bla> jrandom: Entonces, de nuevo, este es el problema de meterlos en el tunnel ahora. Sin embargo, a lo largo de T renovaciones del tunnel (cada ciertos minutos), queda como P = 1 - (1 - c^2/N^h)^T 13:24 <jrandom> por otro lado, la diferencia entre «bloques fijos de 1 KB» y «bloques de 0-40 KB» tiene un impacto considerable 13:24 <+polecat> Odiaría ver que esta red siguiera el camino de Entropy, atascada en McEliece. 13:24 <jrandom> polecat: lee http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD 13:24 <bla> jrandom: Y por tanto tiende a cero para un tiempo suficientemente grande. Es decir: con suficiente tiempo, los atacantes estarán en el mismo tunnel al menos una vez 13:25 <jrandom> el plan es AES256/CBC estándar 13:25 <+protokol> he oído que DNS es bueno para hacer tunneling, la mayoría de la gente no lo bloquea 13:25 <jrandom> ciertamente, bla, aunque no es tan directo (para tunnels exploratorios lo es, pero no para tunnels de cliente) 13:26 <+polecat> Y si de algún modo hasta AES se rompe, algún cifrado simétrico equivalente. 13:27 <jrandom> bla: no creo que sea una preocupación práctica tan grande en la mayoría de los casos en ese grado, pero cuando lo montas como parte de un ataque de predecesor, el asunto queda en gran medida discutible 13:28 <jrandom> (por la forma en que hacemos el resto del enrutamiento de tunnel) 13:28 <bla> jrandom: ok 13:28 <jrandom> así es, polecat 13:29 <jrandom> duck: si vamos con la segunda opción, cambiar a otra más tarde probablemente será fácil. 13:29 <jrandom> por otro lado, la segunda opción requerirá un ajuste de rendimiento considerable para que No Apeste 13:29 <jrandom> pero estoy seguro de que podremos lograrlo 13:31 <jrandom> en fin, creo que lo anterior cubre dónde estamos ahora con respecto al trabajo de la 0.5 13:31 <jrandom> ¿alguien tiene más preguntas/comentarios/preocupaciones? 13:31 <bla> jrandom: Una 13:32 <bla> jrandom: creo que deberíamos valorar el anonimato un poco más que el rendimiento por ahora; así que sí, las opciones de PRNG (generador pseudoaleatorio) suenan bien 13:33 <jrandom> de acuerdo. El rendimiento se puede afinar más tarde; sin embargo, “añadir” mejor anonimato es mucho más difícil 13:33 <jrandom> (pero, por supuesto, el rendimiento es un parámetro de seguridad. Si Apesta, nadie lo usa) 13:33 <bla> Sí. 13:33 <bla> jrandom: 13:33 <bla> perdón 13:33 <@duck> bien, /me activa el bit mágico de rendimiento de Freenet 13:33 <cervantes> quizá disuada a todos esos leechers agitando torrents para que se mantengan alejados un tiempo más ;-) 13:34 <jrandom> jeh 13:34 <cervantes> <-- conexión reiniciada 13:34 <bla> cervantes: ¡no, yo no! :) 13:34 <cervantes> :) 13:35 <jrandom> creo que podemos conseguir optimizaciones muy buenas, y parece que gran parte de nuestro atasco no está relacionado con la selección de pares, sino simplemente (jeje) con bugs en la jobqueue 13:36 <jrandom> pero, en fin, ¿algo más para 2) 0.5? 13:36 <ant> <BS314159> ¿podrías publicar una explicación de este ataque de bucle? 13:37 <ant> <BS314159> suena más peligroso de lo que tu tratamiento implica que es 13:37 <jrandom> bucle: construye un tunnel que contenga A-->B-->C-->D-->C, envía 10 mensajes. 13:37 <jrandom> sin los PRNG, puedes añadir tantos mensajes a ese bucle C<-->D como quieras 13:38 <ant> <BS314159> ok 13:38 <jrandom> haciendo DoS de forma efectiva a cualquier router con solo unos pocos mensajes 13:38 <ant> <BS314159> pero solo A puede hacer esto 13:38 <jrandom> con los PRNG, se limita el número de mensajes que pueden entrar en el bucle 13:38 <ant> <BS314159> así que no hay peligro de que un atacante acorte mis tunnels introduciendo bucles 13:38 <jrandom> no, nadie puede acortar tus tunnels 13:39 <jrandom> lo único para lo que esto sirve es para un DoS 13:39 <jrandom> (un DoS muy barato) 13:39 <jrandom> (pero cuando puedes hacer DoS selectivo a pares sin mucho coste, puedes hacer cosas muuuy feas) 13:40 <ant> <BS314159> comprendo 13:40 <+protokol> ¿y los certificados de hashcash ayudarán en esto? 13:40 <jrandom> protokol: hashcash aborda el problema de que un par construya demasiados tunnels, y quizá demasiados saltos 13:41 <jrandom> protokol: no ayuda con los bucles. Las dos formas que encontré que sí ayudaban fueron los PRNG (tunnel-alt.html) o verificar en cada paso (tunnel.html) 13:42 <jrandom> verificar en cada paso tiene peligros, así que la inclinación actual es hacia los PRNG 13:42 <+Ragnarok> ¿qué tan efectiva será el método de PRNG? 13:42 <Xan> A-->B-->C-->D-->C - ¿no debería cada salto obtener un id diferente o algo así, para que los mensajes salgan del tunnel la segunda vez que alcanzan C en lugar de quedarse en bucle? 13:43 <jrandom> Xan: sí lo hacen, pero sin verificar cada paso, no puedes saber si está mal o no 13:44 <jrandom> Ragnarok: creo que será muy efectivo para minimizar el daño causado 13:45 <jrandom> al menos, por lo que puedo ver hasta ahora 13:45 <jrandom> si alguien ve problemas con ello, o sugerencias de mejora, por favor que se ponga en contacto :) 13:46 <Xan> o quizá me estoy perdiendo el punto 13:46 <Xan> vuelvo luego 13:46 <jrandom> 'k l8r, actualizaré el doc para que esté más claro 13:47 <jrandom> bien, a menos que haya algo más, ¿pasamos a 3) i2pmail.v2? 13:47 <jrandom> postman: ¿andas por aquí? 13:48 <postman> sí 13:49 <postman> :) 13:49 <jrandom> ¿algo que añadir de tu post en el foro? suena bastante bien 13:49 <postman> bueno, algunos quizá ya hayan leído el borrador de i2pmail.v2 13:50 <bla> ¿qué demonios está pasando? Desconexiones masivas. También tengo problemas para alcanzar sitios (por ejemplo orion, library) aquí también 13:50 <postman> apunta a una infraestructura de correo totalmente descentralizada en el futuro 13:50 <postman> pero necesita software proxy en los nodos así como un grupo de relays dedicados 13:51 <postman> todos están invitados a contribuir ideas / conceptos / desahogos 13:51 <postman> el desarrollo ya ha comenzado; no esperéis nada antes de finales de primavera :) 13:51 <jrandom> w00t 13:51 <kaji> hmm, la policía acaba de presentarse en mi puerta 13:52 <bla> kaji: ? 13:52 <jrandom> rápido, vuela tu disco duro 13:52 <postman> jrandom: bueno, esto es todo lo que tengo que decir por ahora :) 13:52 <cervantes> ¡escondan la mesa de blackjack! 13:52 <jrandom> genial, gracias postman 13:52 <kaji> dijeron que marqué el 911, pero estoy bastante seguro de que ni yo ni mi hermano lo hicimos 13:53 <+protokol> kaji: solo están revisando i2p 13:53 <jrandom> bien, a menos que haya algo más sobre 3) i2pmail, pasemos a 4) azneti2p_0.2 13:53 <+protokol> <música inquietante> 13:53 <jrandom> como se mencionó en el correo, ha habido avances importantes últimamente 13:53 <kaji> luego dijeron que los inalámbricos pueden volverse locos cuando quedan descolgados, pero todos mis inalámbricos están en su cargador -> #i2p-chat 13:55 <jrandom> la gente de Azureus ha sido muy receptiva preparando una actualización (¡bien!), pero también deberían estar atentos a problemas 13:55 <jrandom> (si no lees la lista de correo de i2p y usas azneti2p, lee la lista de correo de i2p) 13:55 <jrandom> ((o incluso si no usas azneti2p, lee la lista, que es donde anunciamos cosas importantes ;) 13:56 <jrandom> duck y orion también han estado haciendo muchas actualizaciones para acomodar el nuevo cliente de bt y el formato 13:56 <jrandom> (¡bien!) 13:56 * orion sonríe 13:57 <orion> todavía queda camino por recorrer, pero por ahora funciona. 13:57 <jrandom> (en la medida en que i2p lo permite ;) 13:58 <orion> jeje, sí. ;) 13:58 <jrandom> ¿alguien más tiene algo que plantear con respecto a azneti2p o i2p-bt? 13:58 <jrandom> (o bytemonsoon2p ;) 14:00 <jrandom> bien, si no, pasemos directamente a 5) ??? 14:00 <jrandom> micrófono abierto: ¿alguien más tiene algo que plantear? 14:00 <postman> jrandom: ¿por qué el addressbook publica entradas de userhosts? 14:01 <jrandom> postman: bug. 14:01 <postman> entonces no era un comportamiento planificado y se cambiará? 14:01 <cervantes> solo una cosa... 14:01 <jrandom> postman: correcto, y se cambiará 14:02 <jrandom> (¿verdad, Ragnarok? :) 14:02 <+Ragnarok> depende exactamente de lo que postman quiera decir... 14:03 <jrandom> Ragnarok: las nuevas entradas añadidas por el usuario local a sus hosts privados no deberían propagarse a los hosts publicados 14:03 <jrandom> (p. ej., userhosts.txt es privado; hosts.txt se sincroniza con otra gente y es público) 14:03 <cervantes> Como parte de una sección semirregular en el foro, habrá reconocimiento y premios para quienes hayan contribuido cosas buenas a I2P, ya sea recientemente o a lo largo de la vida del proyecto 14:03 <postman> Ragnarok: después de actualizar a 0.4.2.6 encontré entradas de mi userhosts.txt en el addressbook publicado en mi carpeta eepsite 14:03 <ant> <BS314159> hmm 14:04 <postman> Ragnarok: esas eran claves añadidas manualmente, que no se suponía que se publicaran 14:04 <cervantes> esta semana reconocemos a duck por su excelencia general como proveedor de servicios para la comunidad y como un gran idler en general: http://forum.i2p/viewtopic.php?t=275 14:04 <jrandom> w00t! 14:04 <jrandom> (vamos duck, vamos duck) 14:05 <Teal`c> ¿y qué hay del secuestro de nombres de dominio? 14:05 * brachtus aplaude 14:05 * orion hace el paseíto de pato como señal de respeto. 14:05 <cervantes> un punto importante para el futuro... ¡no tienes que ser un genio de la criptografía para recibir elogios! 14:06 <+Ragnarok> no, ese es el comportamiento esperado. Puedo cambiarlo, pero primero tendré que terminar de implementar el bloqueo de archivos para que puedas cambiar hosts.txt directamente 14:06 <orion> (pero ayuda) 14:06 <cervantes> quizá hayas contribuido una eepsite estupenda o algo así... 14:06 <cervantes> o haber sido de ayuda en el foro, etc. 14:07 <ant> <BS314159> hmm 14:07 <cervantes> (si no, seamos sinceros, jrandom ganaría cada semana) 14:07 <jrandom> oye, ustedes están pagando mi fondo cervecero, estas cosas no son gratis ;) 14:07 <ant> <BS314159> ¿no podrías simplemente crear un archivo nuevo, «publichosts.txt»? 14:07 <ant> <BS314159> y hacer que addressbook ignore userhosts.txt, pero permitir a los usuarios suscribirse a su propio publichosts.txt? 14:08 <jrandom> Teal`c: no hay forma de secuestrar un nombre de dominio, no se sobreescriben entradas, y userhosts siempre tiene prioridad sobre hosts 14:09 <jrandom> Ragnarok: quizá la interfaz web pueda abordar el tema del bloqueo, ya que los usuarios no estarán añadiendo a los archivos manualmente 14:09 <+Ragnarok> una vez hecho el bloqueo, ya no hay razón real para traer direcciones desde userhosts.txt (actualmente es la única manera de evitar una condición de carrera), así que no tiene mucho sentido añadir un tercer archivo 14:10 <+Ragnarok> jrandom: bueno, pensaba usar la API de bloqueo de archivos de Java 14:10 <jrandom> si crees que es necesario, tú mandas :) 14:10 <ant> <BS314159> esto te permitiría eliminar todos los nombres obtenidos de otras personas mientras mantienes los que tú mismo creaste 14:10 <ant> <BS314159> simplemente limpiando hosts.txt y cambiando tu suscripción 14:11 <ant> <BS314159> pero supongo que eso puede esperar a la firma de nombres 14:11 <orion> los metadatos resolverán este problema. ¿Hay ya un borrador de especificación? 14:11 <jrandom> usar solo dos archivos debería estar bien: uno gestionado por el addressbook y otro no 14:12 <jrandom> (incluso podrías hacer que addressbook ignore por completo userhosts.txt; de todos modos, userhosts.txt tiene prioridad sobre hosts.txt) 14:12 <+Ragnarok> jrandom: ese sería el plan, una vez hecho el bloqueo (lo cual no debería ser mucho trabajo; solo que no me he puesto con ello :) 14:13 <+Ragnarok> y ahora mismo estoy aprendiendo suficiente XML Schema para escribir uno para los registros de nombres 14:13 <ant> <dr_kavra> ¿este es el canal de kenosis? otro canal me dijo que viniera aquí :D 14:13 <jrandom> jaja 14:13 <jrandom> no, lo siento, esto es i2p 14:14 <jrandom> (a menos que busques una capa de comunicaciones anónima) 14:14 <jrandom> genial, Ragnarok 14:14 <ant> <BS314159> sigo pensando que XML es demasiado verboso y poco legible para esto, comparado con YAML, pero yo no soy quien escribe el código 14:14 <jrandom> Ragnarok: la parte difícil será hacer la cripto con XML sin recurrir a CDATA feo 14:14 <orion> ¿alguien ha escrito ya un borrador funcional para la especificación de metadatos? 14:15 <jrandom> (personalmente creo que XML apesta, pero solo soy un aguafiestas) 14:15 <jrandom> orion: http://dev.i2p.net/pipermail/i2p/2004-February/000135.html tiene una configuración básica 14:15 <orion> (metadatos de nombre/clave) 14:15 <dox> ¿se ha anunciado en algún sitio el addressbook y sus funciones? No sabía que mi hosts.txt se publica 14:15 <jrandom> (ver los elementos NameReference y LocalEntry) 14:16 <jrandom> dox: se escribe en la ubicación especificada en addressbook/config.txt 14:16 <jrandom> (por defecto, ./eepsite/docroot/hosts.txt) 14:17 <orion> le falta un indicador público/privado (es decir, distribuir/no distribuir). 14:17 <ant> <cervantes> lo único bueno de XML (y esto es un gran punto a favor) es que es un estándar ampliamente aceptado 14:17 <jrandom> cierto, orion; desde ese post han surgido muchas buenas ideas 14:17 <+Ragnarok> XML puede apestar, pero francamente es mejor que cualquiera de las alternativas para lo que estoy haciendo 14:17 <jrandom> cervantes: EDI también 14:17 <orion> ¿hay algún lugar para condensarlas? es decir, ¿una zona del foro? 14:18 <orion> ¿o quizá una página de wiki? 14:18 <jrandom> orion: el wiki de susi o de ugha 14:18 <orion> Voy a montar wikis para bytemonsoon y orion.i2p para ayudar a lograr consenso comunitario sobre los objetivos de desarrollo futuro de cada uno. 14:18 <BrockSamson> xml + cripto sin CDATA = MIME, ¿no? 14:19 <jrandom> genial, orion 14:19 <jrandom> BrockSamson: smime, con analizadores distintos ;) 14:19 <orion> (también uno para metadatos de nombre) 14:21 <jrandom> hay muchas formas de hacer los metadatos; lo importante es la flexibilidad y la “corrección” para que pueda crecer o cambiar con el tiempo 14:21 * jrandom está seguro de que Ragnarok y compañía sacarán cosas buenas :) 14:21 <orion> por eso creo que hace falta un borrador público. 14:22 <ant> <cervantes> consorcio i2p :P 14:22 <jrandom> bueno, la gente lleva diciendo «alguien debería poner sus ideas en el wiki» desde las últimas reuniones, pero las páginas del wiki no están creciendo mucho ;) lo cual está bien, vamos al ritmo que vamos 14:23 * orion promete tener tres wikis arriba en un día y enviar por correo a todos sus ubicaciones 14:23 <BrockSamson> llámame perezoso, pero compara un EDI de pedido de compra ANSI 850 con casi cualquier otro pedido de compra basado en XML, y prefiero decodificar, codificar y depurar la versión en XML. Incluso si es 5 veces el tamaño de EDI 14:23 <jrandom> w00t 14:23 <jrandom> jeje, BrockSamson 14:24 <BrockSamson> ¿La posición 10 es ST? ah, entonces la posición 310 debería ser name 14:24 <BrockSamson> duh 14:24 <jrandom> BrockSamson: no creo que los esquemas XML para POs sean mucho mejores ;) 14:24 <jrandom> (pero sí, esa cosa es un desastre total) 14:25 <BrockSamson> sí lo son a las 4:30 de la mañana 14:25 <BrockSamson> a menos que... 14:25 <jrandom> jeje 14:25 <BrockSamson> lo haya escrito un exprogramador de EDI 14:25 <BrockSamson> y el xml se ve así: <p1><po><q>1</q></po></p1> 14:26 <BrockSamson> apuesto a que, si sumas las horas que los proyectos de OpenSource pasan hablando de si 'XML' o no 'XML', podrías programar Linux 10 veces. 14:26 <BrockSamson> en todos los proyectos en los que he estado ha habido debates enormes sobre ello 14:27 <orion> los debates son buenos para un proyecto, dependiendo de quién debata. ;) 14:27 <jrandom> eh, hace lo que hace, pero no es una panacea. puede funcionar bien para lo del nombrado 14:28 <BrockSamson> pero muchas personas están en proyectos solo para debatir. 14:28 <jrandom> aquí no. yo estoy por la cerveza gratis 14:28 <ant> <cervantes> eso es debatible 14:28 <orion> los detalles de implementación estarán más claros cuando el borrador de la especificación sea más tangible. 14:28 <orion> de ahí la necesidad de un wiki/revisión por pares. 14:29 <BrockSamson> escuché que este proyecto regalaba Garlic gratis 14:29 <jrandom> mucho 14:30 <jrandom> bien, ¿alguien más tiene algo que plantear para la reunión? 14:30 <ant> * cervantes saca la vaca ceremonial con campana 14:30 <ant> <cervantes> call =cow 14:30 * jrandom se prepara 14:31 * jrandom *baf* la campana de vaca, cerrando la reunión