====================================================================================
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:** El gateway 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.