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