Por qué decidimos poner caducidad a nuestros enlaces de vídeo

Nuestros enlaces de vídeo caducan porque decidimos pronto que JustRec entrega vídeos, no los aloja. Un enlace existe para que tu cliente vea un recorrido esta semana, y una vez cumplida esa función, mantenerlo en línea solo añade riesgo y coste. Los enlaces con caducidad estaban en nuestro documento de producto antes de escribir una sola línea de código de servidor.

Ya explicamos el lado del usuario, y cómo trabajar con enlaces que caducan, en enlaces de vídeo que caducan: más seguros que una biblioteca fija. Este es el otro lado: por qué lo elegimos, qué nos costó y cómo funciona por dentro.

Entregar, no alojar

La mayoría de las herramientas de vídeo para el trabajo giran en torno a una biblioteca en la nube. Tus vídeos viven ahí, los enlaces apuntan a ella, y el producto crece añadiendo cosas a la biblioteca: carpetas, búsqueda, recuentos de visualizaciones, comentarios, inserciones.

Piensa en lo que las agencias y los freelancers envían a sus clientes: la segunda ronda de una home, un error en un checkout, dos minutos sobre un presupuesto. Esos vídeos tienen un destinatario y una fecha límite. El cliente lo ve, responde, y la siguiente versión sustituye a la anterior. Nadie vuelve en marzo a la segunda ronda de la home.

Así que planteamos JustRec como una herramienta de entrega. La grabación, la biblioteca y el historial viven en tu Mac. El servidor guarda una copia mientras dura la entrega y luego la suelta. Todas las demás decisiones se derivan de esa.

Tres razones para elegir enlaces que caducan

Los clientes de nuestros usuarios no se apuntaron a un archivo de vídeo

Una grabación de pantalla de trabajo para clientes a menudo muestra datos de clientes: un panel de administración, el nombre de un cliente final, un dashboard. El principio de «limitación del plazo de conservación» del RGPD establece que los datos personales no deben conservarse más tiempo del necesario. Un enlace permanente los mantiene en línea indefinidamente, en servidores que ni tú ni tu cliente habéis elegido. Un enlace que caduca convierte «no más tiempo del necesario» en el comportamiento predeterminado en lugar de una tarea pendiente. El artículo RGPD y vídeos de clientes explica quién es responsable de qué.

Costes que se mantienen estables

Con una biblioteca permanente, cada usuario cuesta cada mes más que el anterior, para siempre. Con enlaces que caducan, un usuario que comparte lo mismo cada mes cuesta lo mismo cada mes. Hicimos el cálculo completo en cuánto cuesta alojar vídeos de clientes en Cloudflare R2: un usuario intensivo con enlaces de 30 días se estabiliza en unos 5 GB de almacenamiento, mientras que el mismo usuario con una biblioteca permanente pasa de 60 GB al cabo de un año y sigue creciendo.

Eso es también lo que nos permite vender una licencia Lifetime. Un pago único no puede financiar un almacenamiento que crece durante años. Sí puede financiar enlaces de 3 días.

Foco

Si los enlaces no viven para siempre, una categoría entera de funciones deja de tener sentido: carpetas en la nube, búsqueda en la nube, analítica de visualizaciones, inserciones en webs. No tenemos que construirlas, protegerlas ni cobrarlas. JustRec no tiene una biblioteca en la nube, y es a propósito.

Por qué 3 días y 30 días

Las dos duraciones siguen a los planes:

Plan	El enlace dura	Duración máxima del vídeo	Por qué
Lifetime	3 días	10 min	Suficiente para feedback, revisiones y reportes de bugs; un precio único puede sostenerlo
Personal, Team	30 días	30 min	Cubre entregas, formación y presupuestos que el cliente vuelve a ver antes de decidir

Los planes y los límites pueden cambiar antes del lanzamiento.

Tres días bastan para la mayoría de los vídeos de revisión: el cliente lo ve el mismo día o al siguiente. Treinta días cubren los vídeos a los que la gente vuelve mientras aprende a usar un CMS nuevo o se piensa una propuesta. Más allá de un mes, un vídeo es material de consulta, y el material de consulta se merece un sitio en condiciones.

Cómo funciona la caducidad en nuestro servidor

El servidor es un Cloudflare Worker con Hono. Los vídeos, los subtítulos y las miniaturas viven en un bucket de R2 restringido a la UE; los metadatos viven en D1, también en la UE. La caducidad son dos mecanismos separados, a propósito.

1. Termina la subida

   Empieza la cuenta atrás

   El servidor guarda la hora de caducidad: 3 o 30 días a partir de ahora, según el plan.

2. Hasta que caduca

   El enlace funciona

   Cada petición de la página, el vídeo, los subtítulos o la miniatura comprueba primero la hora de caducidad.

3. En el segundo exacto en que caduca

   410 Gone

   La página dice que el enlace ha caducado y a quién pedir uno nuevo.

4. En menos de una hora

   Archivos borrados

   Una tarea que se ejecuta cada hora elimina de R2 el vídeo, los subtítulos y la miniatura.

1. El enlace se detiene en el segundo exacto. Cuando termina una subida, el servidor fija expires_at en la hora actual más la duración del enlace. Cada petición de la página, el vídeo, los subtítulos o la miniatura lo comprueba primero:

async function liveVideo(env: Env, id: string) {
  const row = await env.DB.prepare("SELECT * FROM videos WHERE id = ?").bind(id).first();
  const live = !!row && row.status === "ready" && (row.expires_at ?? 0) > now();
  return { row, live };
}

Si no está activo, la página responde con HTTP 410 Gone, dice que el enlace ha caducado o se ha retirado y pide a quien lo ve que se lo vuelva a pedir a quien lo envió, con su nombre. 410 es el código que significa que el recurso existió y se eliminó a propósito, que es exactamente el caso.

2. Los archivos se borran en menos de una hora. Un Cron Trigger ejecuta el Worker cada hora, en el minuto 17. Busca los vídeos que han superado su caducidad, borra los tres objetos de R2 y marca la fila como caducada:

async function cleanUp(env: Env) {
  const expired = await env.DB.prepare(
    "SELECT id FROM videos WHERE status = 'ready' AND expires_at <= ?",
  ).bind(now()).all<{ id: string }>();
  for (const { id } of expired.results) {
    await env.VIDEOS.delete([`videos/${id}.mp4`, `videos/${id}.vtt`, `videos/${id}.jpg`]);
    await env.DB.prepare("UPDATE videos SET status = 'expired' WHERE id = ?").bind(id).run();
  }
  // …y después aborta las subidas iniciadas hace más de 24 horas que nunca terminaron
}

Retirar un enlace desde la app se salta la espera: el servidor borra los archivos al momento y marca la fila como revocada. Las subidas que nunca terminaron se abortan a las 24 horas, así que tampoco quedan vídeos a medio subir ocupando almacenamiento.

Qué se queda, y por qué

Queremos ser precisos con lo que significa «borrado»:

• Borrado de R2: el vídeo, el archivo de subtítulos y la miniatura.
• Conservado en D1: la fila con el id del vídeo, el título, el nombre de quien lo envía, el tamaño, la duración, las fechas y el estado. Es lo que permite que la página de enlace caducado le diga a tu cliente de quién era el vídeo y a quién pedírselo.
• Conservado en tu Mac: el vídeo original y sus subtítulos, intactos.
• En el navegador de quien lo ve: la respuesta del vídeo permite al navegador guardarlo en una caché privada durante 10 minutos, así que una pestaña que ya había cargado una parte puede reproducirla brevemente después de la caducidad.

¿Por qué no las reglas de ciclo de vida de R2?

R2 puede hacer caducar objetos por su cuenta con reglas de ciclo de vida, según su antigüedad y su prefijo. No las usamos para los enlaces porque funcionan por antigüedad del objeto, se aplican por regla y no por vídeo, y los objetos se suelen eliminar en las 24 horas siguientes a su caducidad. Nosotros necesitamos que el enlace se detenga a una hora exacta, duraciones distintas según el plan y borrado inmediato cuando alguien retira un enlace. Una consulta en D1 y una tarea cada hora lo hacen en unas veinte líneas.

Las objeciones, y nuestras respuestas

Las esperamos, y algunas son justas:

Objeción	Nuestra respuesta	Lo que aceptamos
«Mi cliente abre el enlace tarde.»	La página le dice a quién pedírselo, y volver a compartirlo es un clic desde tu biblioteca.	Volver a compartir de vez en cuando.
«Necesito un enlace para material de formación que dure.»	Usa una plataforma de vídeo, un centro de ayuda o tu propia web para los vídeos de larga duración.	JustRec no es la herramienta adecuada para eso.
«¿Por qué no puedo elegir “nunca”?»	Entonces seríamos una empresa de alojamiento con una factura creciente y años de datos de clientes en línea.	Hay quien elegirá otra herramienta.
«Tres días es poco.»	Encaja con las rondas de revisión y los reportes de bugs, y hace posible el precio de Lifetime. Personal y Team tienen 30 días.	Quien use Lifetime para enviar entregas volverá a compartir más.

A qué renunciamos

Ser una herramienta de entrega tiene un coste. No hay enlaces permanentes que pegar en una web. No hay recuentos de visualizaciones, porque tampoco rastreamos a quien ve los vídeos. Algunos clientes verán una página de enlace caducado, y a unos pocos les molestará. Creemos que son los compromisos adecuados para vídeos que, al final, son conversaciones. Si necesitas lo contrario, una biblioteca permanente con analítica, hay buenas herramientas para eso, y nuestra página sobre la alternativa a Loom compara los dos enfoques.

La idea de fondo de todo esto es que tus vídeos son tuyos y deberían vivir en tu máquina. Escribimos sobre ello en grabación local-first: por qué tus vídeos deben quedarse en tu Mac.