Porque é que os nossos links de vídeo expiram

Os nossos links de vídeo expiram porque decidimos cedo que o JustRec entrega vídeos; não os aloja. Um link existe para que o seu cliente veja uma apresentação esta semana e, depois de cumprir essa função, mantê-lo online só acrescenta risco e custo. Os links que expiram estavam no nosso documento de produto antes de escrevermos uma linha de código de servidor.

Já explicámos o lado do utilizador, e como trabalhar com links que expiram, em links de vídeo que expiram: mais seguros que uma biblioteca permanente. Este é o outro lado: porque o escolhemos, o que nos custou e como funciona por dentro.

Entrega, não alojamento

A maioria das ferramentas de vídeo para trabalho gira à volta de uma biblioteca na nuvem. Os seus vídeos vivem lá, os links apontam para ela e o produto cresce acrescentando coisas à biblioteca: pastas, pesquisa, contagem de visualizações, comentários, incorporações.

Pense no que as agências e os freelancers enviam aos clientes: a segunda ronda de uma homepage, um erro num checkout, dois minutos sobre um orçamento. Esses vídeos têm um destinatário e um prazo. O cliente vê, responde, e a versão seguinte substitui a anterior. Ninguém volta à segunda ronda da homepage em março.

Por isso pensámos o JustRec como entrega. A gravação, a biblioteca e o histórico vivem no seu Mac. O servidor guarda uma cópia enquanto a entrega durar e depois deixa-a ir. Todas as outras decisões decorrem desta.

Três razões para escolhermos links que expiram

Os clientes dos nossos utilizadores não se inscreveram num arquivo de vídeo

Uma gravação de ecrã de trabalho para um cliente mostra muitas vezes dados desse cliente: um painel de administração, o nome de um consumidor, um dashboard. O princípio da limitação da conservação do RGPD (artigo 5.º, n.º 1, alínea e)) determina que os dados pessoais não devem ser guardados mais tempo do que o necessário. Um link permanente mantém-nos online indefinidamente, em servidores que nem a sua agência nem o seu cliente escolheram. Um link que expira transforma o «não mais do que o necessário» numa predefinição em vez de uma tarefa. O artigo sobre RGPD e vídeos para clientes explica quem é responsável por quê.

Custos que se mantêm estáveis

Com uma biblioteca permanente, cada utilizador custa todos os meses mais do que no mês anterior, para sempre. Com links que expiram, um utilizador que partilha o mesmo todos os meses custa o mesmo todos os meses. Fizemos as contas completas em quanto custa alojar vídeos de clientes no Cloudflare R2: um utilizador intenso com links de 30 dias estabiliza em cerca de 5 GB de armazenamento, enquanto o mesmo utilizador com uma biblioteca permanente passa dos 60 GB ao fim de um ano e continua a crescer.

É também isso que nos permite vender uma licença Lifetime. Um pagamento único não consegue financiar um armazenamento que cresce durante anos. Consegue financiar links de 3 dias.

Foco

Se os links não vivem para sempre, toda uma categoria de funcionalidades deixa de fazer sentido: pastas na nuvem, pesquisa na nuvem, estatísticas de visualizações, incorporação em sites. Não temos de as construir, proteger nem cobrar por elas. O JustRec não guarda uma biblioteca na nuvem, e é de propósito.

Porquê 3 dias e 30 dias

As duas durações acompanham os planos:

Plano	O link dura	Duração máxima do vídeo	Porquê
Lifetime	3 dias	10 min	Chega para feedback, revisões e reportar bugs; um preço único consegue sustentá-lo
Personal, Team	30 dias	30 min	Cobre entregas de projeto, formação e orçamentos que o cliente revê antes de decidir

Os planos e os limites podem mudar antes do lançamento.

Três dias chegam para a maioria dos vídeos de revisão: o cliente vê no próprio dia ou no seguinte. Trinta dias cobrem os vídeos a que as pessoas voltam enquanto aprendem um CMS novo ou pensam numa proposta. Para lá de um mês, um vídeo é material de referência, e o material de referência merece uma casa a sério.

Como funciona a expiração no nosso servidor

O servidor é um Cloudflare Worker com Hono. Os vídeos, as legendas e as miniaturas vivem num bucket R2 restrito à UE; os metadados vivem no D1, também na UE. A expiração são dois mecanismos separados, de propósito.

1. Carregamento concluído

   O relógio começa

   O servidor guarda a hora de expiração: daqui a 3 dias ou a 30 dias, conforme o plano.

2. Até expirar

   O link funciona

   Cada pedido da página, do vídeo, das legendas ou da miniatura verifica primeiro a hora de expiração.

3. No segundo em que expira

   410 Gone

   A página diz que o link expirou e a quem pedir um novo.

4. Dentro de uma hora

   Ficheiros apagados

   Uma tarefa de hora a hora remove do R2 o vídeo, as legendas e a miniatura.

1. O link para no segundo exato. Quando um carregamento termina, o servidor define expires_at como a hora atual mais a duração do link. Cada pedido da página, do vídeo, das legendas ou da miniatura verifica-o primeiro:

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 };
}

Se não estiver ativo, a página responde com HTTP 410 Gone, diz que o link expirou ou foi retirado e pede a quem vê que o volte a pedir a quem o enviou, pelo nome. O 410 é o código que significa que o recurso existiu e foi removido de propósito, que é exatamente o caso.

2. Os ficheiros são apagados dentro de uma hora. Um Cron Trigger corre o Worker de hora a hora, ao minuto 17. Encontra todos os vídeos com a expiração ultrapassada, apaga os três objetos do R2 e marca a linha como expirada:

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();
  }
  // …depois aborta os carregamentos iniciados há mais de 24 horas que nunca terminaram
}

Retirar um link a partir da app dispensa a espera: o servidor apaga os ficheiros de imediato e marca a linha como revogada. Os carregamentos que nunca terminaram são abortados ao fim de 24 horas, para que também não fiquem vídeos a meio no armazenamento.

O que fica, e porquê

Queremos ser precisos sobre o que significa «apagado»:

• Apagado do R2: o vídeo, o ficheiro de legendas e a miniatura.
• Mantido no D1: a linha com o id do vídeo, o título, o nome de quem envia, o tamanho, a duração, as datas e o estado. É isso que permite à página de link expirado dizer ao seu cliente de quem era o vídeo e a quem pedir.
• Mantido no seu Mac: o vídeo original e as legendas, intactos.
• No browser de quem vê: a resposta do vídeo permite ao browser guardá-lo em cache privada durante 10 minutos, por isso um separador que já tinha carregado parte do vídeo pode reproduzir essa parte por pouco tempo depois da expiração.

Porque não as regras de ciclo de vida do R2?

O R2 consegue expirar objetos sozinho com regras de ciclo de vida, por idade e por prefixo. Não as usámos para os links porque funcionam pela idade do objeto, aplicam-se por regra e não por vídeo, e os objetos são normalmente removidos até 24 horas depois da expiração. Precisamos que o link pare a uma hora exata, de durações diferentes por plano e de apagar de imediato quando alguém retira um link. Uma consulta ao D1 e uma tarefa de hora a hora fazem isso em cerca de vinte linhas.

As objeções, e as nossas respostas

Contamos com estas, e algumas são justas:

Objeção	A nossa resposta	O que aceitamos
«O meu cliente abre o link tarde.»	A página diz-lhe a quem pedir, e voltar a partilhar é um clique na sua biblioteca.	Uma ou outra nova partilha.
«Preciso de um link duradouro para material de formação.»	Use uma plataforma de vídeo, um centro de ajuda ou o seu próprio site para vídeos de longa duração.	O JustRec não é a ferramenta certa para esses.
«Porque não posso escolher “nunca”?»	Passaríamos a ser uma empresa de alojamento, com uma fatura a crescer e anos de dados de clientes online.	Algumas pessoas vão escolher outra ferramenta.
«Três dias é pouco.»	Serve para rondas de revisão e para reportar bugs, e torna possível o preço do Lifetime. O Personal e o Team têm 30 dias.	Quem usa o Lifetime para entregas de projeto vai partilhar de novo mais vezes.

Do que abdicámos

Ser uma ferramenta de entrega tem um custo. Não há links permanentes para colar num site. Não há contagem de visualizações, porque também não seguimos quem vê. Alguns clientes vão ver uma página de link expirado, e alguns vão ficar aborrecidos. Achamos que são os compromissos certos para vídeos que, no fundo, são conversas. Se precisa do oposto, uma biblioteca permanente com estatísticas, há boas ferramentas para isso, e a nossa página de alternativa ao Loom compara as duas abordagens.

A ideia por baixo de tudo isto é que os seus vídeos são seus e devem viver na sua máquina. Escrevemos sobre isso em gravação de ecrã local-first.