ARCHITECTURE

สถาปัตยกรรมทางเทคนิค

Flutter ข้ามแพลตฟอร์ม, Firebase แบ็คเอนด์ และ Signal Protocol E2EE พร้อมวิทยาการเข้ารหัสโพสต์ควอนตัม

02 / 06

Mesh Network · BLE Offline

อยู่นอกเครือข่าย? ยังคงเชื่อมต่อ

BLE offline P2P ทำให้บทสนทนา 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 ข้อมูลเชิงลึก และมุมมอง — ประมวลผลบนอุปกรณ์ทั้งหมด พร้อมสรุป AI ทันทีสำหรับ URL ผ่าน 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