שלוש אבני בניין, מטרה אחת
מאחורי הקלעים, 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 גם מצפין את שכבת האיתות הזו, כך ש-Firestore לא הופך לנקודת מפגש בטקסט גלוי עבור SDP ו-ICE.
שרתי TURN: כשנתיב ישיר לא עובד
חלק מהרשתות חוסמות חיבורים ישירים, למשל חומות אש מחמירות או מפעילים סלולריים מסוימים. במצב כזה WebRTC זקוק ל- ממסר TURN (Traversal Using Relays around NAT).
Timmy מנסה קודם את שרת ה-TURN המקומי, ומשתמש ב-Cloudflare כגיבוי כשהממסר המקומי אינו זמין או עמוס מדי. הממסר מעביר חבילות מוצפנות. אין לו מפתחות לקול או לווידאו; הצפנת WebRTC נשארת שלמה.
פרטי הגישה ל-TURN מגיעים מפונקציית ענן של Firebase ותקפים ל-24 שעות בלבד. פרטי גישה קבועים באפליקציית מוניטור תינוק היו מסוכנים מדי לטעמי.
חיבורים בקרבת מקום: המכשירים מוצאים זה את זה אוטומטית
כדי להימנע משלבי הגדרה מסורבלים בין מכשיר התינוק למכשיר ההורה, Timmy משתמש ב- Nearby Connections. Google מספקת את שכבת הגילוי הזו באמצעות Bluetooth ו-Wi‑Fi.
הצימוד האוטומטי ב-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 הופך את הצימוד לפשוט יותר.
טכנולוגיה טובה קצת נעלמת בתוך חיי היומיום. היא פשוט עובדת, בלי להפוך את חדר התינוק לפרויקט ענן.