الإرسال نصف القصة فقط — عاجلًا أم آجلًا ستكون أنت في الطرف المُستقبِل: زميل يريد أن يسلّمك ملفًا عبر الإنترنت، أو أحد أجهزتك يريد أن يمرّره إلى آخر، أو تريد أن تمدّ يدك وتجلب شيئًا من خادم تديره. يغطي 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: شخص يرسل إليك ملفًا عبر الشبكات
هذا هو نصف الاستقبال من relayium send. يشغّل الطرف الآخر relayium send <path> من جهته (بعد relayium login)، فتُصدر واجهة CLI لديه رمزًا من 6 محارف صالحًا لـ 5 دقائق وتطبعه. ثم يخبرك به عبر أي قناة تثقان بها كلاكما — مكالمة، رسالة محادثة. تشغّل أنت receive بذلك الرمز:
relayium receive K7M4XR
# أو إلى مجلد محدد
relayium receive K7M4XR ./downloads
الاتصال مباشر ومن الند للند ومشفَّر من الطرف إلى الطرف؛ يطبع الطرفان الرمز SAS نفسه (سلسلة المصادقة القصيرة) بمجرد الاتصال — قارنه مع المُرسِل لتتأكد ألا أحد في المنتصف.
بلا وجهة محددة: تصل الملفات إلى المجلد الحالي.
القاعدة نفسها كما في send، الاتصال المباشر فقط: إن لم يُعثر على مسار مباشر بين الشبكتين، يفشل النقل بدل توجيهه عبر مُرحِّل.
هذا هو بروتوكول رمز الاقتران في الـ CLI — ورموز CLI تقترن بـ CLI فقط. لا يتوافق اليوم مع رمز اقتران المتصفح أو تدفق QR في relayium.com؛ ذلك إضافة مستقبلية محتملة، لا شيء تعتمد عليه بعد. إن لم يكن لديك سوى متصفح، اطلب من المُرسِل رابط تنزيل عبر relayium up بدلًا من ذلك.
المُستقبِل لا يحتاج حسابًا أبدًا، على أي شبكة. المُرسِل وحده هو من يسجّل الدخول، كي تتمكن واجهة CLI لديه من إصدار الرمز.
serve: حوّل هذا الجهاز إلى صندوق وارد مُستمِع
يعمل serve بالعكس: بدل أن تمدّ يدك أنت، تدفع أجهزة أخرى إليك مباشرةً عبر relayium:// — مصمَّم للأجهزة التي تثق بها أصلًا، مثل حاسوبك المحمول يدفع إلى NAS، أو خادم بناء يُسقط منتجاته على جهاز تملكه — عبر اتصال TLS 1.3 مثبَّت، بلا SSH وبلا تعارف.
أول مرة يدفع إليك جهاز جديد، يعرض 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 الموجود لديك وتجلب الملفات.
على عكس push، يحتاج pull دائمًا إلى relayium مثبَّتًا أصلًا على الجهاز البعيد — لا يوجد بديل tar للسحب من خادم عارٍ. إن لم يكن موجودًا هناك بعد، ثبّته أولًا بـ curl -fsSL https://relayium.com/install.sh | sh.
تُتحقَّق الملفات بفحص SHA-256 لكل ملف وتستأنف تلقائيًا إذا انقطعت (أضف --no-resume لتعطيل ذلك).
-i و -p تتصرفان مثل -i/-p الخاصتين بـ ssh نفسه، لملف هوية أو منفذ محدد.
الأسئلة الشائعة
هل أحتاج حسابًا لاستقبال الملفات؟
لا. الطرق الثلاث جميعها — 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.