Propuesta Técnica: Red Descentralizada de Espejos sobre IPFS para Distribuciones RPM

Identificador Técnico: [TECH-007]

Resumen Ejecutivo

Esta propuesta técnica (RFC) presenta el diseño, arquitectura y validación operativa de la primera red comunitaria de espejos de software libre sobre IPFS para los proyectos Fedora Linux y CentOS Stream en México y América Latina (mirrors.mx-os.mx).

El modelo traslada el paradigma de distribución de software desde granjas de servidores HTTP centralizados hacia un sistema direccionado por contenido (content-addressed storage). Esto elimina la duplicación de tráfico WAN en redes locales, reduce los costos de egreso para la infraestructura de los proyectos upstream y proporciona resiliencia ante contingencias de red.

Motivación y Problemática Actual

  1. Saturación en lanzamientos masivos: La publicación de versiones mayores (como Fedora 43 o actualizaciones masivas de paquetes) genera picos de demanda extrema que congestionan los espejos regionales tradicionales.

  2. Desperdicio de ancho de banda en redes locales: En oficinas, universidades, laboratorios de cómputo y hogares con múltiples equipos, cada máquina descarga de forma redundante exactamente los mismos paquetes RPM a través de enlaces residenciales o corporativos.

  3. Brecha de infraestructura en América Latina: La densidad de espejos de alta capacidad en la región es limitada, forzando a los usuarios a conectarse con servidores en Estados Unidos o Europa, lo que incrementa la latencia y degrada la experiencia con dnf.

Principios de la Arquitectura Propuesta

1. Direccionamiento por Contenido con UnixFS

Los árboles de paquetes y metadatos se procesan con Kubo generando grafos acíclicos dirigidos (DAGs) con bloques SHA-256. Debido a que cada archivo idéntico produce exactamente el mismo identificador de contenido (CID), los paquetes compartidos entre versiones o arquitecturas se almacenan y transfieren una sola vez en toda la red global.

2. Enclavillado Comunitario Granular

A diferencia de los espejos HTTP que exigen sincronizar cientos de gigabytes para ser útiles, la arquitectura de MxOS permite custodia fraccionada:

  • Un usuario con cuota limitada puede enclavillar únicamente las imágenes ISO (~3.5 GB) o el repositorio BaseOS (~15 GB).

  • Las universidades o empresas pueden alojar el catálogo completo (~300 GB) en sus servidores locales.

  • La red P2P (Bitswap) descubre automáticamente a todos los custodios de un bloque, agregando el ancho de banda de subida de toda la comunidad.

3. Doble Modalidad de Consumo

Para garantizar compatibilidad absoluta:

  • Modo Estándar (Sin cambios para el usuario): La pasarela perimetral https://mirrors.mx-os.mx actúa como proxy inverso transparente hacia Kubo; cualquier cliente DNF estándar consume paquetes por HTTPS convencional.

  • Modo P2P Nativo: Los usuarios con un demonio Kubo local configuran baseurl=http://127.0.0.1:8080/ipns/mirrors.mx-os.mx/...; la descarga se realiza entre pares, aprovechando la velocidad de la red de área local sin consumir tráfico WAN.

Modelo de Seguridad y Confianza Criptográfica

La arquitectura mantiene una postura de cero confianza (Zero-Trust):

  1. Inmutabilidad de datos: Los bloques de IPFS se autodocumentan criptográficamente mediante su hash; si un atacante altera un solo bit en un RPM, el hash cambia y Kubo lo rechaza antes de entregarlo.

  2. Validación GPG en DNF: El gestor de paquetes valida cada archivo RPM contra la llave pública oficial del proyecto (Fedora o CentOS) almacenada localmente en /etc/pki/rpm-gpg/. Ningún operador intermediario ni nodo guardián puede falsificar firmas.

  3. Identidad soberana Ed25519: Las publicaciones del catálogo se firman con la llave dedicada mxos-mirrors (k51qzi5uqu5di6ed3qtnwrdlvpmfil07ib6qfzb1t259nux49jenn8my4dtg0v), permitiendo la resolución y verificación sin requerir servicios comerciales de DNS.

Integración con Fedora MirrorManager

El servidor cabecera de MxOS (web0.mx-os.mx) cumple con los requerimientos técnicos de la infraestructura de Fedora:

  • Soporte de protocolos: Puntos finales HTTP (puerto 80) y HTTPS (puerto 443) con certificados TLS modernos y HTTP/2.

  • Rastreador de sincronización: Respuestas inmediatas a solicitudes HEAD sobre archivos de metadatos (repodata/repomd.xml).

  • Ubicación estratégica: Alojado en centro de datos en Querétaro, México (ASN 272373, HOBOPS.IO), proveyendo baja latencia y excelente conectividad nacional con operadores mexicanos.

Ruta de Evolución hacia Soporte Nativo en DNF

A mediano plazo, se propone explorar dos líneas de desarrollo upstream:

  1. Módulo de transporte para librepo: Diseñar un backend o conector para que librepo reconozca esquemas de URL ipfs:// o ipns://, comunicándose con la API RPC local de Kubo cuando esté disponible.

  2. Complemento DNF5 (dnf5-plugin-ipfs): Implementar un plugin de descubrimiento que reescriba dinámicamente las URLs de espejos hacia el gateway local cuando se detecte un demonio IPFS en ejecución en el equipo.