Enviar es solo la mitad de la historia — tarde o temprano estás en el extremo receptor: un colega quiere entregarte un archivo por internet, una de tus propias máquinas quiere pasárselo a otra, o quieres ir a buscar algo en un servidor que administras. La CLI de Relayium cubre los tres casos con un comando distinto para cada uno, y ninguno necesita cuenta.
Elige receive cuando alguien te envía por código de emparejamiento, serve cuando quieres un buzón permanente al que máquinas de confianza puedan enviar en cualquier momento, y pull cuando eres tú quien va a buscar en un servidor al que ya puedes conectarte por ssh.
Tres formas de recibir, y cuándo aplica cada una
Qué comando ejecutas depende de quién inicia la transferencia y de cómo se conocen las dos máquinas:
relayium receive <code> [destdir] — alguien te envía entre redes usando un código de emparejamiento que generó su CLI y te comunicó fuera de banda. Directo de igual a igual, verificado con un código SAS.
relayium serve [--dir D] [--port N] [--once] [--allow-delete] — esta máquina escucha envíos en daemon directo por relayium://, en el puerto 9031 por defecto.
relayium pull [user@]host:src <dest> — vas a buscar por SSH a un servidor al que ya puedes conectarte y recuperas archivos.
receive: alguien te envía un archivo entre redes
Esta es la mitad receptora de relayium send. La otra persona ejecuta relayium send <path> en su extremo (tras relayium login); su CLI genera un código de 6 caracteres, válido 5 minutos, y lo imprime. Te dice cuál es por cualquier canal en el que ambos confíen — una llamada, un mensaje de chat. Tú ejecutas receive con ese código:
relayium receive K7M4XR
# o dentro de un directorio concreto
relayium receive K7M4XR ./downloads
La conexión es directa, de igual a igual y cifrada de extremo a extremo; ambos terminales imprimen el mismo SAS (cadena de autenticación corta) una vez conectados — compáralo con el remitente para asegurarte de que nadie está en el medio.
Sin destino indicado: los archivos caen en el directorio actual.
La misma regla de solo directo que send: si no puede hallarse ninguna ruta directa entre las dos redes, la transferencia falla en lugar de enrutarse por un retransmisor.
Este es el propio protocolo de código de emparejamiento de la CLI — un código de la CLI solo se empareja con otra CLI. Hoy no interopera con el código de emparejamiento del navegador ni con el flujo de QR en relayium.com; eso es una posible adición futura, no algo en lo que puedas confiar todavía. Si solo tienes navegador, pídele al remitente un enlace de descarga de relayium up.
El receptor nunca necesita una cuenta, en ninguna red. Solo el remitente inicia sesión, para que su CLI pueda generar el código.
serve: convierte esta máquina en un buzón a la escucha
serve funciona al revés: en lugar de que seas tú quien va a buscar, otras máquinas te envían directamente por relayium:// — pensado para máquinas en las que ya confías, como tu propio portátil enviando a un NAS, o un servidor de compilación dejando artefactos en una máquina que es tuya — por una conexión TLS 1.3 con anclaje, sin SSH, sin punto de encuentro.
relayium serve
# un directorio y un puerto concretos, permitiendo peticiones de borrado
relayium serve --dir ~/incoming --port 9031 --allow-delete
La primera vez que una máquina nueva te envía algo, serve (ejecutándose en un terminal) muestra su dirección y su huella y te pide que la apruebes una vez; después, los envíos de la misma huella pasan en silencio.
Sin terminal — un servicio systemd, un script sin TTY — no hay a quién preguntar, así que un emisor no reconocido se rechaza de plano. En su lugar, autorízalo por adelantado usando la huella que el emisor imprime con relayium id:
Autorizar por adelantado para un serve desatendido
Para un serve que corre desatendido (systemd, un script en segundo plano), haz que el emisor ejecute relayium id para imprimir su huella, y luego apruébala de antemano desde el lado receptor:
relayium authorize <fingerprint>
--dir fija dónde caen los archivos (por defecto el directorio actual); --once acepta una única transferencia y sale; --allow-delete deja que una petición --delete (espejo) entrante realmente elimine archivos aquí, y está desactivado por defecto.
--config-dir (por defecto ~/.config/relayium) es donde viven la identidad de este host y su lista de huellas autorizadas — anúlalo si ejecutas serve como un servicio dedicado.
pull: ve a buscar y recupera de un servidor al que puedes conectarte por ssh
pull es el espejo de push: en lugar de esperar a que alguien te envíe algo, vas a buscar por tu acceso SSH existente y recuperas archivos.
A diferencia de push, pull siempre necesita relayium ya instalado en el remoto — no hay respaldo con tar para hacer pull desde un servidor pelado. Si el remoto aún no lo tiene, instálalo allí primero con curl -fsSL https://relayium.com/install.sh | sh.
Los archivos se verifican con una comprobación SHA-256 por archivo y se reanudan automáticamente si se interrumpen (añade --no-resume para desactivarlo).
-i y -p se comportan como los propios -i/-p de ssh, para un archivo de identidad o un puerto específico.
Preguntas frecuentes
¿Necesito una cuenta para recibir archivos?
No. Las tres formas — receive, serve y pull — son completamente gratis y no necesitan una cuenta de Relayium por tu parte. El único inicio de sesión en todo esto es el del remitente en modo receive, para que su CLI pueda generar el código de emparejamiento.
¿relayium receive interopera con el código de emparejamiento del navegador?
No. El protocolo de código de emparejamiento de la CLI está separado del flujo de enlace de unión y QR del navegador en relayium.com — usan handshakes distintos y hoy no se hablan entre sí, así que un código de la CLI solo se empareja con otra CLI. Eso está en la hoja de ruta, no es algo en lo que puedas confiar todavía. Hasta entonces, quien reciba desde un navegador quiere un enlace de relayium up, no un código.
¿Qué pasa si una máquina desconocida envía a mi proceso serve a la escucha?
En un terminal, se te pide aprobarla por dirección y huella en su primer envío, y la aprobación se recuerda. Sin terminal — un servicio systemd, una tarea cron — no hay a quién preguntar, así que un emisor no reconocido se rechaza; autorízalo primero con relayium authorize <fingerprint>.
¿Puedo hacer pull desde un servidor que no tiene relayium instalado?
No. pull siempre necesita relayium en el extremo remoto; no hay respaldo con tar como lo hay para push. Instala relayium allí primero.
¿Dónde guarda relayium mi identidad y los pares de confianza?
En ~/.config/relayium por defecto — anula la ubicación con --config-dir en cualquier comando que toque la identidad o la confianza.
¿Listo para recibir tu primera transferencia? Instala la CLI y elige receive, serve o pull.