# Gemini Advanced Roadmap: Beyond the Basics

Tento dokument obsahuje pokročilé návrhy na vylepšení bezpečnosti, architektury a UX aplikace `encrypted_chat`. Tyto body jdou nad rámec běžného "best practice" a směřují k funkcionalitě profesionálních secure messengerů (Signal, Threema, Wire) se zaměřením na ochranu metadat a anti-forenzní techniky.

---

## 1. Ochrana Metadat & Traffic Analysis Resistance
*Cíl: Server by neměl vědět, KDO s KÝM komunikuje, ani JAKÝ typ dat si posílají.*

### Sealed Sender (Odesílatel v obálce)
- **Koncept:** Server zná pouze `recipient_id`. Identita odesílatele (`sender_id`) je zašifrována uvnitř zprávy (v "obálce"), kterou server nedokáže přečíst.
- **Implementace:**
  1. Odesílatel vygeneruje klíč pro obálku (např. z profilu příjemce).
  2. Zabalí `sender_id` a payload do šifrovaného bloku.
  3. Server doručí blob příjemci bez ověření odesílatele (ověření proběhne až na klientovi po rozbalení).
  4. **Výhoda:** Při kompromitaci serveru útočník nevidí sociální graf (kdo se s kým baví).

### Traffic Padding & Constant Bitrate
- **Problém:** Délka paketu prozrazuje obsah (krátký paket = "Ahoj", dlouhý paket = obrázek/klíč). Intervaly prozrazují aktivitu.
- **Řešení:**
  1. **Padding:** Všechny zprávy doplňovat náhodnými daty na fixní velikosti (např. bloky 4KB).
  2. **Dummy Traffic (Chaff):** Klient náhodně odesílá "falešné" pakety na server, které server zahodí nebo vrátí (echo).
  3. **Výhoda:** Pro síťového analytika (ISP) vypadá tok dat jako konstantní šum.

---

## 2. Anti-Forenzní Ochrana (Client-side)
*Cíl: Minimalizovat dopad fyzického zabavení zařízení nebo vynuceného odemčení.*

### Duress Password (Heslo pod nátlakem)
- **Funkce:** Uživatel si nastaví *druhé* heslo.
- **Chování:** Pokud se přihlásí tímto heslem:
  - **Varianta A (Decoy):** Odemkne se prázdná nebo falešná databáze s neškodnými konverzacemi.
  - **Varianta B (Panic):** Aplikace na pozadí tiše provede **secure wipe** (přepis) privátních klíčů a reálné DB, zatímco uživateli zobrazí "Connection Error".

### Secure Deletion & DB Vacuuming
- **Problém:** SQL `DELETE` data nesmaže fyzicky, jen označí místo jako volné.
- **Řešení:**
  1. Před smazáním zprávy přepsat obsah náhodnými byty (`UPDATE messages SET content = random_blob WHERE id = ...`).
  2. Pravidelně spouštět `VACUUM` (u SQLite) nebo optimalizaci tabulek.
  3. Pro soubory (obrázky) použít bezpečné mazání (overwrite passes) před `os.unlink()`.

### Disappearing Messages (TTL)
- **Funkce:** Odesílatel nastaví životnost zprávy (např. 1 minuta).
- **Implementace:** Odpočet začíná okamžikem zobrazení (Read Receipt). Po uplynutí času klient data nenávratně smaže z disku (včetně secure wipe). Server maže ihned po doručení.

---

## 3. Infrastruktura & Škálování
*Cíl: Odlehčit Python procesu a databázi pro podporu tisíců uživatelů.*

### Object Storage (MinIO / S3) + Presigned URLs
- **Problém:** `server.py` blokuje I/O při příjmu velkých souborů.
- **Řešení:**
  1. Klient požádá server o upload.
  2. Server vygeneruje **Presigned PUT URL** (časově omezený token pro přímý upload do MinIO/S3).
  3. Klient nahrává data přímo do úložiště (obchází aplikační server).
  4. Server ukládá pouze odkaz (URL/Key).
- **Výhoda:** Masivní zrychlení, server řeší jen metadata.

### Read/Write Splitting (MySQL Replication)
- **Architektura:**
  - **Master DB:** Pouze pro `INSERT`, `UPDATE`, `DELETE`.
  - **Read Replicas (Slaves):** Pro těžké `SELECT` dotazy (historie zpráv, hledání).
- **Implementace v `db.py`:** Router, který podle typu dotazu volí connection pool.

---

## 4. Protokol & Funkce
*Cíl: Rozšíření možností komunikace bez nutnosti centralizovaného streamování.*

### P2P Volání (WebRTC Signalizace)
- **Koncept:** Využít existující bezpečný kanál (Double Ratchet) pro výměnu SDP (Session Description Protocol) paketů.
- **Flow:**
  1. Alice pošle Bobovi zašifrovanou zprávu typu `CALL_OFFER` s parametry WebRTC.
  2. Bob odpoví `CALL_ANSWER`.
  3. Klienti si vymění `ICE_CANDIDATES` (IP adresy/porty) a naváží přímé P2P spojení (UDP).
  4. Audio/Video stream (SRTP) jde mimo server.

### Diferenciální Synchronizace (Merkle Trees)
- **Problém:** Stahování seznamu kontaktů (`get_user_contacts`) je pomalé při velkém množství dat.
- **Řešení:** Klient a server si udržují Hash Tree (Merkle Tree) stavu. Při synchronizaci porovnají pouze root hash. Pokud se liší, stahují se jen změněné větve stromu (delta update).

---

## 5. UI/UX (PyQt Speciality)
*Cíl: Ochrana soukromí na úrovni OS a skrytá komunikace.*

### Privacy Overlay (Task Switcher)
- **Funkce:** Detekovat událost ztráty fokusu okna (`QEvent.WindowDeactivate`) nebo minimalizace.
- **Akce:** Překrýt obsah okna rozmazaným efektem (`QGraphicsBlurEffect`) nebo logem aplikace.
- **Důvod:** Zabrání operačnímu systému (Windows/Linux/macOS) vytvořit čitelný náhled okna v Alt+Tab menu nebo v historii aktivit.

### Steganografie
- **Funkce:** Ukrýt šifrovanou zprávu do obrazových dat nevinného obrázku (např. meme kočky).
- **Implementace:** Modifikace LSB (Least Significant Bit) pixelů obrázku.
- **Výhoda:** Pro síťového admina nebo forenzní analýzu to vypadá jako běžné posílání obrázků, přítomnost šifrované komunikace je popiratelná.

---

## 6. High Availability Architecture (Distribuovaný Cluster)
*Cíl: Zajištění provozu i při výpadku/napadení serveru (Active-Active "RAID 1 přes síť").*

### Architektura: Geograficky Distribuovaný "Zero-Trust" Cluster

#### 1. Vstupní brána (Global Traffic Manager)
- **Funkce:** Rozděluje klienty mezi dostupné servery (Round Robin / Geo-DNS).
- **Self-Healing:** Při výpadku Serveru A okamžitě přesměruje provoz na Server B. Uživatel nic nepozná.

#### 2. Aplikační vrstva (Stateless Servers)
- **Stav:** Servery jsou **bezstavové**. `server.py` neukládá nic důležitého v RAM.
- **Škálování:** Můžete spustit N instancí serveru. Je jedno, ke kterému se uživatel připojí.
- **Komunikace:** Servery spolu mluví přes rychlý Message Bus (Redis Pub/Sub) pro doručování real-time zpráv mezi uživateli na různých uzlech.

#### 3. Datová vrstva (Zrcadlení Dat - "RAID 1")
- **Databáze (MySQL Galera Cluster):** Synchronní multi-master replikace. Zápis na Serveru A se potvrdí, až když je fyzicky zapsán i na Serveru B (a C). 
  - *Efekt:* Ztráta serveru neznamená ztrátu dat (klíčů, zpráv).
- **Soubory (MinIO Cluster):** Distribuovaný Object Storage s Erasure Coding. Soubory jsou matematicky rozprostřeny přes všechny servery. Výpadek disku/serveru nevadí.

#### 4. Bezpečnostní pojistky ("Poisoned Node")
- **Soft Delete:** Databáze nemaže data ihned, ale označuje je jako smazané (ochrana proti `DELETE *` od útočníka).
- **Client-Side Verification:** I kdyby kompromitovaný server posílal podvržené klíče, klienti ověřují digitální podpisy (Identity Keys). Server nemůže zfalšovat identitu uživatelů.

---

## 7. Technický Upgrade pro Stateless Architekturu
*Cíl: Odstranit závislost na paměti procesu (RAM) pro umožnění horizontálního škálování.*

### 1. Redis jako Distribuovaná Paměť
Nahrazení Python `dict` struktur, které jsou lokální pro jeden proces, za centrální Redis úložiště přístupné všem serverům.

*   **Párovací Session:**
    *   *Stav:* `pairing_sessions` (dict) -> Redis Key `pair:{code}` (Hash/String s TTL).
    *   *Efekt:* Uživatel může vyžádat kód na Serveru A a potvrdit ho na Serveru B.
*   **Rate Limiting:**
    *   *Stav:* `rate_limits` (dict) -> Redis Key `rl:{ip}:{action}` (Counter s EXPIRE).
    *   *Efekt:* Limity platí globálně pro celý cluster, ne jen per server.

### 2. Redis Pub/Sub pro Real-Time Routing
Doručení zprávy uživateli, který je připojen k JINÉMU serveru než odesílatel.

*   **Princip:**
    1.  Server A (odesílatel) zjistí, že příjemce Bob není připojen lokálně.
    2.  Server A publikuje zprávu do Redis kanálu `user:{bob_user_id}`.
    3.  Server B (kde je Bob připojen) tento kanál poslouchá (subscribe).
    4.  Server B přijme zprávu z Redisu a pošle ji Bobovi do otevřeného TCP socketu.

### 3. Session Sticky vs. Stateless Uploads
Řešení pro nahrávání souborů po částech (chunks).

*   **Varianta A (Infrastructure - Sticky Sessions):** Load Balancer (HAProxy/Nginx) zajistí, že všechny požadavky od jedné IP jdou vždy na stejný server. Nejjednodušší, nevyžaduje změnu kódu.
*   **Varianta B (Architectural - Direct Upload):** Viz bod 3 "Object Storage + Presigned URLs". Server vůbec nepřijímá data souboru, pouze vygeneruje token. Plně stateless řešení.