ARCHITECTURE

الهندسة المعمارية التقنية

عميل Flutter متعدد المنصات، خلفية Firebase، وتشفير Signal Protocol E2EE مع تشفير ما بعد الكم.

02 / 06

Mesh Network · BLE Offline

خارج الشبكة؟ لا تزال متصلاً.

تُبقي شبكة BLE الند للند دون اتصال محادثاتك المشفرة E2EE حية حتى عند فشل الإنترنت وشبكات الهاتف المحمول. بديل حقيقي للكوارث والرقابة والبنية التحتية المُحمّلة.

NO INTERNET. NO PROBLEM.

📡 لا يوجد إنترنت

🔋 BLE ACTIVE

🔒 E2EE

أنت

المكدس التقني

Layer	Technology
Client	Flutter 3.44 + Dart
State Management	Riverpod 3.0 (AsyncNotifier / Generator)
Backend	Firebase (Firestore / Auth / Storage / FCM) + GCP
PreKey Server	Elixir/Phoenix (Cloud Run, europe-west1) — Firestore transaction-based atomic PreKey consumption
Mesh Network	Bridgefy BLE SDK
Cryptography	Arc Protocol (libsignal-client Rust FFI): PQXDH (X25519 + ML-KEM-1024), XEdDSA signatures, Sender Key (Group)
Local Database	Hive (NoSQL, type-safe)
Key Storage	FlutterSecureStorage (Keychain / Keystore / Web Crypto API)
Image Cache	CachedNetworkImage

PreKey Server — Elixir/Phoenix

Dedicated server for atomic PreKey consumption during Signal Protocol session establishment. Built with Elixir/Phoenix on Cloud Run (europe-west1), optimized for EMEA users.

Elixir 1.19

Erlang/OTP 28 · BEAM VM

Phoenix 1.8

API only · Bandit HTTP

Cloud Run

europe-west1 · EMEA

Firestore

REST API · eur3 multi-region

Rust (libsignal)

PQXDH · XEdDSA · Sender Key

Flutter 3.44

iOS · Android · macOS · Web

خط أنابيب تشفير E2EE

Phase 1: PQXDH (Post-Quantum Extended Diffie-Hellman)
  IKa(X25519) × SPKb(X25519) → DH1
  EKa(X25519) × IKb(X25519) → DH2
  EKa(X25519) × SPKb(X25519) → DH3
  EKa(X25519) × OPKb(X25519) → DH4
  EKa(ML-KEM-1024) → PQ encapsulate → ss_pq
  HKDF(DH1 ‖ DH2 ‖ DH3 ‖ DH4 ‖ ss_pq) → Root Key

Phase 2: Double Ratchet
  Root Key → Chain Key → Message Key (per message)
  DH Ratchet: New X25519 key pair per exchange
  Symmetric Ratchet: KDF chain for sequential messages

Phase 3: AES-256-GCM
  Message Key → AES-256-GCM encrypt(plaintext)
  12-byte random IV per message
  Authentication tag for integrity

Phase 4: AEGIS (XEdDSA Signature via libsignal)
  Sign(senderId ‖ timestamp ‖ content) → signature
  XEdDSA: Identity Key (X25519) doubles as signing key

Phase 5: Sealed Sender
  Generate ephemeral X25519 key pair
  ECDH with recipient → HKDF-SHA256 → AES key
  Encrypt(senderId ‖ ciphertext) → sealed message

Group Encryption (ECIES + AES-256-GCM)

Key Distribution (per member):
  GroupKey(AES-256) → ECIES encrypt(member.publicKey) → Firestore

Message Encryption:
  AES-256-GCM(groupKey, plaintext, AAD = senderId ‖ groupId ‖ timestamp)

Key Retrieval (fast path):
  Memory Cache → SecureStorage → Firestore ECIES decrypt

O(N) key distribution, O(1) message encryption. Each member receives the group key encrypted with their public key via ECIES. Messages are encrypted once with AES-256-GCM using Additional Authenticated Data (AAD) for integrity.

E2EE Protection Across All App States

Messages are decrypted immediately upon receipt and cached in persistent storage, ensuring E2EE protection regardless of app state — foreground, background, or terminated.

App State	1:1 Chat	Group Chat	Mechanism
Chat screen active	✅	✅	StreamBuilder decrypt → LRU + SentMessageCache
Foreground (other screen)	✅	✅	FCM pre-decrypt → SentMessageCache
Pre-session reset	✅	N/A	Pre-decrypt before ratchet reset
Background / Terminated	✅	✅	SharedPreferences queue → bulk decrypt on resume

هندسة الأجهزة المتعددة

Device 1 (e.g., iPhone)

[X25519] Identity Key
[Ed25519] Signing Key
[X25519] Signed PreKey
[X25519] OTPKs x 100
[ML-KEM-1024] PQ PreKey
Independent Double Ratchet sessions

Device 2 (e.g., macOS)

[X25519] Identity Key
[Ed25519] Signing Key
[X25519] Signed PreKey
[X25519] OTPKs x 100
[ML-KEM-1024] PQ PreKey
Independent Double Ratchet sessions

Device List Signing: Ed25519 signature on deviceListV1:{sorted_ids}:{timestamp} for tamper detection. No session sharing between devices.

Mesh Network (BLE أوفلاين E2EE)

[Device A] ──BLE── [Device B] ──BLE── [Device C] ──Multi-hop── [Device D]
   100m radius         100m radius         100m radius

Parameter	Value
Direct P2P	BLE 100m radius
Multi-hop	N relay x 100m
Protocol	Bridgefy SDK
Encryption	X3DH + Double Ratchet + AES-256-GCM
Offline	Store & Forward queue
Use Case	Disaster, winery fields, remote areas

architecture.ondeviceTitle

architecture.ondeviceDesc

Rosetta

Offlineقريبًا

architecture.rosettaDesc

Model: Gemma 4 (TranslateGemma)
Languages: 55
Processing: 100% on-device
Data leakage: zero

Pet Companion

Offlineقريبًا

architecture.petDesc

Model: Gemma 4 (4B parameters)
Storage: Hive (TypeID 96-97)
Processing: 100% on-device
Server communication: none

SUM

Offlineقريبًا

قم بتحميل ملفات PDF والعروض التقديمية والمستندات للحصول على ملخصات مدعومة بالذكاء الاصطناعي، ورؤى عميقة، ووجهات نظر — تتم معالجتها بالكامل على الجهاز. بالإضافة إلى ملخصات AI فورية للروابط عبر Gemini. ميزة خطة Intelligence.

Model: Gemma 4 (planned)
Input: PDF / DOCX / PPTX
Processing: 100% on-device
Plan: Intelligence

4-Pillar Vision:
  🛡️ DefenseTech     ─── Online: E2EE (PQXDH + ML-KEM-1024) + AEGIS + Sealed Sender
  📡 DisasterTech    ─── Offline: BLE Mesh + additional encryption layers
  🌍 Language Bridge ─── Offline: Gemma 4 (TranslateGemma) on-device translation
  🐾 AI Pet         ─── Offline: Gemma 4 companion, zero server communication

Model Pipeline:
  Firestore config → Download check → Ad gate → Model download → Hive cache
  User input → On-device inference (Gemma 4) → Result → No data leaves device

دورة حياة المفاتيح والتدوير

Key Type	Rotation	Purpose
Identity Key (X25519)	Account lifetime	Core identity
Signing Key (Ed25519)	90 days + grace period	AEGIS message signatures
Signed PreKey (X25519)	7-30 days	X3DH handshake
One-Time PreKeys (X25519)	Single use	Forward secrecy per session
PQ PreKey (ML-KEM-1024)	Account lifetime	Post-quantum key encapsulation
Double Ratchet Keys	Per message exchange	Per-message forward secrecy