Envoyer n'est que la moitié de l'histoire — tôt ou tard, c'est vous qui recevez : un collègue veut vous remettre un fichier par Internet, l'une de vos machines veut le transmettre à une autre, ou vous voulez aller chercher quelque chose sur un serveur que vous administrez. La CLI Relayium couvre ces trois cas avec une commande différente pour chacun, et aucune ne nécessite de compte.
Choisissez receive quand quelqu'un d'autre vous envoie via un code de jumelage, serve quand vous voulez une boîte de réception permanente vers laquelle des machines de confiance peuvent envoyer à tout moment, et pull quand c'est vous qui allez chercher sur un serveur où vous pouvez déjà vous connecter en SSH.
Trois façons de recevoir, et quand utiliser chacune
La commande à exécuter dépend de qui déclenche le transfert et de la façon dont les deux machines se connaissent :
relayium receive <code> [destdir] — quelqu'un vous envoie à travers les réseaux avec un code de jumelage convenu hors bande. Pair-à-pair direct, vérifié par un code SAS.
relayium serve [--dir D] [--port N] [--once] [--allow-delete] — cette machine écoute les envois en daemon direct via relayium://, sur le port 9031 par défaut.
relayium pull [user@]host:src <dest> — vous allez chercher, via SSH, sur un serveur où vous pouvez déjà vous connecter, et vous récupérez des fichiers.
receive : quelqu'un vous envoie un fichier à travers les réseaux
C'est le pendant côté réception de relayium send. L'autre personne choisit un code court et vous le communique par un canal auquel vous faites tous deux confiance — un appel, un message — puis exécute relayium send <path> <code> de son côté. Vous exécutez receive avec le même code :
relayium receive 428571
# or into a specific directory
relayium receive 428571 ./downloads
La connexion est directe, pair-à-pair, et chiffrée de bout en bout ; une fois connectés, les deux terminaux affichent le même SAS (short authentication string) — comparez-le avec l'expéditeur pour être sûrs que personne n'est au milieu.
Sans destination indiquée, les fichiers atterrissent dans le répertoire courant.
Même règle de connexion directe uniquement que pour send : si aucun chemin direct n'est trouvé entre les deux réseaux, le transfert échoue plutôt que de transiter par un relais.
C'est le protocole de code de jumelage propre à la CLI — il ne s'interopère pas aujourd'hui avec le code de jumelage ou le flux QR du navigateur sur relayium.com ; c'est un ajout possible à l'avenir, pas encore quelque chose sur quoi compter.
Le destinataire n'a jamais besoin de compte, quel que soit le réseau.
serve : transformer cette machine en boîte de réception à l'écoute
serve fonctionne dans l'autre sens : au lieu que vous alliez chercher, d'autres machines vous envoient directement via relayium:// — conçu pour des machines en qui vous avez déjà confiance, comme votre propre ordinateur portable qui envoie vers un NAS, ou un serveur de build qui dépose des artefacts sur une machine qui vous appartient — via une connexion TLS 1.3 épinglée, sans SSH, sans rendez-vous.
relayium serve
# a specific directory, port, and allowing delete requests
relayium serve --dir ~/incoming --port 9031 --allow-delete
La première fois qu'une nouvelle machine vous envoie quelque chose, serve (exécuté dans un terminal) affiche son adresse et son empreinte et vous demande de l'approuver une fois ; ensuite, les envois de la même empreinte passent silencieusement.
Sans terminal — un service systemd, un script sans TTY — il n'y a personne à qui demander, donc un émetteur inconnu est rejeté d'emblée. Autorisez-le plutôt à l'avance, en utilisant l'empreinte que l'émetteur affiche avec relayium id :
Autoriser à l'avance pour un serve sans surveillance
Pour un serve qui tourne sans surveillance (systemd, un script en arrière-plan), demandez à l'émetteur d'exécuter relayium id pour afficher son empreinte, puis approuvez-la à l'avance côté récepteur :
relayium authorize <fingerprint>
--dir définit où les fichiers atterrissent (par défaut le répertoire courant) ; --once accepte un seul transfert puis s'arrête ; --allow-delete permet à une requête --delete (miroir) entrante de réellement supprimer des fichiers ici, et est désactivé par défaut.
--config-dir (par défaut ~/.config/relayium) est l'endroit où se trouvent l'identité de cet hôte et sa liste d'empreintes autorisées — surchargez-le si vous exécutez serve comme service dédié.
pull : aller chercher sur un serveur où vous pouvez déjà vous connecter en SSH
pull est le miroir de push : au lieu d'attendre que quelqu'un vous envoie quelque chose, vous allez chercher via votre accès SSH existant et récupérez des fichiers.
Contrairement à push, pull a toujours besoin de relayium déjà installé sur la machine distante — il n'y a pas de repli tar pour un pull depuis un serveur nu. Si relayium n'y est pas encore, installez-le d'abord avec curl -fsSL https://relayium.com/install.sh | sh.
Les fichiers sont vérifiés par un contrôle SHA-256 par fichier et reprennent automatiquement en cas d'interruption (ajoutez --no-resume pour désactiver).
-i et -p se comportent comme les -i/-p de ssh lui-même, pour un fichier d'identité ou un port spécifique.
Questions fréquentes
Ai-je besoin d'un compte pour recevoir des fichiers ?
Non. Les trois méthodes — receive, serve et pull — sont entièrement gratuites et ne nécessitent aucun compte Relayium, d'aucun côté.
relayium receive s'interopère-t-il avec le code de jumelage du navigateur ?
Non. Le protocole de code de jumelage de la CLI est distinct du flux de lien de participation et de QR code du navigateur sur relayium.com — ils utilisent des poignées de main différentes et ne communiquent pas entre eux aujourd'hui. C'est sur la feuille de route, mais ce n'est pas encore quelque chose sur quoi compter.
Que se passe-t-il si une machine inconnue envoie vers mon écouteur serve ?
Dans un terminal, on vous demande de l'approuver par son adresse et son empreinte lors de son premier envoi, et l'approbation est mémorisée. Sans terminal — un service systemd, une tâche cron — il n'y a personne à qui demander, donc un émetteur inconnu est rejeté ; autorisez-le d'abord avec relayium authorize <fingerprint>.
Puis-je faire un pull depuis un serveur où relayium n'est pas installé ?
Non. pull a toujours besoin de relayium côté distant ; il n'y a pas de repli tar comme pour push. Installez d'abord relayium là-bas.
Où relayium conserve-t-il mon identité et les pairs de confiance ?
Par défaut dans ~/.config/relayium — surchargez cet emplacement avec --config-dir sur toute commande touchant à l'identité ou à la confiance.
Prêt à recevoir votre premier transfert ? Installez la CLI et choisissez receive, serve ou pull.