Architecture

QuietDrop Architecture

This page describes the overall architecture of QuietDrop, its components, and how they interact.

System Overview

QuietDrop now follows a modern architecture with a shared core library and multiple interface options: a CLI for command-line operations and a cross-platform application built with Tauri 2.0 for desktop and mobile devices.

graph TD
    subgraph "QuietDrop System"
        subgraph "Core Library"
            A[Authentication Module] --> Core[quietdrop-core]
            E[Encryption Module] --> Core
            M[Message Module] --> Core
            C[Client Module] --> Core
            S[Server Module] --> Core
        end
        
        subgraph "Interfaces"
            CLI[Command Line Interface] --> Core
            
            subgraph "Tauri Application"
                TA[Tauri Backend] --> Core
                YF[Yew Frontend] <--> TA
                TA --> DP[Desktop Platforms]
                TA --> MP[Mobile Platforms]
            end
        end
        
        Server[Server Instance] <--> CLI
        Server <--> TA
    end
    
    DP --> Windows[Windows]
    DP --> MacOS[macOS]
    DP --> Linux[Linux]
    MP --> Android[Android]
    MP --> iOS[iOS]
    
    Client1[Client 1] <-->|Encrypted Messages| Server
    Client2[Client 2] <-->|Encrypted Messages| Server

Loading

Project Structure

QuietDrop uses a Rust workspace with multiple crates:

graph TD
    W[Workspace] --> Core[quietdrop-core]
    W --> CLI[quietdrop-cli]
    W --> Tauri[quietdrop-tauri]
    
    Core --> A[authentication.rs]
    Core --> E[encryption.rs]
    Core --> M[message.rs]
    Core --> C[client.rs]
    Core --> S[server.rs]
    
    CLI --> main[main.rs]
    
    Tauri --> Frontend[Yew Frontend]
    Tauri --> Backend[Tauri Backend]
    
    Frontend --> Components[UI Components]
    Frontend --> Services[Service Layer]
    
    Backend --> Commands[Tauri Commands]
    Backend --> Handlers[Event Handlers]

Loading

Core Components

Authentication Module (authentication.rs)

Handles user authentication and password security:

• Password hashing using Argon2id algorithm
• Salt generation and management
• Password verification

// Key functions
pub fn hash_password(password: &str) -> Result<(String, String)>
pub fn verify_password(hashed_password: &str, salt: &str, password: &str) -> Result<bool>

Encryption Module (encryption.rs)

Manages cryptographic operations:

• Key pair generation for asymmetric encryption
• Message encryption and decryption
• Uses libsodium (via sodiumoxide) for cryptographic primitives

// Key functions
pub fn generate_keypair() -> KeyPair
pub fn encrypt_message(message: &str, public_key: &PublicKey, secret_key: &SecretKey) -> Vec<u8>
pub fn decrypt_message(encrypted_data: &[u8], public_key: &PublicKey, secret_key: &SecretKey) -> Result<String, &'static str>

Message Module (message.rs)

Defines message structure and handling:

• Message serialization and deserialization
• Message types (text, file, etc.)
• Content encryption

// Data structures
pub struct Message {
    pub timestamp: DateTime<Utc>,
    pub message_type: MessageType,
    pub sender: String,
    pub recipient: String,
    pub content: Vec<u8>,
    pub public_key: PublicKey,
}

pub enum MessageType {
    Text,
    File,
}

Client Module (client.rs)

Manages the client side of communication:

• Connection to server
• Message sending
• User interface interaction

// Key functions
pub async fn send_message(message: &Message, server_addr: &str) -> Result<(), Box<dyn std::error::Error>>

Server Module (server.rs)

Handles server-side operations:

• Listening for client connections
• Message routing
• Rate limiting for security

// Key functions
pub async fn run_server(addr: &str, server_secret_key: &SecretKey) -> Result<(), Box<dyn std::error::Error>>

Tauri 2.0 Integration

The Tauri 2.0 application provides a cross-platform interface for QuietDrop:

Yew Frontend

Built entirely in Rust and compiled to WebAssembly:

• Component-based UI architecture
• State management using Yew hooks and contexts
• Responsive design for desktop and mobile
• Platform-specific adaptations

Tauri Backend

Bridges the frontend with the core library:

• Exposes core functionality through Tauri commands
• Manages application state
• Handles platform-specific features
• Provides system integration (file system, notifications, etc.)

sequenceDiagram
    participant User
    participant YewUI as Yew UI
    participant TauriBackend as Tauri Backend
    participant CoreLib as Core Library
    participant Server
    
    User->>YewUI: Interact with UI
    YewUI->>TauriBackend: Call Tauri command
    TauriBackend->>CoreLib: Use core functionality
    CoreLib->>Server: Send encrypted message
    Server-->>CoreLib: Acknowledge message
    CoreLib-->>TauriBackend: Return result
    TauriBackend-->>YewUI: Update UI state
    YewUI-->>User: Show confirmation

Loading

Data Flow

Key Exchange

1. Both server and clients generate their own key pairs (public and private keys)
2. Server's public key is stored in a file that clients can access
3. Clients send their public key along with each message

Message Sending

1. Client constructs a message with sender, recipient, and content
2. Client encrypts the message content using:
   • Recipient's public key (or server's public key in current implementation)
   • Client's private key
3. Encrypted message is sent to the server

Message Reception

1. Server receives the encrypted message
2. Server decrypts the message using:
   • Sender's public key (included in the message)
   • Server's private key
3. Server processes the message and can relay it to other clients

Technology Stack

• Core Language: Rust (for memory safety and performance)
• Frontend Framework: Yew (Rust-based UI framework)
• Application Framework: Tauri 2.0 (cross-platform deployment)
• Cryptography: sodiumoxide (Rust bindings for libsodium)
• Networking: Tokio (asynchronous runtime)
• Serialization: Serde (for structuring messages)
• Password Hashing: Argon2 (memory-hard function resistant to attacks)
• Database (planned): SQLite with sqlx for persistent storage

Security Considerations

• End-to-End Encryption: Messages can only be decrypted by intended recipients
• Forward Secrecy: Compromise of keys doesn't expose past communications
• Authentication: Strong password hashing prevents credential theft
• Rate Limiting: Protects against brute force and DoS attacks
• Process Isolation: Tauri's architecture separates the frontend (WebView) from backend (Rust)
• Platform Security: Leverages platform-specific security features on desktop and mobile

Cross-Platform Considerations

graph TD
    subgraph "Platform-Specific Features"
        subgraph "Desktop"
            DT[System Tray]
            DW[Multiple Windows]
            DN[Desktop Notifications]
            DFS[File System Access]
        end
        
        subgraph "Mobile"
            MP[Push Notifications]
            MB[Biometric Authentication]
            MC[Camera Access]
            MPH[Photo Library]
        end
        
        subgraph "Shared"
            SE[Secure Storage]
            SN[Network Communication]
            SC[Clipboard Access]
            SD[Dialog Windows]
        end
    end

Loading

• UI Adaptation: Components adapt to different screen sizes and input methods
• Platform Detection: Runtime detection of platform for feature availability
• Resource Management: Different strategies for desktop and mobile
• Permission Handling: Platform-specific permission requests and management

Future Architecture Extensions

• Database Integration: SQLite with sqlx for message persistence and user management
• Federation Protocol: To allow communication between different QuietDrop servers
• Push Notification Service: For mobile message delivery
• Offline Capabilities: Local-first architecture with synchronization

Deployment Architecture

Current deployment is simplified for development:

graph TD
    subgraph "Development Environment"
        Server[Server Instance]
        CLI[CLI Client]
        Desktop[Desktop App]
        Mobile[Mobile App]
        
        CLI -->|Connects to| Server
        Desktop -->|Connects to| Server
        Mobile -->|Connects to| Server
    end

Loading

Future scalable deployment architecture:

graph TD
    subgraph "Server Infrastructure"
        LB[Load Balancer]
        
        subgraph "Server Cluster"
            S1[Server 1]
            S2[Server 2]
            S3[Server 3]
        end
        
        subgraph "Database Cluster"
            DB1[(Primary DB)]
            DB2[(Replica DB)]
        end
        
        LB --> S1
        LB --> S2
        LB --> S3
        
        S1 <--> DB1
        S2 <--> DB1
        S3 <--> DB1
        
        DB1 <-->|Replication| DB2
    end
    
    subgraph "Clients"
        DC[Desktop Clients]
        MC[Mobile Clients]
    end
    
    DC --> LB
    MC --> LB

Loading

For more detailed technical information, please see:

• API documentation
• Tauri Architecture
• Frontend Development Guide