استقبال الملفات من سطر الأوامر

آخر تحديث: 2026-09-01

الإرسال نصف القصة فقط — عاجلًا أم آجلًا ستكون أنت في الطرف المُستقبِل: زميل يريد أن يسلّمك ملفًا عبر الإنترنت، أو أحد أجهزتك يريد أن يمرّره إلى آخر، أو تريد أن تمدّ يدك وتجلب شيئًا من خادم تديره. يغطي Relayium CLI الحالات الثلاث بأمر مختلف لكلٍّ منها، ولا واحدة منها تحتاج حسابًا.

اختر receive حين يدفع إليك شخص آخر برمز اقتران، وserve حين تريد صندوق وارد دائمًا تستطيع الأجهزة الموثوقة الدفع إليه في أي وقت، وpull حين تكون أنت من يمدّ يده إلى خادم يمكنك أصلًا تسجيل الدخول إليه عبر ssh.

ثلاث طرق للاستقبال، ومتى تنطبق كل منها

الأمر الذي تشغّله يعتمد على من يبدأ النقل وكيف يعرف الجهازان أحدهما الآخر:

‏‎relayium receive <code> [destdir]‎ — يرسل إليك شخص عبر الشبكات باستخدام رمز اقتران أصدرته واجهة CLI لديه ثم أبلغك به خارج القناة. من الند للند مباشرةً، مع رمز SAS يمكنك مقارنته.
‏‎relayium serve [--dir D] [--port N] [--once] [--allow-delete]‎ — يستمع هذا الجهاز لعمليات الدفع daemon direct عبر relayium://، على المنفذ 9031 افتراضيًا.
‏‎relayium pull [user@]host:src <dest>‎ — تمدّ يدك عبر SSH إلى خادم يمكنك أصلًا تسجيل الدخول إليه وتجلب الملفات.

receive: شخص يرسل إليك ملفًا عبر الشبكات

ما تحتاجه قبل الخطوة 1

الـ CLI على هذا الجهاز. يطبع relayium version سطر إصدار، وإذا ردّت الصدفة بـ command not found فهو غير مثبَّت هنا بعد.
مرسِل مسجَّل الدخول وجالس أمام طرفيته الآن. وهو وحده من يحتاج حسابًا — أما أنت فلا تسجّل الدخول للاستقبال إطلاقًا.
الأرقام الستة، تصلك عبر قناة خارجة عن المسار. وهي تعيش خمس دقائق من لحظة توليد الـ CLI لديه لها، فاتفقا على اللحظة أولًا.
وسيلة تقرأ بها ستة أرقام أخرى عليه بعد ذلك: فالـ SAS يُقارَن نطقًا لا على الشاشة.
أن يكون الطرف الآخر هو الـ CLI. فالمتصفح لا يستطيع الانضمام إلى رمز اقتران خاص بالـ CLI — وإن كان المتصفح كل ما لديك فاطلب رابط relayium up بدلًا منه.

هذا هو نصف الاستقبال من relayium send. يشغّل الطرف الآخر ‎relayium send <path>‎ من جهته (بعد relayium login)، فتُصدر واجهة CLI لديه رمزًا من 6 أرقام صالحًا لـ 5 دقائق وتطبعه. ثم يخبرك به عبر أي قناة تثقان بها كلاكما — مكالمة، رسالة محادثة. تشغّل أنت receive بذلك الرمز:

relayium receive 483920

# أو إلى مجلد محدد
relayium receive 483920 ./downloads

اتفق مع المرسِل على موعد تشغيله لـ send. فالرمز يبدأ بالانتهاء من لحظة توليده لا من لحظة وصوله إليك.
خذ الأرقام الستة عبر قناة يثق بها كلاكما — مكالمة، أو نافذة محادثة، أو الغرفة التي تجلسان فيها.
شغّل receive من الدليل الذي يُفترض أن تصل إليه الملفات، أو سمِّ دليلًا صراحةً.
```
relayium receive 483920
```
```
relayium receive 483920 ./downloads
```
حين تطبع الطرفيتان رمز تحقّق، اقرأ رمزك بصوت مسموع وتأكّد أنه يطابق رمزه. إنه ليس رمز الاقتران، وهو الشيء الوحيد الذي يستبعد استبدال الطرف المقابل.
اترك الطرفية وشأنها حتى تعود إلى المحث. فهذه جلسة حيّة واحدة: إغلاق أي طرف يوقف النقل.

كيف يبدو استقبال ناجح

يُعلَن الاتصال بأنه direct، وتطبع الطرفيتان رمز التحقّق نفسه. واختلاف الرمزين هو النتيجة الوحيدة التي يجب ألّا تقبلها — توقّف وتحقّق مع المرسِل من الجهاز الذي يجلس عليه.

$ relayium receive 483920
verification code (SAS): 271044 — not the pairing code; compare it on both ends to rule out a substituted endpoint
path: direct

الاتصال مباشر ومن الند للند ومشفَّر من الطرف إلى الطرف؛ يطبع الطرفان الرمز SAS نفسه (سلسلة المصادقة القصيرة) بمجرد الاتصال. قارنه مع المُرسِل خارج القناة لتأكيد أن بصمات شهادات TLS المثبّتة لم تُستبدل وأن خدمة الالتقاء لم تنتحل شخصية أي طرف. يصادق SAS على الطرفين؛ ولا يثبت كل قفزة في مسار الشبكة.
بلا وجهة محددة: تصل الملفات إلى المجلد الحالي.
القاعدة نفسها كما في send، الاتصال المباشر فقط: إن لم يُعثر على مسار مباشر بين الشبكتين، يفشل النقل بدل توجيهه عبر مُرحِّل.
هذا هو بروتوكول رمز الاقتران في الـ CLI — ورموز CLI تقترن بـ CLI فقط. لا يتوافق اليوم مع رمز اقتران المتصفح أو تدفق QR في relayium.com؛ ذلك إضافة مستقبلية محتملة، لا شيء تعتمد عليه بعد. إن لم يكن لديك سوى متصفح، اطلب من المُرسِل رابط تنزيل عبر relayium up بدلًا من ذلك.
المُستقبِل لا يحتاج حسابًا أبدًا، على أي شبكة. المُرسِل وحده هو من يسجّل الدخول، كي تتمكن واجهة CLI لديه من إصدار الرمز.

serve: حوّل هذا الجهاز إلى صندوق وارد مُستمِع

يعمل serve بالعكس: بدل أن تمدّ يدك أنت، تدفع أجهزة أخرى إليك مباشرةً عبر relayium:// — مصمَّم للأجهزة التي تثق بها أصلًا، مثل حاسوبك المحمول يدفع إلى NAS، أو خادم بناء يُسقط منتجاته على جهاز تملكه — عبر اتصال TLS 1.3 مثبَّت، بلا SSH وبلا تعارف.

relayium serve

# مجلد ومنفذ محددان، مع السماح بطلبات الحذف
relayium serve --dir ~/incoming --port 9031 --allow-delete

شغّل المُنصِت مع تسمية الدليل الذي ستصل إليه الدفعات.
```
relayium serve --dir ~/incoming
```
عند أول دفعة من جهاز جديد، يعرض serve عنوانه وبصمته ويسألك. وافق مرة واحدة، فتمر الدفعات التالية من البصمة نفسها بصمت.
إن كان هذا المُنصِت سيعمل بلا طرفية، فلا تعتمد على ذلك السؤال — لا أحد هناك ليجيب عنه، والمرسِل غير المعروف يُرفَض من فوره. استخدم بدلًا من ذلك التصريح المسبق الموصوف في القسم التالي.

أول مرة يدفع إليك جهاز جديد، يعرض serve (عند تشغيله في طرفية) عنوانه وبصمته ويطلب منك الموافقة عليه مرة واحدة؛ بعد ذلك تمر عمليات الدفع من البصمة نفسها بصمت.
بلا طرفية — خدمة systemd، برنامج نصي بلا TTY — لا أحد ليُسأل، فيُرفض الطرف الدافع غير المعروف فورًا. بدلًا من ذلك، امنحه الإذن مسبقًا باستخدام البصمة التي يطبعها الطرف الدافع بـ relayium id:

منح الإذن مسبقًا لـ serve دون إشراف

لتشغيل serve دون إشراف (systemd، برنامج نصي في الخلفية)، اجعل الطرف الدافع يشغّل relayium id لطباعة بصمته، ثم امنحها الإذن مسبقًا من جهة الاستقبال:

relayium authorize <fingerprint>

‏--dir يحدّد أين تصل الملفات (الافتراضي هو المجلد الحالي)؛ ‏--once يقبل نقلًا واحدًا ثم يخرج؛ ‏--allow-delete يتيح لطلب --delete (المرآة) الوارد أن يزيل الملفات فعلًا هنا، وهو معطّل افتراضيًا.
‏--config-dir (الافتراضي ~/.config/relayium) هو مكان هوية هذا المضيف وقائمة بصماته المُصرَّح بها — تجاوزه إن كنت تشغّل serve كخدمة مخصّصة.

pull: مدّ يدك واجلب من خادم يمكنك تسجيل الدخول إليه عبر ssh

‏pull هو مرآة push: بدل انتظار أن يرسل إليك أحد شيئًا، تمدّ يدك عبر وصول SSH الموجود لديك وتجلب الملفات.

relayium pull user@host:/path/to/files ./local-dest

تأكّد أن الجهاز البعيد يملك الـ CLI فعلًا. فـ pull يشغّل relayium على الطرف البعيد، وخلافًا لـ push لا يوجد بديل احتياطي عبر tar، فغياب الثنائي يُفشل الأمر كله.
```
ssh user@host command -v relayium
```
إن كان غائبًا، ثبّته هناك أولًا.
```
curl -fsSL https://relayium.com/install.sh | sh
```
اسحب الملفات عبر وصول SSH الذي تملكه أصلًا. وتتصرّف ‎-i‎ و‎-p‎ تمامًا كنظيرتيهما في ssh.
```
relayium pull user@host:/path/to/files ./local-dest
```

على عكس push، يحتاج pull دائمًا إلى relayium مثبَّتًا أصلًا على الجهاز البعيد — لا يوجد بديل tar للسحب من خادم عارٍ. إن لم يكن موجودًا هناك بعد، ثبّته أولًا بـ curl -fsSL https://relayium.com/install.sh | sh.
تُتحقَّق كل ملف بفحص SHA-256 لكل ملف. ولا يستأنف pull: فهو يرفض وجهة موجودة سلفًا، مسبقًا وقبل جلب أي شيء. وإذا انقطع السحب، أكمِله بجلب المسارات الناقصة أو باستخدام relayium sync في الاتجاه نفسه. و‏--no-resume مقبول هنا ولا يفعل شيئًا.
‏-i و -p تتصرفان مثل -i/-p الخاصتين بـ ssh نفسه، لملف هوية أو منفذ محدد.

حين لا ينجح الأمر

خمسة إخفاقات تغطي تقريبًا كل استقبال فاشل. والأمر الذي كنت تشغّله يحدّد أيها ينطبق، ولكلٍّ منها سطر تقرؤه أو أمر تشغّله يحسم المسألة.

العَرَض، الفحص، الإصلاح

تُدخِل الرمز فيرفضه خادم اللقاء.

relayium receive 483920
# the rendezvous refuses the code

غالبًا انقضت الدقائق الخمس — فالرمز ينتهي ابتداءً من لحظة توليد الـ CLI لدى المرسِل له، لا من لحظة إخبارك به. اطلب منه تشغيل send مرة أخرى وقراءة الأرقام الجديدة عليك فورًا. وخطأ رقم واحد يبدو من هنا مطابقًا تمامًا، فأعد قراءة الرمز عليه قبل أن تفترض أنه انتهى.

يكتمل النقل لكنك لا تجد الملفات.

relayium receive 483920 ./downloads

من دون تحديد وجهة، يكتب receive في الدليل الذي شغّلته منه، وهو نادرًا ما يكون المكان الذي بحثت فيه. حدّد دليلًا صراحةً، أو شغّل pwd أولًا لتتيقّن.

يفشل برسالة «no direct connection to the peer (both ends behind strict NAT?)».

relayium receive 483920
# no direct connection to the peer (both ends behind strict NAT?): …

مسار الاقتران في الـ CLI مباشر فقط بحكم التصميم: فحين لا يوجد طريق مباشر يفشل بدل أن يمرّر ملفك عبر مُرحِّل. ولا شيء من جهتك يصلح ذلك. اطلب من المرسِل رابط تنزيل relayium up بدلًا منه، أو استخدم الاتصال المباشر بين الخادمين أو push عبر SSH بين جهازين تتحكّم فيهما.

يفشل pull فورًا شاكيًا أن relayium غير موجود.

ssh user@host command -v relayium
# (no output)

يشغّل pull أمر relayium على الجهاز البعيد — فهو المرسِل في ذلك التبادل — ولا يوجد بديل احتياطي عبر tar كما في push. ثبّت الـ CLI على الجهاز البعيد أولًا ثم أعد تشغيل pull.

جهاز يدفع إلى مُنصِت serve لديك فيُرفَض دون أن تُسأل قط.

relayium serve --dir ~/incoming

ذلك السؤال لا يوجد إلا حين تكون لـ serve طرفية. أما تحت systemd أو داخل سكربت أو خلف أنبوب فلا أحد ليُسأل، فتُرفَض البصمة المجهولة من فورها. اطلب من المرسِل تشغيل relayium id، وصرّح لها هنا بـ relayium authorize <البصمة>، بالـ ‎--config-dir‎ نفسه الذي يعمل به المُنصِت.

الأسئلة الشائعة

هل أحتاج حسابًا لاستقبال الملفات؟

لا. الطرق الثلاث جميعها — receive وserve وpull — مجانية تمامًا ولا تحتاج حساب Relayium من جهتك. وتسجيل الدخول الوحيد في كل هذا هو تسجيل المُرسِل في وضع receive، كي تتمكن واجهة CLI لديه من إصدار رمز الاقتران.

هل يتوافق relayium receive مع رمز اقتران المتصفح؟

لا. بروتوكول رمز الاقتران في الـ CLI منفصل عن تدفق رابط الانضمام وQR في المتصفح على relayium.com — يستخدمان مصافحات مختلفة ولا يتحدثان أحدهما إلى الآخر اليوم، فرمز الـ CLI لا يقترن إلا بواجهة CLI أخرى. ذلك على خارطة الطريق، لا شيء تعتمد عليه بعد. وإلى أن يحدث ذلك، من يستقبل عبر متصفح يحتاج رابط relayium up لا رمزًا.

ماذا يحدث إذا دفع جهاز غير معروف إلى مُستمِع serve لديّ؟

في الطرفية، يُطلب منك الموافقة عليه بعنوانه وبصمته عند أول دفعة، وتُحفَظ الموافقة. بلا طرفية — خدمة systemd، مهمة cron — لا أحد ليُسأل، فيُرفض الطرف الدافع غير المعروف؛ امنحه الإذن مسبقًا أولًا بـ ‎relayium authorize <fingerprint>‎.

هل يمكنني السحب من خادم لا يوجد فيه relayium مثبَّتًا؟

لا. يحتاج pull دائمًا إلى relayium على الطرف البعيد؛ لا يوجد بديل tar كما في push. ثبّت relayium هناك أولًا.

أين يحفظ relayium هويتي والأقران الموثوقين؟

في ~/.config/relayium افتراضيًا — تجاوز الموقع بـ --config-dir في أي أمر يمسّ الهوية أو الثقة.

مستعد لاستقبال نقلك الأول؟ ثبّت الـ CLI واختر receive أو serve أو pull.

احصل على الـ CLI