Relayium مقابل magic-wormhole: نقل الملفات عبر CLI

ما هو مشترك بينهما

تحلّ الأداتان المشكلة الجوهرية نفسها بالطريقة الصادقة نفسها: لا ملف مُخزَّن على خادم لا تتحكم فيه، ورمز قصير هو الشيء الوحيد الذي يتناقله الطرفان خارج القناة. أما الحساب فلا تحتاجه magic-wormhole إطلاقًا، بينما يطلبه Relayium من المُرسِل وحده كي يُصدر خادمه ذلك الرمز، ويظل المُستقبِل بلا حاجة إليه.

• مشفّر من الطرف إلى الطرف: يشتقّ magic-wormhole مفتاح الجلسة من رمز الـ wormhole نفسه باستخدام PAKE (SPAKE2)، بحيث لا يعرف المفتاح حتى خادم التعارف الخاص به؛ أما send/receive في Relayium فيجري تبادل مفاتيح X25519 مباشرة بين الطرفين ويعرض رمز تحقق قصير (SAS) يمكنك مقارنته قبل تحرّك أي بايت.
• لا حساب للاستقبال في كلتا الأداتين — ولا حساب إطلاقًا مع magic-wormhole.
• مجاني ومفتوح المصدر — اقرأ الشيفرة التي تلمس ملفاتك.
• متعدد المنصات: macOS و Linux و Windows.

المُرحِّلات: يستخدمها magic-wormhole وRelayium كلاهما

هذه هي المفاضلة الصادقة، ويجدر ذكرها بوضوح بدل التغاضي عنها. يأتي magic-wormhole مزوّدًا بمُرحِّل Transit Relay يمكنه الرجوع إليه حين يتعذّر على الطرفين فتح اتصال مباشر بينهما — مثلًا حين يكون كلا الجانبين خلف NAT صارم أو متماثل بلا وسيلة للاختراق. لا يرى المُرحِّل سوى نص مُشفَّر دائمًا، لكن لأنه موجود، تكتمل عملية النقل رغم ذلك.

يمرّر send/receive في Relayium كل بايت عبر مُرحِّل TURN مُشفَّر كلما أصدر الخادم مُرحِّلًا للرمز — حتى مع وجود مسار مباشر — وتُحتسب البايتات المُرحَّلة ضمن حصة حركة البيانات الشهرية للحساب الذي أنشأ الرمز؛ ولا يرى المُرحِّل إلا نصًا مُشفَّرًا. ولا يحتاج إلى مسار مباشر إلا حين لا يصدر مُرحِّل (لم يُهيَّأ مُرحِّل، أو نفدت تلك الحصة)، وعندها قد يفشل بين جهازين خلف NAT صارم على نحو غير معتاد، حيث يظل مُرحِّل magic-wormhole قادرًا على حمل النقل. ولا يعتمد daemon direct إلى خادم يمكن الوصول إليه على قفزة P2P مباشرة أيضًا.

قبل أن تبدأ

كل ما يلي هو relayium CLI، فثبّته أولًا إن لم تكن قد فعلت. على macOS وLinux، يُسقط أمر واحد ملفًا ثنائيًا مُسبق البناء في PATH الخاص بك:

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

• تفضّل اختيار الملف بنفسك، أو تعمل على Windows؟ احصل على ملف ثنائي من صفحة الإصدارات — يسرد relayium.com/cli كل خيارات التثبيت (أو go build ./cmd/relayium إن كان لديك Go).
• يؤكّد relayium --version أنه مثبَّت. تخطَّ هذا وستطبع الأوامر أدناه ‘command not found’ لا غير.

‏daemon direct: التحدّث إلى خادم تشغّله أصلًا

حيث يضيف CLI في Relayium مساحة حقيقية هو خارج حالة رمز الاقتران لمرة واحدة: طريقة إضافية لنقل الملفات تعتمد على بنية تحتية تملكها أصلًا، وهو ما لا يحاول magic-wormhole تغطيته.

ملاحظة تاريخية: كان هذا القسم يشرح عمليات النقل عبر SSH في Relayium — أي push أو sync إلى وجهة بصيغة user@host:path، وrelayium pull، والخيارين -i و-p. وقد أوقف CLI الحالي هذه العمليات ويرفضها برسالة «SSH transfers are currently disabled»، لذا لم تعد الأوامر التي كانت هنا تعمل ولم تعد معروضة. بين جهازين تديرهما، استخدم relayium serve مع push أو sync إلى relayium://host؛ وتشرح النسختان الإنجليزية والصينية المبسّطة المُحدَّثتان من هذه الصفحة، المرتبطتان في أعلاها، الخطوات الحالية.

يحوّل relayium serve أي جهاز تملكه إلى هدف daemon direct، يمكن الوصول إليه عبر TLS 1.3 مثبَّت بلا SSH وبلا رمز اقتران — تُبنى الثقة عند الاتصال الأول (يُوافَق عليه تفاعليًا، أو يُصرَّح به مسبقًا للاستخدام غير المراقَب) وتبقى مثبَّتة بعد ذلك، وهي الفكرة نفسها مثل مفتاح مضيف SSH.

relayium authorize <sender-fingerprint>

relayium serve --dir ~/incoming

relayium push ./build relayium://your-server

مزامنة المجلدات وخادم قابل للاستضافة الذاتية

يرسل magic-wormhole دفعة من الملفات (أو مجلدًا مضغوطًا) ثم يخرج — أرسِلها مجددًا لتحديث الطرف الآخر، بلا أي مفهوم لما ينبغي حذفه. يضيف CLI في Relayium الأمر relayium sync، وهو مرآة تزايدية أحادية الاتجاه فوق daemon direct: ينقل فقط ما تغيّر، ويحذف --delete الملفات على الوجهة التي اختفت من المصدر (لا يحترم ذلك daemon إلا إن بُدئ بـ --allow-delete، فعلى المستقبِل أن يوافق صراحةً)، ويبقي --watch على إعادة المزامنة فورًا كلما تغيّرت الملفات، بلا حاجة إلى مهمة cron.

خادم Relayium قابل أيضًا للاستضافة الذاتية كحاوية Docker واحدة إن أردت تشغيل كل شيء بنفسك بدل الاعتماد على relayium.com؛ وجّه إليه CLI باستخدام --server.

relayium sync ./photos relayium://your-server --delete --watch

مقارنة الميزات في لمحة

أهمّ الفروق، جنبًا إلى جنب:

• لا مسار مباشر متاح: يستطيع كلاهما الترحيل — فمُرحِّل magic-wormhole ومُرحِّل Relayium المُشفَّر (كلما أصدره الخادم للرمز، ويُحتسب ضمن حصة حركة البيانات الشهرية للحساب الذي أنشأ الرمز) يحملان التدفّق المُشفَّر فيكتمل النقل.
• التحدّث إلى خادم: يستخدم Relayium ‏daemon بـ TLS مثبّت (serve وpush/sync)، وقد أُوقف نقل SSH القديم (push/pull). أمّا magic-wormhole فيتطلب تثبيته على الطرفين ومشاركة عبارة رمزية.
• مزامنة المجلدات: يعكس relayium sync تزايديًا مع --delete و --watch؛ أما magic-wormhole فيرسل دفعة (أو مجلدًا مضغوطًا) ثم يخرج، بلا دلالات مرآة أو حذف.
• التحقق: كلاهما مشفَّر من الطرف إلى الطرف؛ ويعرض send/receive في Relayium إضافةً رمز SAS قصيرًا يقارنه الطرفان قبل بدء النقل.
• الاستضافة الذاتية: خادم Relayium صورة Docker واحدة تستطيع تشغيلها بنفسك، تخدم CLI وتطبيق المتصفح معًا؛ ويمكن لـ send/receive في CLI التوجّه إليه بـ --server.
• الترخيص والتكلفة: كلاهما مجاني ومفتوح المصدر. لا يحتاج magic-wormhole حسابًا إطلاقًا، أما Relayium فيحتاجه لـ send فقط، كي يُصدر رمز الاقتران.