Reunión de desarrolladores de I2P - 30 de diciembre de 2003

<jrandom> 0) hola <jrandom> 1) estado del router <jrandom> 2) i2ptunnel <jrandom> 3) im <jrandom> 4) planes para 0.3 <jrandom> 5) sincronización de tiempo <jrandom> 6) ??? <jrandom> hello mihi, polo <polo> hello ! <mihi> hi jrandom <jrandom> 0) hola <jrandom> :) <rsk> hola <i2p> <duck> hola <jrandom> 1) estado del router <jrandom> 0.2.3.3 ha salido, y parece estar funcionando <jrandom> aún hay mucho por hacer, por supuesto <jrandom> pero esta debería ser la última versión 0.2 <jrandom> 0.3 va a añadir el perfilado de pares para permitir que los routers eviten routers malos <jrandom> (y 0.3.1 es una renovación de los transports) <jrandom> hola Ophite1 <Ophite1> Heya. <rsk> ¿entonces más overhead para 0.3? <jrandom> sí y no <jrandom> tendrá pruebas de pares, pero va a estar más enfocado <rsk> ¿veremos una aceleración con la selección de rutas? <jrandom> sí <jrandom> están esos calculadores de ‘liveliness’, y se añadirán nuevos calculadores de latencia y throughput <jrandom> además la gente podrá ajustar sus propias preferencias para pares concretos <jrandom> p. ej., si sabes que quieres preferir al peer X sobre el peer Y, podrás darles una bonificación de ponderación de algunos puntos aleatorios <mihi> ¿habrá un apagado limpio? *g* <jrandom> en realidad es una buena pregunta, mihi <jrandom> I2P está llegando al punto en que necesita una interfaz de administración. <jrandom> el trabajo (Job) más largo que está bloqueando su operación es el GenerateStatusConsoleJob <jrandom> que ahora puede tardar hasta 4-6 segundos <jrandom> (bloqueando todo lo demás) <jrandom> eso debe ir asíncrono y bajo demanda. <jrandom> pero no quiero escribir un listener web / etc. <jrandom> quizá al revés: un servlet que arranque el router y se comunique con él <mihi> no necesitas un servidor web completo. cuando veas GET, devuelve tus datos. <jrandom> correcto <jrandom> tienes razón, eso también debería ir en 0.3. <mihi> y cuando veas otra cosa (como SHUTDOWN), haz lo que quieras. por supuesto, solo desde localhost ;) <jrandom> vamos, hombre <mihi> entonces alguien puede hacer un buen programa de administración <jrandom> correcto <mihi> ¿tenías algunos triggers por archivos, no? ¿están documentados en algún lugar? >>> mihi [~mihi@ags9-d9ba536a.pool.mediaWays.net] requested PING 1072820995 from jrandom <jrandom> esos estaban en IDN, no en el router en sí <jrandom> pero podría ser una buena vía <jrandom> es un sistema trivialmente fácil <jrandom> buena idea, vayamos por ahí <jrandom> (y puedo reutilizar ese código :) <i2p> <duck> esta cosa mágica de archivos empieza a parecerse a plan9 <jrandom> lol <mihi> pero los triggers por archivo requieren polling <jrandom> correcto, mihi, leer un directorio cada 30s no es tan malo <mihi> pero un ServerSocket#accept es más barato. <mihi> ya que no consume tiempo. (siempre que haya un buen SO) <mihi> bien, los triggers por archivo son mejores que nada, seguro. <jrandom> un server socket permitiría administración remota <jrandom> (cuando sea apropiado) <jrandom> no sé. <jrandom> algo a resolver. <jrandom> (o si alguien quiere subirse y programarlo... :) <mihi> y un server socket podría entregar también la routerConsole. <jrandom> correcto <jrandom> ok, 2) i2ptunnel <jrandom> :) <jrandom> i2ptunnel sigue mandando, y parece que queremos añadir una API basada en sockets para controlarlo <i2p> <anon> ¿los planes ic2cp2pc de aum están cancelados por ahora? <jrandom> sí, ci2cp está muerto en el agua, reemplazado por la API basada en sockets para controlar I2PTunnel <jrandom> Creo que puedo incorporar esa API en los próximos días, para que él pueda ponerse con la implementación <mihi> solo usa un socket, haz in.readLine() y pasa esa línea a runCommand() ;) <rsk> ¿qué le aporta el api a i2p? <jrandom> más o menos lo que dice mihi (excepto que formatea los resultados y los envía de vuelta de una manera estándar) <mihi> con un "logger" apropiado para enviar los comandos de vuelta. <mihi> s/commands/results/ <jrandom> rsk> permite a los desarrolladores de aplicaciones construir sockets cliente y servidor sobre i2p sin lidiar con las necesidades de cifrado de I2CP <jrandom> sí sí <jrandom> i2ptunnel /sí/ tiene un overhead para situaciones donde hay muchos i2ptunnels <jrandom> independientemente de la JVM <jrandom> los clientes de i2ptunnel crean un destino nuevo por cliente contactado, y el router rendirá mucho peor a medida que crezca el número de destinos locales. <rsk> ah <jrandom> esto se debe a las necesidades de anonimato de la red ligadas a cómo funciona nuestro cifrado <jrandom> para aplicaciones que solo quieren abrir uno o dos tunnels a un peer, esta nueva api va a MANDAR <jrandom> pero para aplicaciones que necesitan hablar con muchos otros peers, I2CP es el camino. <jrandom> (ya que ese es un único destino, multiplexado por i2cp) <jrandom> Supongo que es el antiguo equilibrio TCP vs UDP, en cierto modo <jrandom> mihi> ¿tienes algún comentario, o algunas ideas para el futuro de i2ptunnel? <rsk> ¿cómo va el trabajo de IP sobre i2p, o lo del vpn? <mihi> jrandom: que alguien escriba una buena API de streaming, y luego que i2ptunnel la use. <mihi> lo mismo para el naming server. <mihi> quizá añadir algunos números de secuencia si nadie hace lo anterior. <mihi> lo cual significará un cambio incompatible. <jrandom> los cambios incompatibles no son malos, estamos en desarrollo temprano <jrandom> (si pudiéramos aumentar también el tamaño de los IDs a dos o cuatro bytes por lado?) <mihi> la API de streaming será un cambio incompatible de todas formas. y si i2p funcionara, no necesitaríamos números de secuencia. <jrandom> rsk> en pausa, ¿hasta que alguien tenga tiempo para llevarlo? ≡ rsk/#i2p piensa que los cambios incompatibles son los mejores <jrandom> correcto, mihi <mihi> el ID debería ser de 3 bytes ahora mismo, ¿por qué *aumentar* a 2 bytes? <jrandom> mihi> en realidad, me gustaría desaprobar lentamente mode=GUARANTEED y implementarlo en la API de streaming ≡ mihi/#i2p también <jrandom> dejando i2p = IP, no TCP ni UDP <jrandom> maldita sea, ojalá tuviera otras 14 horas en el día. <mihi> ¿solo 14? ;) <jrandom> ;) <jrandom> ¿no son los ids de 3 bytes derivados por ambos lados de la conexión? o quizá estoy confundido <mihi> cada lado tiene un ID de 3 bytes, sin embargo, solo hay que enviar uno a la vez. <jrandom> quizá implemente la API de streaming, quite GUARANTEED y añada ese controlador por socket después. <jrandom> ah ok <mihi> consulta /apps/i2p/i2ptunnel/java/src/protocol.txt <jrandom> sí sí <mihi> por cierto, ¿quién extravió ese archivo *ahí*? ≡ jrandom culpa a eco ;) <jrandom> espera, no, lo pusiste tú ahí <jrandom> ¿no? <jrandom> oh espera, no, los importé yo ≡ jrandom se culpa a sí mismo por ser estúpido. <jrandom> (la la la) <jrandom> maldición. ok, sí, trabajar en la API de streaming y el controlador por socket me permitirá reflexionar sobre el manifiesto de pruebas/perfilado/selección de pares <jrandom> lo publicaré en unos días para comentarios <jrandom> (y me sacará la cabeza del router. variedad++) <jrandom> mihi> ¿algo más sobre i2ptunnel? <mihi> que yo sepa no <jrandom> guay <jrandom> (gracias de nuevo por tomarte el tiempo de aportar en estas cosas, sé que estás ocupado con fiw y el resto) <jrandom> ok, thecrypto no está aquí, pero está progresando en la app de IM. <jrandom> (ese es el punto 3 de la agenda) <jrandom> 4) planes para 0.3 <jrandom> 0.3.0 ~= cosas de perfilado de pares, y ahora también incluirá la API de streaming y ese controlador por socket para i2ptunnel <jrandom> pero, si no lo habías adivinado, no se va a publicar el 1 de enero <jrandom> el 15 de enero es una posibilidad remota. ya veremos cómo van las cosas. <jrandom> 0.3.1 no es un mes completo de trabajo, así que puede que no necesite aplazarse. <jrandom> aparte de eso, la hoja de ruta sigue bastante en camino y representando hacia dónde nos movemos <jrandom> 5) sincronización de tiempo <jrandom> hay una nueva FAQ publicada en http://wiki.invisiblenet.net/iip-wiki?I2PTiming <jrandom> mihi, ¿tenías una sugerencia sobre la cuarta opción ahí (construir nuestro propio timing dentro de I2P)? <jrandom> hola brawl <mihi> sí. ∙φ∙ brawl is now known as eco_ <eco_> hola chicos <jrandom> oh hola, eco <mihi> deberías conectar 3 nodos aleatorios y recordar la diferencia entre el tiempo promedio y el tiempo local. <jrandom> acabamos de discutir la API de streaming / la api de tunnel <mihi> y luego hackear tu propio getTimeMillis que corrija eso. <Ophite1> mihi: No, no deberías. <jrandom> mihi> si un atacante crea 1000 nodos con la hora incorrecta, todos se fastidian <jrandom> (ya que el promedio se sesgaría aleatoriamente en medio) <mihi> si un atacante crea 1000 nodos, ¿no se fastidia todo el mundo de todos modos...? <rsk> ¿no sería eso auto-correctivo? <Ophite1> mihi: OK, 3. <jrandom> no, deberíamos poder manejar eso, mihi. <mihi> bien, entonces solo usa el promedio si la desviación estándar es menor que 1 seg o así. <rsk> si todos tienen la misma hora estás bien, incluso si esa hora es incorrecta, ¿no? <jrandom> rsk> si los 1000 nodos están sincronizados, pero ¿y si todos son aleatorios? <mihi> usa solo tiempos que estén lo suficientemente cerca. si no, toma 3 nodos nuevos. <jrandom> mihi> correcto, podríamos implementar NTP (que básicamente hace lo que dices, usando una serie de promedios candidatos para acercarse iterativamente a la hora correcta <mihi> pero no necesitamos preocuparnos de todo (como las latencias de ping), como hace ntp. <Ophite1> si no lo hiciéramos, mihi, el tiempo iría retrocediendo lentamente. ≡ mihi/#i2p piensa que eso es mejor que dejar que los usuarios configuren su hora individualmente. <jrandom> entonces cualquiera que elija al azar 3 de esos nodos sesgados es enviado a su propia red privada? <jrandom> ¿qué hay de esa tercera opción - <jrandom> i2p tiene un componente que consulta a un servidor NTP real vía NTP o SNTP <mihi> si solo tienes nodos sesgados en tu netDB, también estás en esa red privada... <jrandom> en lugar de reinventar la rueda <Ophite1> aunque esa me gusta en parte... <Ophite1> NTP no está firmado, es susceptible a un ataque MITM (man-in-the-middle). <Ophite1> o envenenamiento de caché DNS de, digamos, time.nist.gov <jrandom> correcto, Ophite1, aunque con más de 200.000 hosts SNTP o NTP, ese es un conjunto grande a atacar. <jrandom> definitivamente no sincronizaríamos con time.nist.gov. <Ophite1> conexiones desde i2p al servidor de tiempo de la NSA podrían levantar cejas, ¿no? :) <jrandom> y si un atacante va a por time.nist.gov, todo el mundo en todas partes se ve afectado <jrandom> je <mihi> entonces combinamos ambas. pregunta a un servidor ntp “real” y a tu vecino. si ambos dicen lo mismo, está bien. <jrandom> así que aún /más/ código ;) <jrandom> pero sí, es razonable. <Ophite1> Interesante. ¿Y si no coinciden? <Ophite1> ¿elegir otro servidor ntp? <jrandom> rechazar el peer. <mihi> probar con otro servidor ntp y otro peer. <mihi> hasta que tengas una coincidencia. luego rechaza todos los peers previos. ≡ mihi/#i2p teclea más lento que jrandom :( <Ophite1> ¿coincidencia dentro de un umbral determinado, digamos 1 seg? <jrandom> 1 s estaría bien. <jrandom> aceptar peers hasta unos 30 s o así (para lidiar con el lag) <Ophite1> ¿1 seg está bien en conexiones MUY CARGADAS? <jrandom> 1 s para sincronizar, 30 s para comunicación. <Ophite1> he visto la latencia en DSL llegar a 5 segundos cuando le haces cosas malvadas. <jrandom> ¿con tcp o udp? <Ophite1> pero entonces, en ese caso, ese host quizá no sea con el que quieres sincronizar el tiempo ;) <jrandom> correcto <Ophite1> udp. <jrandom> hmm 'k <Ophite1> pensarías que se descartaría :) <i2p> <duck> Creo que el problema es más informar al usuario de que hay un problema <jrandom> duck> eso es cierto. <i2p> <duck> solo después de caminar por logs enormes ven que su reloj está mal (si lo encuentran) <Ophite1> Puede. Más o menos. <i2p> <duck> o que el puerto ya está vinculado <jrandom> una interfaz de administración estaría bien. <i2p> <duck> el mundo es mejor con todo el mundo usando NTP conectado a su servidor local stantrum (sp) 2 CTCP Cloaking is now [On] <jrandom> quizá tengamos una versión 0.4 con un montón de limpiezas y cosas para usuarios finales, antes de ir a 1.0? <jrandom> correcto (stratum) <i2p> <duck> solo los clientes de windows probablemente no tengan eso <i2p> <duck> pero tampoco es probable que sean estables <jrandom> windows tiene NTP <i2p> <duck> así que a quién le importa <Ophite1> duck: Windows XP y Windows Server 2003 incluyen NTP. <jrandom> muchísimo más fácil que con unix también <Ophite1> sincronizado por defecto con time.windows.com si no recuerdo mal. <jrandom> con opciones desplegables para otros <Ophite1> Es una parte esencial de Windows Product Activation. <Ophite1> no puede expirar si no sabes la hora :) <jrandom> je <mihi> no hay opción en mi universidad... todos los relojes están de 1 a 5 horas mal. pero puede que no se me permita ejecutar i2p allí de todas formas... <Ophite1> mihi: i2p debería esforzarse especialmente por funcionar en una situación así... <jrandom> mihi> ¡genial! puedes ayudar a probar la operación oculta :) <jrandom> como nota al margen, voy a viajar este verano <jrandom> probablemente estaré desconectado, sin mi portátil. <i2p> <duck> idea al margen: ntp.duck.i2p :) <Ophite1> Míralo así: Brianna Kazaa se descarga un nuevo y genial cliente de compartición anónima que su mejor amiga le dijo que era muy guay y te permite chatear con gente en secreto y tal. ¿Queremos decirle que necesita ajustar su reloj en 30 segundos (¿cómo los va a conseguir?)? ¿O queremos que simplemente funcione? <jrandom> pero me aseguraré de poder seguir en I2P solo con terminales públicos. CTCP Cloaking is now [Off] <jrandom> sin duda, Ophite1. que simplemente funcione (con documentación para geeks) <jrandom> duck> bootstrap ;) <jrandom> y i2p /no/ requerirá root. <Ophite1> Ese es mi punto. <Ophite1> jrandom: ¿correrías un router en una máquina en la que no tienes root? <jrandom> así que sí, una mezcla entre la opción 3 y 4 <Ophite1> la opción 3.5 me suena bien ;) <jrandom> Ophite1> correría un centenar de ellos :) <mihi> opción 3.1415926... <jrandom> (y pasar al siguiente laboratorio, correr un centenar más) <Ophite1> Oh. Pie. Delicioso.;) <Ophite1> jrandom: dije en una en la que no tuvieras root. Amateur. :) <jrandom> lol <jrandom> así que básicamente por ahí vamos. <jrandom> hasta que se implemente lo del tiempo, todos deberían usar la opción 1 o 2. <jrandom> para la opción 2, si alguien pudiera escribir algo de documentación, lo agradecería <Ophite1> eso es aceptable por ahora ya que aún no estamos listos para Brianna Kazaa y cía ;) <mihi> para que conste: no probaré la "operación oculta". mi cuenta de la uni ya ha sido deshabilitada una vez y no quiero que la bloqueen otra vez... <Ophite1> mihi: Eres la mejor prueba que podríamos tener. <jrandom> Ophite1 > no para probar. <jrandom> 'k mihi, encontraremos una manera, y una vez que esté listo podrás usarlo. <Ophite1> OK, quizá no para probar. Algunas unis se ponen tan quisquillosas que te echan en lugar de solo bloquearte. <Ophite1> Conozco a alguien en la universidad más anti-compartición y pro-RIAA de EE. UU. Lleva un dumpsite de 2 gbit. <jrandom> lol bonito <Ophite1> Aprecio que muy, muy poca gente tenga tanto valor. <jrandom> ok, eso es todo sobre sincronización de tiempo. <jrandom> eco_> hola. ¿algo de bt de lo que quieras hablar? {¿o lo dejamos para la próxima semana?} <Ophite1> pero ten en cuenta que la mayoría de internet en el futuro probablemente se convertirá en universitario/corporativo. i2p podría prohibirse. i2p BIEN podría considerarse abuso por parte de grandes ISPs. i2p tendrá que funcionar de todos modos. <Ophite1> Tengo algunas ideas interesantes en esa línea que presentaré en una fecha futura. <jrandom> eso <Ophite1> (transport) <rsk> i2p es considerado abuso por los grandes ISPs, lee tu contrato <Ophite1> rsk: ¿ejecutar una caché proxy distribuida? <rsk> ejecutar cualquier 'servidor' <Ophite1> rsk: No, a menos que retransmita a SMTP o WWW. <jrandom> ejecutar servicios de cualquier tipo <jrandom> correcto <Ophite1> rsk: Jeje, tengo una solución para eso ;) <eco_> jrandom: puedo dar una breve actualización <jrandom> el piso es tuyo :) <eco_> estoy portando el cliente bittorrent basado en java snark (www.klomp.org/snark) para familiarizarme con i2p <eco_> el primer port corre encima de i2ptunnel, llamando directamente a las clases java <eco_> estado actual: funciona con 2 peers, las cosas se desordenan con > 2, los tunnels no se limpian, así que reiniciar es doloroso <eco_> eta: este fin de semana ≡ eco_/#i2p se da cuenta de que esto podría considerarse > 2003 <jrandom> w00t! ≡ jrandom hackea time.nist.gov <eco_> un port "real" probablemente recortaría el overhead de los tunnels, pero eso es un siguiente paso <jrandom> genial ≡ eco_/#i2p devuelve la palabra al mc jrandom <jrandom> 'k, creo que eso era todo <jrandom> 6) ??? <jrandom> ¿alguien tiene algo más? ≡ eco_/#i2p le gustaría expresar su agradecimiento por el trabajo bien hecho por jrandom cs hasta ahora <eco_> y que el sueño tiene alguna utilidad para home sapiens, aunque jrandom parece demostrar lo contrario <jrandom> ;) <jrandom> ¿qué opinan de reunirnos aquí en lugar de iip, hasta que i2p sea lo suficientemente confiable? <jrandom> personalmente, estoy cansado de que las reuniones se hagan pedazos cada semana. <i2p> <anon> ¡lilo apesta! <eco_> podríamos estar dejando fuera a gente si venimos aquí <jrandom> sí, lo sé. <jrandom> si pudiéramos tener un puente iip<-->aquí <i2p> <duck> IIP está dejando fuera a gente cada día <jrandom> eso estaría bien. <jrandom> correcto. <jrandom> iip es, por desgracia, inutilizable para una comunidad de desarrollo fiable. <i2p> <duck> http://banaan.zeelandnet.nl/open/changate.html <i2p> <duck> ese es el código en el que se basa eyeKon etc <jrandom> y aunque me gusta irme a programar por mi cuenta, ustedes aportan ideas realmente buenas y hacen cosas buenas que son esenciales ≡ rsk/#i2p está escribiendo un script de actualización para windows <i2p> <duck> teóricamente podría conectarse a 3 servidores y reflejar cada uno de ellos <jrandom> palabra, duck, quizá intente poner uno funcionando en i2p.dnsalias.net <jrandom> ping flood from hell ;) <eco_> irc en duck.i2p estuvo bastante bien hoy, superó a iip <jrandom> de acuerdo <jrandom> aunque me tiró unas cuantas veces. <jrandom> quizá la semana próxima sea más confiable <eco_> está en tus manos :-) <jrandom> la confiabilidad probablemente no mejorará hasta 0.3, que es en ~2 semanas <jrandom> (1 semana para hacer lo del tunnel/streaming, 1 semana para el perfilado/pruebas de pares) <jrandom> luego habrá los bugs que eso introduzca :) <jrandom> aunque debería decir que me emocionó transmitir audio desde aum anoche <jrandom> ¡y ardvark pudo transmitir durante 42 minutos sin buffering! <jrandom> así que quizá podamos ser lo suficientemente confiables <jrandom> (mi router local es solo phttp, lo que probablemente es una pequeña causa) <jrandom> ok, ¿alguien tiene algo más? <i2p> <duck> cant thing of anything ≡ eco_/#i2p tampoco puede ≡ jrandom concluye... ≡ jrandom *baf* da por cerrada la reunión