Zuletzt aktualisiert: 2026-07-09
magic-wormhole hat sich still und leise eine treue Anhängerschaft erarbeitet: starten, einen kurzen, gut vorlesbaren Code wie 7-crossover-clockwork erhalten, ihn der anderen Person nennen — und die Datei kommt an, durchgehend verschlüsselt, ohne Konto und ohne Server, um den man sich kümmern muss. Die Relayium CLI folgt einer ähnlichen Idee: ein kurzer Code koppelt zwei Rechner direkt und verschlüsselt alles dazwischen.
Beide überschneiden sich stark, und wo nicht, lohnt es sich, präzise zu sein — auch bei dem einen Punkt, an dem magic-wormhole heute tatsächlich robuster ist als die Relayium-CLI.
Beide Tools lösen dasselbe Kernproblem auf dieselbe ehrliche Art: kein Konto, keine Datei, die auf einem Server liegen bleibt, den du nicht kontrollierst, und ein kurzer Code als einziges, worauf sich beide Enden außerhalb des Kanals einigen müssen.
Das ist der ehrliche Kompromiss, und er sollte klar benannt werden, statt beschönigt zu werden. magic-wormhole bringt ein Transit Relay mit, auf das es zurückgreifen kann, wenn die beiden Enden keine direkte Verbindung zueinander aufbauen können — etwa wenn beide Seiten hinter strengem oder symmetrischem NAT sitzen und sich keine Öffnung finden lässt. Das Relay sieht dabei immer nur Chiffretext, aber weil es existiert, wird die Übertragung trotzdem abgeschlossen.
Relayiums send/receive ist rein direkt: Es versucht direkt nach dem Handshake für ein paar Sekunden eine direkte Verbindung aufzubauen, und findet es keine, schlägt die Übertragung schlicht fehl, statt auf ein Relay auszuweichen — Relayiums Server kommen laut Design nie mit den Dateibytes einer netzwerkübergreifenden CLI-Übertragung in Berührung. In der Praxis ist das selten (die meisten Heim- und Büronetzwerke erlauben einen direkten Pfad), aber wenn du Dateien zwischen zwei Maschinen bewegst, die beide hinter ungewöhnlich strengem NAT sitzen, funktioniert magic-wormhole eher einfach so. Wenn sich kein direkter Pfad finden lässt und Zuverlässigkeit wichtiger ist als die Vermeidung eines Relays, ist das der Fall, in dem sich magic-wormhole anbietet — oder Relayiums push/pull bzw. daemon-direct gegen einen tatsächlich erreichbaren Server, die überhaupt nicht von diesem direkten P2P-Hop abhängen.
Dort, wo die Relayium-CLI wirklich zusätzliche Fläche hinzufügt, liegt außerhalb des einmaligen Pairing-Code-Falls: zwei weitere Wege, Dateien zu bewegen, die sich auf Infrastruktur stützen, die du bereits hast — ein Bereich, den magic-wormhole gar nicht abzudecken versucht.
relayium push / pull nutzt deinen bestehenden SSH-Zugang, also gibt es nichts Neues zu vertrauen und keinen Code zu teilen. push funktioniert sogar gegen einen Server ohne installiertes relayium und fällt dann auf einen einfachen tar-Stream über die SSH-Verbindung zurück — dieser Fallback existiert nur bei push; pull braucht immer relayium auf der Gegenseite, da es dort als Absender agiert.
relayium serve macht aus jeder Maschine, die dir gehört, ein daemon-direct-Ziel, erreichbar über gepinntes TLS 1.3, ohne SSH und ohne Code — Vertrauen entsteht bei der ersten Verbindung (interaktiv bestätigt oder für unbeaufsichtigten Betrieb vorab autorisiert) und ist danach gepinnt, dieselbe Idee wie ein SSH-Host-Key.
relayium push ./photos user@your-server:backups/relayium serve --dir ~/incomingrelayium push ./build relayium://your-servermagic-wormhole sendet eine Reihe von Dateien (oder einen gezippten Ordner) und beendet sich dann — um die Gegenseite zu aktualisieren, musst du erneut senden, ein Konzept, was gelöscht werden soll, gibt es nicht. Die Relayium CLI fügt relayium sync hinzu, einen inkrementellen Einweg-Spiegel über einen der beiden obigen Transportwege: Es bewegt nur, was sich geändert hat; --delete entfernt Dateien am Ziel, die auf der Quelle verschwunden sind (ein Daemon befolgt das nur, wenn er mit --allow-delete gestartet wurde, der Empfänger muss also selbst zustimmen); --watch synchronisiert bei Dateiänderungen laufend in Echtzeit neu, kein Cron-Job nötig.
Wenn du dich nicht auf relayium.com verlassen, sondern alles selbst betreiben willst, lässt sich Relayiums Server auch als einzelner Docker-Container selbst hosten; richte die CLI mit --server darauf aus.
relayium sync ./photos user@your-server:backups/photos --delete --watchDie wichtigsten Unterschiede nebeneinander:
Ja, vollständig. Es gibt keine bezahlte Stufe und nichts zu messen — jeder Modus verbindet die beiden Enden direkt, und die CLI ist quelloffen.
Nein. push/pull nutzt deinen eigenen SSH-Zugang, daemon-direct nutzt gepinntes TLS-Zertifikatsvertrauen zwischen deinen Maschinen, und send/receive nutzt einen Code, den ihr außerhalb des Kanals vereinbart. Nichts davon berührt ein Relayium-Konto.
In diesem Fall ist Relayiums send/receive rein direkt und schlägt fehl — es weicht nicht auf ein Relay aus. magic-wormholes Transit Relay kann den verschlüsselten Datenstrom trotzdem tragen und die Übertragung abschließen. Wenn es unabhängig vom Netzwerk funktionieren muss, deckt magic-wormhole diesen Fall heute ab; Relayiums push/pull oder daemon-direct gegen einen erreichbaren Server funktionieren ebenfalls, da sie nicht von einem direkten P2P-Hop abhängen.
Noch nicht für eine gekoppelte Live-Übertragung — send/receive der CLI nutzt einen eigenen, direkten Handshake, getrennt vom WebRTC-basierten Pairing-Ablauf des Browsers, sodass beide heute nicht zusammenarbeiten. Um jemandem nur per Browser eine Datei zu übergeben, nutze Relayiums gespeicherten Download-Link oder den eigenen Pairing-Code-Modus der Browser-App.
Ja. Relayiums Server wird als Docker-Image ausgeliefert (docker compose up -d --build), und du kannst send/receive der CLI mit --server https://your-domain auf deine eigene Instanz zeigen lassen.
Installiere die kostenlose Relayium CLI und probiere push, sync oder send — ohne Konto, und eine codebasierte Übertragung genauso schnell startklar wie magic-wormhole.
CLI holen