آخر تحديث: 2026-07-12
اكتسب magic-wormhole بهدوء جمهورًا وفيًا: شغّله، فتحصل على رمز قصير سهل القراءة مثل 7-crossover-clockwork، اقرأه للطرف الآخر فيصل الملف — مشفَّرًا طوال الطريق، بدون حساب وبدون خادم عليك التفكير فيه. وقد بُني CLI في Relayium حول فكرة مشابهة: رمز قصير يقرن جهازي حاسوب مباشرة ويشفّر كل ما بينهما.
يتداخل الاثنان كثيرًا، وحيث لا يتداخلان يستحق الأمر الدقّة في وصفه — بما في ذلك الموضع الوحيد الذي يكون فيه magic-wormhole اليوم أكثر صمودًا فعلًا من CLI في Relayium.
تحلّ الأداتان المشكلة الجوهرية نفسها بالطريقة الصادقة نفسها: لا ملف مُخزَّن على خادم لا تتحكم فيه، ورمز قصير هو الشيء الوحيد الذي يتناقله الطرفان خارج القناة. أما الحساب فلا تحتاجه magic-wormhole إطلاقًا، بينما يطلبه Relayium من المُرسِل وحده كي يُصدر خادمه ذلك الرمز، ويظل المُستقبِل بلا حاجة إليه.
هذه هي المفاضلة الصادقة، ويجدر ذكرها بوضوح بدل التغاضي عنها. يأتي magic-wormhole مزوّدًا بمُرحِّل Transit Relay يمكنه الرجوع إليه حين يتعذّر على الطرفين فتح اتصال مباشر بينهما — مثلًا حين يكون كلا الجانبين خلف NAT صارم أو متماثل بلا وسيلة للاختراق. لا يرى المُرحِّل سوى نص مُشفَّر دائمًا، لكن لأنه موجود، تكتمل عملية النقل رغم ذلك.
أما send/receive في Relayium فمباشر فقط: يتسابق على اتصال مباشر لبضع ثوانٍ مباشرة بعد المصافحة، وإن لم يجده يفشل النقل تمامًا بدل الرجوع إلى أي مُرحِّل — فخوادم Relayium لا تلمس إطلاقًا بايتات ملفات CLI العابرة للشبكات، بحكم التصميم. هذا نادر عمليًا (تسمح معظم الشبكات المنزلية والمكتبية بمسار مباشر)، لكن إن كنت تنقل ملفات بين جهازين كلاهما خلف NAT صارم على نحو غير معتاد، فمن الأرجح أن يعمل magic-wormhole ببساطة. إن تعذّر إيجاد مسار مباشر وكانت الموثوقية أهم من تجنّب المُرحِّل، فتلك هي الحالة التي تستدعي اللجوء إلى magic-wormhole — أو استخدام push/pull في Relayium أو daemon direct مقابل خادم تستطيع فعلًا الوصول إليه، وهذه لا تعتمد على تلك القفزة المباشرة من الند للند أصلًا.
كل ما يلي هو relayium CLI، فثبّته أولًا إن لم تكن قد فعلت. على macOS وLinux، يُسقط أمر واحد ملفًا ثنائيًا مُسبق البناء في PATH الخاص بك:
curl -fsSL https://relayium.com/install.sh | shحيث يضيف CLI في Relayium مساحة حقيقية هو خارج حالة رمز الاقتران لمرة واحدة: طريقتان إضافيتان لنقل الملفات تعتمدان على بنية تحتية تملكها أصلًا، وهو ما لا يحاول magic-wormhole تغطيته.
يعيد relayium push / pull استخدام وصول SSH القائم لديك، فلا شيء جديد لتثق به ولا رمز اقتران لمشاركته. بل يعمل push حتى مقابل خادم لا يوجد فيه relayium مثبَّت إطلاقًا، بالرجوع إلى تدفّق tar عادي عبر اتصال SSH — وهذا الرجوع خاص بـ push فقط؛ أما pull فيحتاج دائمًا إلى relayium على الطرف البعيد، إذ يعمل هناك بصفته المُرسِل.
يحوّل relayium serve أي جهاز تملكه إلى هدف daemon direct، يمكن الوصول إليه عبر TLS 1.3 مثبَّت بلا SSH وبلا رمز اقتران — تُبنى الثقة عند الاتصال الأول (يُوافَق عليه تفاعليًا، أو يُصرَّح به مسبقًا للاستخدام غير المراقَب) وتبقى مثبَّتة بعد ذلك، وهي الفكرة نفسها مثل مفتاح مضيف SSH.
relayium push ./photos user@your-server:backups/relayium serve --dir ~/incomingrelayium push ./build relayium://your-serverيرسل magic-wormhole دفعة من الملفات (أو مجلدًا مضغوطًا) ثم يخرج — أرسِلها مجددًا لتحديث الطرف الآخر، بلا أي مفهوم لما ينبغي حذفه. يضيف CLI في Relayium الأمر relayium sync، وهو مرآة تزايدية أحادية الاتجاه فوق أيٍّ من النقلين أعلاه: ينقل فقط ما تغيّر، ويحذف --delete الملفات على الوجهة التي اختفت من المصدر (لا يحترم ذلك daemon إلا إن بُدئ بـ --allow-delete، فعلى المستقبِل أن يوافق صراحةً)، ويبقي --watch على إعادة المزامنة فورًا كلما تغيّرت الملفات، بلا حاجة إلى مهمة cron.
خادم Relayium قابل أيضًا للاستضافة الذاتية كحاوية Docker واحدة إن أردت تشغيل كل شيء بنفسك بدل الاعتماد على relayium.com؛ وجّه إليه CLI باستخدام --server.
relayium sync ./photos user@your-server:backups/photos --delete --watchأهمّ الفروق، جنبًا إلى جنب:
نعم، تمامًا. لا توجد فئة مدفوعة ولا شيء يُقاس — كل وضع يوصل الطرفين مباشرة، و CLI مفتوح المصدر.
send نعم، وكذلك up السحابي. يستخدم push/pull وصولك عبر SSH، ويستخدم daemon direct ثقة شهادة TLS المثبَّتة بين أجهزتك، فلا يلمس أيٌّ منهما حساب Relayium. أما send/receive فهو الاستثناء: لا يستطيع إصدار رمز الاقتران إلا الخادم، ولحساب مسجَّل الدخول فقط، لذا يشغّل المُرسِل relayium login مرة واحدة — أما send الذي تمرّر له رمزًا أعطاك إياه غيرك فلا يُصدر شيئًا ولا يحتاج تسجيل دخول. أما الاستقبال فلا يحتاج حسابًا أبدًا.
send/receive في Relayium مباشر فقط وسيفشل في تلك الحالة — فهو لا يرجع إلى مُرحِّل. يستطيع مُرحِّل Transit Relay في magic-wormhole حمل التدفّق المُشفَّر وإتمام النقل رغم ذلك. إن احتجت أن يعمل مهما كان شكل الشبكة، فإن magic-wormhole يعالج هذه الحالة اليوم؛ كما يعمل push/pull في Relayium أو daemon direct مقابل خادم تستطيع الوصول إليه، لأنهما لا يعتمدان على قفزة مباشرة من الند للند.
ليس بعد لنقل مقترن حيّ — إذ يستخدم send/receive في CLI مصافحته المباشرة الخاصة، المنفصلة عن تدفّق الاقتران القائم على WebRTC في المتصفح، فلا يتوافق الاثنان اليوم. لتسليم ملف لشخص يستخدم المتصفح فقط، استخدم رابط التنزيل المُخزَّن في Relayium أو وضع رمز الاقتران الخاص بتطبيق المتصفح نفسه.
نعم. يُشحن خادم Relayium كصورة Docker (docker compose up -d --build)، ويمكنك توجيه send/receive في CLI إلى نسختك الخاصة بـ --server https://your-domain.
ثبّت CLI المجاني في Relayium وجرّب push أو sync أو send — مجانًا تمامًا، ونقل قائم على رمز يبدأ بالسرعة نفسها مثل magic-wormhole.
احصل على CLI