Relayium

Relayium vs magic-wormhole: transferência de arquivos por CLI

Última atualização: 2026-07-12

O magic-wormhole conquistou silenciosamente um público fiel: você o executa, recebe um código curto e legível como 7-crossover-clockwork, lê para a outra pessoa e o arquivo chega — criptografado o caminho todo, sem conta e sem nenhum servidor com que precise se preocupar. A CLI do Relayium foi construída em torno de uma ideia parecida: um código curto que emparelha dois computadores diretamente e criptografa tudo o que passa entre eles.

Eles se sobrepõem bastante, e onde não se sobrepõem vale a pena ser preciso — incluindo o único ponto em que o magic-wormhole hoje é genuinamente mais resiliente que a CLI do Relayium.

O que eles têm em comum

Ambas as ferramentas resolvem o mesmo problema central da mesma forma honesta: sem nenhum arquivo depositado em um servidor que você não controla, e um código curto como a única coisa que as duas pontas trocam por outro canal. O magic-wormhole não precisa de conta nenhuma; o Relayium pede login só a quem envia, para que o servidor dele possa gerar esse código, e quem recebe continua sem precisar.

O único ponto em que o magic-wormhole é mais resiliente: ele tem um retransmissor

Essa é a concessão honesta, e vale a pena dizê-la com clareza em vez de contorná-la. O magic-wormhole vem com um Transit Relay ao qual pode recorrer quando as duas pontas não conseguem abrir uma conexão direta entre si — por exemplo, ambos os lados atrás de um NAT rígido ou simétrico sem como atravessá-lo. O retransmissor só vê texto cifrado, mas, por existir, a transferência ainda assim se completa.

O send/receive do Relayium é somente direto: ele tenta uma conexão direta por alguns segundos logo após o handshake e, se não encontra nenhuma, a transferência simplesmente falha em vez de recorrer a qualquer retransmissor — os servidores do Relayium nunca tocam os bytes de arquivos de uma transferência CLI entre redes, por decisão de projeto. Na prática isso é raro (a maioria das redes domésticas e de escritório permite um caminho direto), mas se você estiver movendo arquivos entre duas máquinas ambas atrás de NAT excepcionalmente rígidos, é mais provável que o magic-wormhole simplesmente funcione. Se não for possível encontrar um caminho direto e a confiabilidade importar mais do que evitar um retransmissor, esse é o caso para recorrer ao magic-wormhole — ou para usar o push/pull ou o daemon direto do Relayium contra um servidor que você realmente consiga alcançar, que não dependem em nada desse salto P2P direto.

Antes de começar

Tudo abaixo é a CLI do relayium, então instale-a primeiro se ainda não tiver. No macOS ou Linux, um comando coloca um binário pré-compilado no seu PATH:

curl -fsSL https://relayium.com/install.sh | sh

SSH e daemon direto: falar com um servidor que você já opera

Onde a CLI do Relayium acrescenta superfície de verdade é fora do caso pontual do código de emparelhamento: mais duas formas de mover arquivos que se apoiam em infraestrutura que você já tem, algo que o magic-wormhole não tenta cobrir.

O relayium push / pull reutiliza seu acesso SSH existente, então não há nada novo em que confiar nem nenhum código de emparelhamento a compartilhar. O push até funciona contra um servidor sem nenhum relayium instalado, recorrendo a um simples fluxo tar sobre a conexão SSH — esse recurso de reserva é só do push; o pull sempre precisa do relayium no remoto, já que ali ele atua como remetente.

O relayium serve transforma qualquer máquina que você possua em um destino daemon direto, acessível por TLS 1.3 com fixação, sem SSH e sem código de emparelhamento — a confiança se estabelece na primeira conexão (aprovada de forma interativa, ou pré-autorizada para uso não supervisionado) e fica fixada a partir daí, a mesma ideia de uma chave de host SSH.

relayium push ./photos user@your-server:backups/
relayium serve --dir ~/incoming
relayium push ./build relayium://your-server

Sincronização de pastas e um servidor auto-hospedável

O magic-wormhole envia um lote de arquivos (ou uma pasta, compactada) e encerra — envie de novo para atualizar o outro lado, sem nenhuma noção do que deveria ser removido. A CLI do Relayium acrescenta o relayium sync, um espelho incremental de sentido único sobre qualquer um dos dois transportes acima: ele só move o que mudou, o --delete remove no destino os arquivos que desapareceram da origem (um daemon só respeita isso se tiver sido iniciado com --allow-delete, então o receptor precisa optar por isso) e o --watch continua ressincronizando em tempo real conforme os arquivos mudam, sem necessidade de nenhuma tarefa cron.

O servidor do Relayium também é auto-hospedável como um único contêiner Docker, caso você queira rodar tudo por conta própria em vez de depender do relayium.com; aponte a CLI para ele com --server.

relayium sync ./photos user@your-server:backups/photos --delete --watch

Comparação de recursos em resumo

As diferenças que mais importam, lado a lado:

Perguntas frequentes

A CLI do Relayium é gratuita?

Sim, completamente. Não há nível pago nem nada a medir — cada modo conecta as duas pontas diretamente, e a CLI é de código aberto.

Ela precisa de conta?

O send sim, e o up na nuvem também. O push/pull usa seu próprio acesso SSH e o daemon direto usa a confiança de certificado TLS com fixação entre suas máquinas, então nenhum dos dois toca uma conta do Relayium. O send/receive é a exceção: só o servidor pode gerar um código de emparelhamento, e apenas para uma conta com login feito, então quem envia roda relayium login uma vez; um send ao qual você passa um código que lhe deram não gera nenhum e não precisa de login. Receber nunca precisa de conta.

E se eu estiver atrás de um NAT rígido e não houver caminho direto?

O send/receive do Relayium é somente direto e falhará nesse caso — ele não recorre a um retransmissor. O Transit Relay do magic-wormhole ainda pode carregar o fluxo criptografado e completar a transferência. Se você precisa que funcione não importa como seja a rede, o magic-wormhole cobre esse caso hoje; o push/pull ou o daemon direto do Relayium contra um servidor que você consiga alcançar também funcionam, já que não dependem de um salto P2P direto.

Posso usar o código de emparelhamento da CLI com o aplicativo web do Relayium?

Ainda não para uma transferência emparelhada ao vivo — o send/receive da CLI usa seu próprio handshake direto, separado do fluxo de emparelhamento do navegador baseado em WebRTC, então os dois não interoperam hoje. Para entregar um arquivo a alguém que usa apenas um navegador, use o link de download armazenado do Relayium ou o próprio modo de código de emparelhamento do aplicativo web.

Posso auto-hospedá-lo?

Sim. O servidor do Relayium é distribuído como imagem Docker (docker compose up -d --build), e você pode apontar o send/receive da CLI para a sua própria instância com --server https://your-domain.

Instale a CLI gratuita do Relayium e experimente push, sync ou send — totalmente gratuita, e uma transferência baseada em código tão rápida de começar quanto o magic-wormhole.

Obter a CLI

Continue lendo