• Publicado: 2018-02-11
  • Autor: str4d
  • Publicado en roadmap

System Message: WARNING/2 (Blog, line 1)

Title overline too short.

===========================
Hoja de ruta de alto-nivel para 2018
===========================

Una de las muchas cosas que hemos discutido en el 34C3 fue sobre qué debemos centrarnos para el próximo año. En particular, queríamos una hoja de ruta que fuera clara acerca de lo que queremos asegurar que realizamos, frente a lo que sería realmente agradable tener, y poder ayudar a subirse al carro a los recién llegados a cada categoría. Esto es a lo que hemos logrado:

Prioritario: ¡Nueva criptografía!

System Message: WARNING/2 (Blog, line 18)

Title underline too short.

Prioritario: ¡Nueva criptografía!
-----------------------------

Muchas de las actuales primitivas y protocolos todavía conservan sus diseños originales desde alrededor de 2005, y necesitan mejoras. Hemos tenido varias propuestas abiertas con ideas durante años, pero el progreso posterior ha sido lento. Todos estamos de acuerdo en que estas necesidades sean nuestra principal prioridad para 2018. Los componentes centrales son:

  • Nuevos protocolos de transporte (para reemplazar NTCP y SSU). Vea la Prop111.
  • Nuevo protocolo de cifrado-onion para construir y usar túneles.
  • Nuevos tipos de datos de NetDB para habilitar Destinos I2P mejorados. Vea la Prop123.
  • Protocolo extremo-a-extremo actualizado (reemplazando ElGamal).

El trabajo sobre esta prioridad corresponde a varias áreas:

  • Escribir propuestas.
  • Escribir implementaciones funcionales de estas que se puedan probar.
  • Revisar las propuestas.

No podemos publicar nuevas especificaciones de protocolo por toda la red sin trabajar sobre todas estas áreas.

Deseable: Reutilización de código

System Message: WARNING/2 (Blog, line 44)

Title underline too short.

Deseable: Reutilización de código
------------------------

Uno de los beneficios de iniciar el trabajo descrito ahora, es que durante los últimos años ha habido esfuerzos independientes para crear protocolos simples y estructuras de protocolo que logren muchos de los objetivos que tenemos para nuestros propios protocolos, y hemos ganado tracción con una comunidad más amplia. Al potenciar este trabajo, obtenemos un efecto multiplicador.

  • Nos beneficiamos de diseños de protocolos, pruebas de seguridad, y código

System Message: WARNING/2 (Blog, line 53)

Bullet list ends without a blank line; unexpected unindent.

escrito por otros, reduciendo la cantidad de trabajo que necesitamos hacer para lograr el mismo nivel de perfeccionamiento de características y certidumbre de seguridad.

  • El trabajo que hacemos puede ser potenciado por otras comunidades,

System Message: WARNING/2 (Blog, line 58)

Bullet list ends without a blank line; unexpected unindent.

incrementando su interés en colaborar con nosotros, y reflexionando acerca de I2P en su conjunto.

Mis propuestas en particular van a potenciar el Noise Protocol Framework (marco del protocolo de ruido), y el `formato de paquete SPHINX`_. ¡Para estas tengo colaboraciones asignadas con varias personas externas a I2P!

Prioritario: Colaboración de clearnet

System Message: WARNING/2 (Blog, line 69)

Title underline too short.

Prioritario: Colaboración de clearnet
--------------------------------

Sobre ese tema, hemos estado atrayendo el interés durante los últimos seis meses o así. A lo largo de PETS2017, 34C3, y RWC2018, he tenido algunos buenos debates acerca de formas en las que podemos mejorar la colaboración con la comunidad en un sentido más ampliio. Esto es realmente importante para asegurar que podemos acumular tantas revisiones como sea posible para nuevos protocolos. El mayor obstáculo que he observado es de hecho que la mayoría de la colaboración de desarrollo de I2P actualmente ocurre en el interior del propio I2P, lo que incrementa significativamente el esfuerzo requerido para contribuir.

Las dos prioridades en este área son:

  • Establecer un proyecto-llevar un foro de desarrollo que sea accesible tanto desde dentro como desde fuera de I2P.
  • Establecer listas de correo para revisión y debate de propuestas (posiblemente conectadas con el foro anterior).

Otras metas clasificadas como deseables:

  • Establecer una senda usable git-a-mtn, para habilitarnos a solicitar de forma efectiva contribuciones sobre clearnet (red abierta) en GitHub mientras mantenemos el entorno de desarrollo canónico en Monotone.
  • Escribir un "documento de posición" que explique I2P con precisión a audiencias académicas y lo ponga en contexto con la literatura existente.

Espero que las colaboraciones con personas fuera de I2P sean realizadas por completo sobre GitHub, para minimizar fricciones.

Prioritario: Preparación para versiones de vida-larga

System Message: WARNING/2 (Blog, line 101)

Title underline too short.

Prioritario: Preparación para versiones de vida-larga
---------------------------------------------

I2P ahora está en Debian Sid (su repositorio inestable) que se estabilizará en alrededor de un año y medio, y también ha sido incorporado al repositorio de Ubuntu para su inclusión en el próxima versión LTS (de soporte a largo plazo) en Abril. Vamos a comenzar a tener versiones de I2P que terminen deambulando durante años, y tenemos que asegurarnos de que podemos manejar su presencia en la red.

El objetivo principal aquí es presentar tantos de los nuevos protocolos como nos sea factible en el próximo año, para alcanzar la siguiente versión de Debian estable. Para aquellos que requieran despliegues durante varios años, debemos incorporar los cambios de compatibilidad-hacia-delante tan pronto como podamos.

Prioritario: Pluginización de las actuales aplicaciones

System Message: WARNING/2 (Blog, line 117)

Title underline too short.

Prioritario: Pluginización de las actuales aplicaciones
---------------------------------------

El modelo de Debian anima a tener paquetes separados para componentes separados. Estamos de acuerdo en que desacoplar la aplicaciones Java actualmente incluidas del router I2P Java central, sería beneficioso por varias razones:

  • Codifica el límite entre las aplicaciones y el router I2P.
  • Debe hacer más fácil lograr que estas aplicaciones se ejecuten en routers I2P no-Java.
  • Habilitaría que terceros crearan "Paquetes de I2P" conteniendo sólo las aplicaciones que desean.

En combinación con las prioridades anteriores, esto mueve el proyecto I2P principal más en la dirección p.e. del kernel Linux. Pasaremos más tiempo centrándonos en la propia red, dejando que desarrolladores terceros se ocupen de aplicaciones que usen la red (algo significativamente más fácil de hacer tras nuestro trabajo de los últimos años sobre APIs y librerías).

Deseable: Mejoras de la aplicación

System Message: WARNING/2 (Blog, line 135)

Title underline too short.

Deseable: Mejoras de la aplicación
------------------------------

Hay un montón de mejoras a nivel de aplicación sobre las que queremos trabajar, pero actualmente nuestros desarrolladores no disponen de tiempo para abordarlas, dado el resto de nuestras prioridades. ¡Este es área para el que nos encantaría ver nuevos contribuidores! Una vez se complete el desacoplamiento descrito, será significativamente más fácil para alguien trabajar sobre una aplicación específica independientemente del router I2P Java.

Una de esas aplicaciones para las que nos encantaría recibir ayuda es I2P Android. La mantendremos actualizada con las versiones centrales de I2P, y corregiremos fallos según podamos, pero hay muchas cosas que se podrían hacer para mejorar el código subyacente así como la usabilidad.

Prioritario: Estabilización de Susimail e I2P-Bote

System Message: WARNING/2 (Blog, line 150)

Title underline too short.

Prioritario: Estabilización de Susimail e I2P-Bote
---------------------------------------------

Habiendo dicho esto, queremos trabajar específicamente sobre correcciones en Susimail e I2P-Bote a corto plazo (algunas de las cuales ya se han implantado en la 0.9.33). Estas han recibido menos cuidados durante los últimos años que otras aplicaciones de I2P, así que queremos pasar más tiempo poniendo sus bases de código a la par, ¡y haciendo que sean más fácilmente abordables para nuevos contribuidores!

Deseable: Asignar preferencia de tickets

System Message: WARNING/2 (Blog, line 160)

Title underline too short.

Deseable: Asignar preferencia de tickets
---------------------------

Tenemos un gran acopio de tickets (asuntos instados) de varios de los subsistemas y aplicaciones de I2P. Como parte del esfuerzo de estabilización descrito, nos encantaría deshacernos de algunos de nuestros asuntos de mayor antigüedad. Aún más importante, queremos asegurar que nuestros tickets estén correctamente organizados, de forma que los nuevos contribuidores puedan encontrar buenos tickets sobre los que trabajar.

Prioritario: Soporte del usuario

System Message: WARNING/2 (Blog, line 170)

Title underline too short.

Prioritario: Soporte del usuario
----------------------

Un aspecto de lo anterior sobre el que nos estaremos centrando es mantenernos en contacto con los usuarios que se toman su tiempo en informar de problemas. ¡Gracias! Cuanto más corto podamos hacer el ciclo de comunicación más rápido podremos resolver los problemas a los que se enfrentan los nuevos usuarios, y es más probable que continúen participando en la comunidad.

¡Nos encantaría que nos ayudase!

System Message: WARNING/2 (Blog, line 179)

Title underline too short.

¡Nos encantaría que nos ayudase!
--------------------

¡Todo esto parece muy ambiguo, y lo es! Pero muchos de los elementos descritos se solapan, y con una planificación cuidadosa podemos hacerles verdadera mella..

Si está interesado en ayudar con alguno de los objetivos anteriores, ¡venga y chatee con nosotros! Puede encontrarnos en OFTC y Freenode (#i2p-dev), y en Twitter (@GetI2P).

There are errors in this translation. Please comment on this ticket with the URL of this page.

System Message: ERROR/3 (Blog, line 61); backlink

Unknown target name: "formato de paquete sphinx".