Servidores conectados y Jellyfin

Especificado. Esta página describe el comportamiento objetivo. El diseño está en dec-0131 (PROPOSED) y todavía no hay código. Lo que dice obliga a la implementación. Dónde cuelga en el roadmap está pendiente de decisión (dec-0131 §15, P1).

Tres cosas que no son lo mismoCopiar enlace

Si la otra persona no tiene servidor, no hace falta nada de esto: la invitas a tu servidor con una invitación y tendrá su cuenta en él.

Compartir con un amigo que tiene su StyxCopiar enlace

1. En tu servidor creas una concesión: qué bibliotecas o colecciones, qué puede hacer (ver, reproducir, descargar, importar), con qué límites (calidad, reproducciones simultáneas, ancho de banda) y hasta cuándo. La fecha de caducidad es obligatoria.
2. Styx te da un enlace o un QR de un solo uso. Se lo pasas a tu amigo.
3. Tu amigo lo abre en su propio Styx. Los dos servidores se reconocen por sus claves y, si queréis, comparáis un código corto en pantalla.
4. En el Styx de tu amigo aparece "Compartido contigo" con lo que le has concedido.

Lo que no pasa:

• Tu amigo no tiene cuenta en tu servidor y tú no sabes su nombre ni su email: tu servidor ve un identificador seudónimo, estable sólo dentro de esa concesión.
• Su progreso, lo que ha visto y sus listas se quedan en su servidor.
• No puede volver a compartir lo que le has dado con un tercero.
• Los servidores no comparten su bus interno. Sólo hablan por peticiones firmadas.

Puedes revocar una concesión en cualquier momento. Lo que se esté reproduciendo se corta en la siguiente petición y lo compartido desaparece del Styx de tu amigo (sus datos no).

Cómo llegan los bytesCopiar enlace

Por defecto, el reproductor de tu amigo sólo habla con su servidor. Su servidor lee de tu servidor con un permiso de corta duración por reproducción (una SCT, la misma que usa cualquier reproducción en Styx) y le sirve el vídeo como si fuera suyo. Así tu amigo no necesita configurar nada y tu servidor no ve su IP. Los vídeos nunca pasan por JavaScript ni por el bus.

Si tu amigo ya tiene la misma película, Styx lo detecta por el contenido del fichero (dec-0114) y por sus ids externos, y la tuya aparece como otra fuente de la suya, no como un duplicado.

Si tu servidor está detrás de CGNATCopiar enlace

Para conceder, tu servidor tiene que ser alcanzable desde el de tu amigo, igual que para verlo tú desde fuera de casa. Esto depende de tu borde (un VPS, el delivery-edge), no de esta función.

Enlazar dos instalaciones tuyasCopiar enlace

Si tienes dos Styx independientes (por ejemplo, uno en casa y otro en otro sitio) y no quieres unirlos como nodos, puedes conectarlos como cualquier par y además vincular tu cuenta en los dos, aprobándolo en ambos lados. Con el vínculo, tu progreso y lo que has visto se replican entre ellos. Siguen siendo dos cuentas, una en cada servidor.

Con el permiso importar, puedes además copiar una biblioteca de un servidor al otro. Los ficheros viajan por conduit (reanudable) y llevan sus metadatos dentro (metadatos en el fichero), así que entran en el catálogo sin re-escanear ni volver a buscar portadas.

Importar de JellyfinCopiar enlace

Jellyfin no es un servidor conectado: no puede conceder ni recibir concesiones. Styx habla con él por su API, con una API key que tú le das.

El importador se puede repetir sin duplicar y se puede interrumpir y reanudar. Al terminar te dice qué emparejó, qué dejó para revisar y qué no encontró.

Mientras sigas usando Jellyfin, Styx puede sincronizar el progreso en los dos sentidos: lo que veas en uno aparece en el otro. Styx sólo escribe en Jellyfin progreso y vistos, nunca metadatos ni borrados. Cuando termines de migrar, apagas la sincronización.

Para operadoresCopiar enlace

• Los servidores conectados están apagados por defecto (STYX_FEDERATION=enabled para activarlos).
• Cada servidor tiene una clave propia, distinta de la que firma las SCT, publicada en /.well-known/styx/server.
• Todo cambio de pares y concesiones queda en el audit, y los topes de cada concesión protegen tu ancho de banda y tu CPU aunque el otro servidor se porte mal.

Para desarrolladoresCopiar enlace

• Protocolo servidor a servidor fed/v1: HTTP firmado con RFC 9421 (Ed25519), con created, nonce y content-digest. Su spec y sus vectores vivirán en protocols/federation/.
• Una concesión se canjea por una SCT v1 normal con actor = fed:<peerId>:<handle>. El daemon no distingue un actor federado de uno local.
• El contenido remoto es un SourceBinding de kind remote-styx dentro del catálogo federado (r08), y su fuente de bytes es una SeekableMediaSource más (r04).