morsel
pomagrenate/morsel
Overview
A blazing-fast, encrypted, local-first clipboard manager built in Rust. Features secure encryption, instant search, and minimal resource footprint.
Technologies & Concepts
Project Analysis
🔴 Problem
Windows + V clipboard limitations: Standard Windows clipboard only holds one item at a time, with no search capability, no security for sensitive data, and no history persistence.
Developer workflow pain: Developers frequently copy code snippets, API keys, commands, and configuration data, but lose previous clipboard content when copying new items. No way to search through previously copied content.
Security concerns: Sensitive data like API keys and credentials copied to clipboard remain unencrypted and vulnerable, with no way to securely manage clipboard history.
Existing solutions bloated: Electron-based clipboard managers consume 250-600MB RAM and have slow startup times (1.2-3.5s), making them unsuitable for always-on background use.
⚪ Baseline
Starting point: Standard Windows clipboard functionality
Baseline characteristics:
- Single item storage (overwrites previous content)
- No search capability
- No encryption or security
- No history persistence
- No content categorization
Alternative solutions: Electron clipboard managers with 250-600MB RAM footprint, 1.2-3.5s startup time, continuous network telemetry
🔵 Change
Built morsel: Rust-based encrypted local-first clipboard manager designed for developers
Key architectural changes:
- 100% pure Rust implementation for native performance
- AES-256-GCM encryption for sensitive clipboard data
- Instant fuzzy search through 100,000+ items in <2ms
- Developer-aware auto-detection (JSON, YAML, SQL, code languages)
- Background daemon with <5MB RAM footprint
- Zero-cloud architecture with no network requests
- Terminal UI (TUI) with syntax highlighting
Modular architecture: Separate crates for clipboard monitoring, search engine, storage, platform abstraction, and daemon
🟣 Measurement
Test environment: Windows system with comprehensive performance monitoring
Metrics collected:
- CPU usage (65.04% total, 36.12% user, 28.82% privileged)
- Memory management (637 MB available, 10.5 GB committed)
- Disk I/O performance (4.07ms read, 0.22ms write latency)
- Thermal performance (24.85°C operating temperature)
- Network activity (1.8 KB/sec, 14 packets/sec)
- Comparison vs Electron clipboard managers
Benchmark suite: Criterion benchmarks for search engine, storage engine, content detection, and daemon startup
🟢 Result
Exceptional resource efficiency:<4.2 MB RAM footprint vs 250-600 MB for Electron tools (~100x lighter)
Blazing fast startup:<12 ms startup vs 1,200-3,500 ms for Electron tools (~250x faster)
Instant search performance: 1.8 ms search latency for 100k items vs 120-450 ms for Electron tools (~100x faster)
Compact binary size:<3.8 MB vs 120+ MB for Electron tools (~30x smaller)
Complete privacy: Zero network requests vs continuous telemetry in Electron tools (100% offline)
System performance: Efficient CPU utilization, excellent thermal performance (24.85°C), sub-millisecond disk I/O
Performance Visualizations
Overall Performance Comparison

Memory Usage Comparison

Morsel vs Windows Clipboard Comparison

Radar Chart Comparison

Search Scaling Performance

Startup Time Comparison

🟡 Lesson
Rust's zero-cost abstractions: Building morsel taught me that Rust's compile-time guarantees don't come at runtime cost. The zero-cost abstractions and efficient memory management translated directly to ~100x improvements in resource usage vs Electron alternatives.
Local-first architecture benefits: The minimal network footprint (1.8 KB/sec) validated the local-first approach. By keeping data encrypted and local, morsel provides both privacy and performance benefits that cloud-based clipboard managers cannot match.
Background service optimization: The thermal and CPU metrics taught me the importance of efficient background processing. A clipboard manager needs to be always-on but resource-conscious, which influenced my design decisions around event-driven architecture rather than polling.
Encryption performance trade-offs: I learned that encryption doesn't have to be slow. The disk latency metrics show that with proper implementation (AES-NI hardware acceleration), encrypted clipboard operations can be as fast as unencrypted ones.
Search algorithm selection:The search scaling benchmarks demonstrated that choosing the right data structure (inverted index with fuzzy matching) makes a significant difference in performance as clipboard history grows, enabling <2ms search across 100k+ items.
Clipboard management complexity: I learned that clipboard management is more complex than it appears - handling different data types, encryption, history persistence, and cross-platform compatibility requires careful modular architecture design.