ARCHITECTURE

Architektura techniczna

Wieloplatformowy klient Flutter, backend Firebase oraz Signal Protocol E2EE z kryptografią postkwantową.

02 / 06

Mesh Network · BLE Offline

Bez sieci? Wciąż połączeni.

BLE offline P2P utrzymuje twoje rozmowy E2EE nawet wtedy, gdy internet i sieci komórkowe zawiodą. Realny zapas na klęski żywiołowe, cenzurę i przeciążoną infrastrukturę.

NO INTERNET. NO PROBLEM.

📡 BRAK INTERNETU

🔋 BLE ACTIVE

🔒 E2EE

Stos technologiczny

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

Pipeline szyfrowania 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

Architektura wielu urządzeń

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 Offline 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

OfflineJuż wkrótce

architecture.rosettaDesc

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

Pet Companion

OfflineJuż wkrótce

architecture.petDesc

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

SUM

OfflineJuż wkrótce

Przesyłaj PDF, prezentacje i dokumenty, aby uzyskać streszczenia oparte na AI, głębokie wglądy i perspektywy — przetwarzane całkowicie na urządzeniu. Plus natychmiastowe streszczenia AI dla URL przez Gemini. Funkcja planu 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

Cykl życia i rotacja kluczy

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