Card 1 / Framing
Qué es y qué no es el Modelo de Pila Soberana
El Modelo de Pila Soberana no es un modelo de redes genérico. Es un modelo con una postura definida sobre las capas en las que se toman las decisiones arquitectónicas relativas a la soberanía digital. Ese enfoque lo distingue de TCP/IP (que modela el internet en funcionamiento) y de OSI (que modela las capas de red con fines pedagógicos y de desarrollo de estándares).
El modelo condensa las capas inferiores — medios físicos, enlace de datos, enrutamiento a nivel IP — en una sola L1, porque esas capas están, en gran medida, mercantilizadas a efectos de soberanía. Elabora las capas superiores porque es allí donde realmente residen los compromisos de soberanía de quienes lo adoptan: identidad, datos comunitarios, gobernanza, federación, paradigma de aplicación.
Correspondencia explícita con OSI y TCP/IP. La L1 del SSM absorbe las capas L1–L3 de OSI y L1–L2 de TCP/IP — el sustrato físico, de enlace y de enrutamiento — porque esas capas están mercantilizadas a efectos de soberanía. La L2 del SSM (Transporte / Canal) es un análogo directo de la L4 de OSI / L3 de TCP/IP. La L3.1 del SSM (Red de Superposición) no tiene análogo en OSI ni en TCP/IP; se sitúa por encima del internet enrutado, en lugar de al mismo nivel, y es opcional — los sistemas que no usan redes de superposición simplemente la atraviesan. El resto de la pila superior del SSM — de L3.2 a L3.6 (las cinco subcapas restantes de Confianza Comunitaria) más L4 (Aplicación / Interfaz) — profundiza en lo que OSI llama la capa de aplicación (L7) y en lo que TCP/IP llama su propia capa de Aplicación, numerada por separado (también etiquetada L4 en ese modelo, distinta de la L4 del SSM): existen porque es ahí donde residen las decisiones de soberanía.
La compensación es intencional. El modelo tiene alta resolución donde quienes lo adoptan la necesitan (seis capas por encima del transporte, donde se toman la mayoría de las decisiones relevantes para la descentralización) a costa de una resolución menor en las capas sobre las que la mayoría de los adoptantes no toman decisiones (infraestructura física y de nivel IP).
Card 2 / Comparison
Cómo se relacionan los tres modelos
TCP/IP, OSI y la Pila Soberana son tres formas de dividir el mismo terreno arquitectónico para propósitos distintos.
TCP/IP se optimiza para el internet en funcionamiento — capas mínimas, enfocado en lo que quienes implementan realmente construyen. OSI se optimiza para la claridad pedagógica y de desarrollo de estándares — más capas, separación de preocupaciones más granular. La Pila Soberana se optimiza para la toma de decisiones sobre soberanía digital — capas completamente distintas por encima del sustrato de transporte, enfocadas en dónde residen realmente los compromisos de soberanía de quienes la adoptan.
Ninguno de los tres es "más correcto" que los demás. Responden a preguntas diferentes. Un ingeniero de redes que depura un problema recurre a TCP/IP. Un organismo de estándares que diseña un nuevo protocolo recurre a OSI. Quien adopta y trata de decidir en qué pila descentralizada apostar recurre a algo como la Pila Soberana.
Card 3 / Analogues
Dónde los análogos son claros y dónde no lo son
Los análogos horizontales directos son claros para la capa de transporte — el Transporte de TCP/IP, la L4 Transporte de OSI y la L2 Transporte / Canal del SSM coinciden en qué es el transporte. Por debajo del transporte, los tres modelos dividen el territorio de forma distinta, pero lo comparten.
Los análogos sesgados (diagonales) aparecen en dos lugares. La L3 Red de OSI y el Internet de TCP/IP quedan absorbidos en la L1 del SSM — la Pila Soberana condensa el sustrato de enrutamiento IP en una sola capa fundacional, en lugar de separar el enrutamiento físico, de enlace y de red. La L3.1 Red de Superposición del SSM es un concepto completamente distinto (redes de superposición construidas sobre el internet enrutado, no el internet enrutado en sí). De manera similar, la L6 Presentación de OSI queda absorbida en su mayor parte en la L3.2 Datos & Semántica del SSM, ya que la Pila Soberana trata el formato de los datos y su semántica como algo integrado, en lugar de dividirlos en capas separadas.
Para la tercera asimetría importante — que la L5 Sesión de OSI no tenga análogo en la Pila Soberana — véase la tarjeta dedicada más abajo.
Card 4 / OSI L5 Session
Por qué la Sesión de OSI no tiene análogo en la Pila Soberana
La capa de Sesión de OSI se encarga de establecer, mantener y recuperar interacciones de larga duración entre puntos finales — puntos de sincronización, control de diálogo y reanudación de sesión tras una interrupción. La Pila Soberana no extrae estas preocupaciones en una sola capa, porque en el panorama de los sistemas descentralizados la sesión se gestiona en capas distintas según la entidad:
QUIC gestiona la sesión de conexión en la L2 Transporte / Canal del SSM — migración de conexión, reanudación 0-RTT, control de flujo por flujo. Las sesiones de sincronización de Willow residen en la L3.2 Datos & Semántica del SSM — negociación de área de interés, rondas de conciliación, soporte de reanudación. La continuidad de mensajes en hilo de DIDComm reside en la L3.3 Identidad & Soberanía del Usuario del SSM — IDs de hilo, IDs de hilo padre, rotación de mensajes. El emparejamiento entre instancias de ActivityPub gestiona sus propios equivalentes de sesión en la L3.6 Federación del SSM — semántica de entrega servidor-a-servidor.
La elección de qué capa gestiona la sesión es, en sí misma, una decisión de arquitectura de soberanía. Extraer la sesión hacia una sola capa del SSM oscurecería esa elección — condensando compromisos arquitectónicos significativamente distintos en una uniformidad engañosa. La omisión de la Pila Soberana es deliberada: la sesión es real e importante, pero se entiende correctamente como una preocupación que atraviesa capas, y no como una capa propia.
Card 5 / Methodology
En qué se diferencia el SSM del mapeo genérico de capacidades
Existen dos formas de organizar una descripción de lo que hace un sistema complejo. Una es el mapeo de capacidades — identificar las capacidades discretas que ofrece un sistema y disponerlas como un grafo o una jerarquía, con relaciones entre ellas. La otra es el modelado por capas — comprometerse con un número reducido de capas ordenadas, cada una con un rol definido, y ubicar las capacidades dentro de ellas. El SSM es lo segundo.
El mapeo de capacidades tiene fortalezas reales. Capta la complejidad de forma fiel, da cabida a nuevas capacidades con facilidad y no impone compromisos donde aún no están justificados. El costo es que cada mapa es a medida — la comparación entre mapas es difícil, y la falta de una estructura general dificulta el uso de los mapas de capacidades para la toma de decisiones.
El SSM se compromete con una estructura por capas con un esquema definido: nueve posiciones de capa numeradas — L1, L2, la capa de Confianza Comunitaria de seis partes (L3.1–L3.6) y L4 — cada una con un rol específico, y las entidades ubicadas en su capa principal (a veces abarcando varias). El costo de este enfoque es que se pierde algo de información — en particular, las preocupaciones transversales y las capacidades que no encajan limpiamente en una sola capa. El beneficio es que la comparación se vuelve posible: se pueden examinar dos arquitecturas para ver qué colocan en L3.3, qué colocan en L3.6, qué dejan vacío.
Esa comparación es el propósito. El SSM está diseñado para quienes adoptan y tratan de elegir entre pilas descentralizadas, para colaboradores que tratan de entender dónde encaja su trabajo, y para investigadores que tratan de identificar vacíos en el panorama. Los tres se benefician de un vocabulario compartido por capas de formas que un mapa de capacidades a medida no puede ofrecer.
La elección metodológica es intencional y estructural. El SSM sacrifica fidelidad por legibilidad — eligiendo una estructura que permite la comparación por encima de una que capte cada matiz.
Card 6 / Cross-cutting concerns
Propiedades que no pertenecen a una sola capa
Algunas propiedades arquitectónicas atraviesan las capas en lugar de residir en una sola. El historial inmutable, el direccionamiento por contenido, los registros de auditoría enlazados mediante Merkle, el versionado y el estado reproducible son decisiones a nivel de protocolo que pueden implementarse en L3.2 (Datos & Semántica), L3.3 (Identidad & Soberanía del Usuario), L3.4 (Datos Comunitarios & Gobernanza), L3.5 (Coordinación entre Pares) o L3.6 (Federación), según el protocolo. Ninguna de estas propiedades tiene una única capa en la que siempre resida.
La capa en la que un protocolo implementa esa propiedad es, en sí misma, un compromiso arquitectónico relevante para la soberanía. El direccionamiento por contenido implementado en L3.2 produce estructuras de datos verificables en las que cualquier capa superior puede confiar. Implementado en L3.5, produce un sustrato de coordinación entre pares con detección de manipulación incorporada. Implementado en L3.6, produce una federación con responsabilidad criptográfica entre instancias. Se trata de mundos arquitectónicos significativamente distintos, aunque la técnica subyacente — aplicar hash al contenido para direccionarlo — sea la misma.
El SSM no extrae estas preocupaciones hacia una capa propia, porque hacerlo oscurecería precisamente las decisiones que más importan. Quien lea y encuentre el direccionamiento por contenido en una ubicación del SSM debería preguntarse: ¿en qué capa implementa este protocolo esa propiedad, y a qué compromete esa ubicación a la arquitectura? La misma pregunta se aplica al historial inmutable, los registros de auditoría y el versionado. La naturaleza transversal de estas propiedades es una característica del modelo, no un vacío.
Una nota sobre el lenguaje: cuando la descripción de una entidad menciona una de estas propiedades, se entiende que la propiedad se implementa en la capa principal de la entidad, salvo que se indique lo contrario. Las entidades que implementan propiedades transversales en múltiples capas — algo común en los entornos de ejecución integrados — reflejan esto en su propio perfil de entidad, y no en el modelo de capas en sí.
Card 7 / Origins
De dónde viene este modelo
El Modelo de Pila Soberana surgió del trabajo colaborativo entre tres comunidades de grupos de trabajo que se superponen, cada una aportando un enfoque complementario.
La Collaborative Technology Alliance (CTA) es una coalición de organizaciones e individuos que trabajan en tecnología prosocial, descentralizada y orientada a los comunes. OpenHaven es el grupo de trabajo de tecnologías entre pares de la CTA — el mismo proyecto bajo un nombre de trabajo — y es el sitio principal donde este modelo se mantiene y se refina a medida que surgen nuevas entidades y evoluciona la taxonomía. DWeb (el proyecto Decentralized Web del Internet Archive, que incluye el DWeb Camp y los DWeb Working Groups) ofrece un espacio de encuentro más amplio para quienes trabajan en tecnología descentralizada, y aporta el enfoque social y político de la "soberanía digital" que motiva las capas superiores del modelo.
El modelo se atribuye a este esfuerzo colaborativo, y no a ninguna organización individual. A medida que crece el catálogo de entidades y surgen nuevos patrones arquitectónicos en el ecosistema, se espera que el modelo evolucione a través del mismo proceso de grupos de trabajo — con revisiones presentadas para su revisión comunitaria, en lugar de impuestas unilateralmente.
Card 8 / Version history
Versiones y colaboradores
El Modelo de Pila Soberana es un artefacto de trabajo desarrollado mediante borradores iterativos y revisión comunitaria.
V1 (2025) fue producida por el grupo de trabajo World Wise Web, con la colaboración de Brad deGraf, Josh Field, Day Waterbury y Brandon Nørgaard.
V2 (2026) se presentó en el Internet Identity Workshop XLII (IIW 42), donde recibió comentarios que dieron forma a las revisiones posteriores.
V3 (2026) incorpora las revisiones del ciclo de revisión de V2 y los aportes continuos de las comunidades más amplias de la Collaborative Technology Alliance, OpenHaven y DWeb.
V4 (actual, 2026) reagrupa las seis capas intermedias bajo una capa de Confianza Comunitaria subdividida (3.1–3.6) y renumera Aplicación / Interfaz como L4, alineando el nivel superior del modelo en cuatro capas: Red, Transporte, Confianza Comunitaria y Aplicaciones.
Los comentarios son bienvenidos. Para sugerir revisiones, plantear un problema o contribuir a futuras versiones, comuníquese con Brandon Nørgaard en brandon@civicenlightenment.org.