Arquitectura de OIM: visión general

Este documento explica cómo funciona el ecosistema OIM a alto nivel, detallando la filosofía de separación de capas y cómo los players web procesan la información de forma segura y eficiente.

1. El modelo de separación en 3 capas

Tanto OIM (Object Interactive Media, para imágenes) como OVM (Object Video Media, para vídeo) se basan en un paradigma fundamental de separación estricta entre los píxeles horneados, un separador simbólico y los datos interactivos que siguen vivos:

Capa −1 · Horneada

Los píxeles del PNG (o los fotogramas del vídeo en OVM). Contiene lo que el autor decide fijar en la imagen desde el editor («Fijar en la imagen»), de cualquier tipo de capa: fondos, fotografías, formas y también filtros y máscaras si el autor los hornea. Puede incluir tipografía horneada si el autor fijó texto en la imagen. Cualquier visor de imágenes la muestra. La firma la sella mediante un hash SHA-256 inmutable (image_hash).

Capa 0 · Separador

Solo simbólica: no almacena nada. Es la línea entre lo que se convirtió en píxeles y lo que sigue vivo.

Capa +1 · Dinámica

Los slots almacenados en el chunk zTXt OIM_Data: texto en todos los idiomas, botones, zonas, animaciones, estados y los filtros y máscaras que el autor dejó vivos. El player los compone sobre la imagen horneada. Esta capa se incrusta directamente en el propio contenedor, lo que permite:

• Que una única imagen contenga varias traducciones instantáneas.
• Que todo el contenido siga siendo totalmente accesible por lectores de pantalla y motores de búsqueda SEO (DOM real en Shadow DOM).
• Tematización dinámica fluida mediante unidades Container Query Width (cqw) y tokens semánticos de Dynamic Colors.

Los filtros y las máscaras no son una capa propia: cada uno está horneado (−1) o es dinámico (+1), y el autor decide por capa. Una opción del proyecto puede hornear todas las capas visibles para obtener una miniatura completa, a costa de que el texto aparezca dos veces (en los píxeles y dibujado por el player).

2. Players web (Web Components)

En el corazón de la visualización están nuestros players web, construidos como Custom Elements agnósticos al framework (<oim-player> y <ovm-player>).

Ciclo de vida del renderizado

1. Extracción: El player carga el archivo, lee la imagen horneada (Capa −1) y extrae los metadatos de la Capa +1 · Dinámica en milisegundos.
2. Validación: Verifica estrictamente que los metadatos cumplen con nuestros esquemas, evitando corrupción o inyecciones maliciosas.
3. Montaje: La imagen o el vídeo nativos se renderizan por debajo, mientras que el texto y los triggers interactivos se renderizan como HTML puro superpuesto.

Rendimiento

Para OVM (vídeo), la arquitectura deja que el navegador se ocupe del buffering nativo del vídeo, mientras que el player web solo gestiona la interpolación temporal de la Dynamic Layer, garantizando una experiencia fluida a 60 FPS sin sobrecargar el hilo principal.

3. Modelo de seguridad

La seguridad es crítica en los sistemas de medios interactivos. Hemos implementado varios mecanismos de protección para garantizar que los archivos OIM/OVM sean seguros de consumir en cualquier entorno:

1. Aislamiento con Shadow DOM: Los estilos y el marcado del player están encapsulados. Los CSS de tu sitio no romperán el player, y los estilos del player no se filtrarán al exterior.
2. Endurecimiento frente a XSS: Todo el contenido textual dinámico inyectado en la pantalla se escapa estrictamente como texto plano (textContent). El HTML crudo de la Dynamic Layer nunca se evalúa.
3. Validación con Zod: Cada payload de metadatos se valida contra un esquema estricto antes de su ejecución, rechazando propiedades no reconocidas, cadenas excesivamente largas o estructuras malformadas.