ثلاثة مكوّنات، هدف واحد
من الداخل، بُني Timmy بطريقة عملية جدًا: Flutter للتطبيق، WebRTC للصوت والفيديو في الوقت الفعلي، و Firebase للتنسيق. لم أرد بناء منصة ضخمة تمرر كل شيء عبر السحابة. يجب أن يعرف كل جزء أقل قدر ممكن، وأن يعمل مع الأجزاء الأخرى بشكل موثوق.
WebRTC: اتصال مباشر وتشفير افتراضي
تنقل WebRTC (Web Real-Time Communication) الصوت والفيديو بين جهاز الطفل وجهاز الوالد. وفي أفضل الحالات، تتدفق البيانات مباشرة بين الجهازين، من نظير إلى نظير، من دون خادم وسائط بينهما.
يستخدم كل اتصال WebRTC بروتوكول DTLS-SRTP افتراضيًا. فإذا التقط شخص ما حزم الشبكة، فلن يتمكن من فهم الصوت أو مشاهدة الفيديو. وهذا التشفير جزء من البروتوكول ولا يمكن تعطيله ببساطة في WebRTC.
كانت هذه النقطة مهمة بالنسبة لي: وسائط غرفة الطفل لا مكان لها على خادمي. تبقى بين أجهزتكم.
الإشارات عبر Firebase Firestore
قبل أن يبدأ WebRTC، تحتاج الأجهزة إلى العثور على بعضها والتفاوض على طريقة الاتصال. يُسمّى هذا الجزء تبادل الإشارات؛ ويستخدم Timmy لهذا الغرض Firebase Firestore، وهي قاعدة بيانات سحابية من Google.
لا يتم تبادل سوى بيانات الاتصال التقنية:
- عروض وردود SDP: تصف إمكانات الأجهزة، مثل برامج الترميز والدقات المدعومة وغيرها.
- مرشحو ICE: مسارات الشبكة المحتملة التي يمكن للأجهزة من خلالها الوصول إلى بعضها.
لا يصل الصوت أو الفيديو إلى Firebase؛ إذ لا ينقل Firestore سوى بيانات الاتصال التقنية. ويشفّر Timmy طبقة تبادل الإشارات هذه أيضًا، كي لا تصبح بيانات SDP وICE متاحة بنص غير مشفّر عبر Firestore.
خوادم TURN: عندما لا ينجح المسار المباشر
تحظر بعض الشبكات الاتصالات المباشرة، مثل جدران الحماية الصارمة أو بعض شركات الاتصالات المحمولة. عندها يحتاج WebRTC إلى خادم ترحيل TURN (Traversal Using Relays around NAT).
يحاول Timmy استخدام خادم TURN المحلي أولًا، ثم يستخدم Cloudflare كخيار احتياطي إذا لم يكن الترحيل المحلي متاحًا أو كان مثقلًا. يمرر الترحيل حزمًا مشفّرة، ولا يحصل على مفاتيح الصوت أو الفيديو؛ يظل تشفير WebRTC سليمًا.
تأتي بيانات اعتماد TURN من Firebase Cloud Function، وتبقى صالحة لمدة 24 ساعة فقط. بيانات الاعتماد الدائمة في تطبيق لمراقبة الطفل ستكون مخاطرة كبيرة جدًا بالنسبة لي.
الاتصالات القريبة: تعثر الأجهزة على بعضها تلقائيًا
لتجنّب خطوات الإعداد المربكة بين جهاز الطفل وجهاز الوالد، يستخدم Timmy Nearby Connections. توفر Google طبقة الاكتشاف هذه عبر Bluetooth وWiFi.
الإقران التلقائي في Timmy يعمل من دون إدخال رمز يدويًا: تكتشف الأجهزة بعضها وتجد نقطة الالتقاء نفسها لتبادل المفاتيح. وإذا فشل ذلك، يتوفر رمز من 4 خانات يمكنك إدخاله. لا يغادر رمز الإقران الجهاز أبدًا؛ لا يرى Firestore سوى قيمة تجزئة تشفيرية (SHA-256) تُستخدم معرّفًا للمستند.
المصادقة مجهولة الهوية
يستخدم Timmy المصادقة المجهولة من Firebase. عند التشغيل لأول مرة، يحصل كل جهاز على معرّف مؤقت ومجهول. لا يوجد حساب ولا عنوان بريد إلكتروني ولا كلمة مرور. هذا المعرّف موجود فقط لفرض قواعد Firestore: لا يمكن إلا للأجهزة المصادَق عليها قراءة بيانات الجلسة أو كتابتها.
البنية: من يرسل ومن يستقبل
لدى Timmy وضعان:
- وضع الطفل (المرسل): يلتقط الجهاز الصوت عبر الميكروفون ويرسله إلى جهاز الوالد عبر WebRTC. ويمكن تشغيل الكاميرا اختياريًا؛ وعندها يُرسل الفيديو مباشرة أيضًا.
- وضع الوالد (المستقبِل): يتلقى الجهاز الصوت والفيديو، ويعرض بث الكاميرا، ويتيح التحدث بالضغط لإرسال رسائل صوتية قصيرة إلى جهاز الطفل.
تستخدم عناصر التحكم، مثل التحدث بالضغط وتشغيل الكاميرا أو إيقافها، DataChannel، وهي قناة WebRTC أخرى ترسل رسائل صغيرة مشفّرة مباشرة بين الأجهزة.
لماذا Flutter؟
Flutter هو إطار عمل من Google لتطوير التطبيقات على منصات متعددة. وبالنسبة إلى Timmy، يعني ذلك أنني أستطيع كتابة جزء كبير من منطق التطبيق مرة واحدة واستخدامه على Android وiOS. يتوفر Timmy على Android، واقترب إطلاق إصدار iOS. وكلما قلّ تكرار الشيفرة، قلّت المواضع التي قد تتسلل منها الأخطاء.
الخلاصة
القاعدة التقنية بسيطة: يجب أن يتعامل Timmy فقط مع البيانات التي يحتاجها فعلًا. تحمي WebRTC الوسائط، وينسق Firebase إعداد الاتصال، ولا يرى TURN إلا الحزم المشفّرة، وتزيل Nearby Connections التعقيد من الإقران.
تندمج التقنية الجيدة بسلاسة في الحياة اليومية. فهي تعمل من دون أن تحوّل غرفة الطفل إلى مشروع سحابي.