A secure, private, and decentralized chat app using the marmot protocol 🦫 to build secure messaging with MLS and Nostr
This is the Flutter app repository. If you're looking for the core messaging logic of whitenoise or the CLI, those live in whitenoise-rs.
- ✅ Android - Fully supported
- ✅ iOS - Fully supported
- ⏳ macOS - Not supported yet
- ⏳ Windows - Not supported yet
- ⏳ Linux - Not supported yet
- ⏳ Web - Not supported yet
lib/
├── constants/ # Shared constants: fixed, related sets or reused elsewhere only
├── providers/ # Shared state
├── hooks/ # Ephemeral widget state
├── services/ # Stateless operations (API calls)
├── screens/ # Full-page components
├── widgets/ # Reusable components
- Flutter
- Rust
- flutter_rust_bridge - Dart ↔ Rust integration
- whitenoise rust crate 🦀
- Flutter SDK (3.24.x or later)
- Rust (latest stable)
- Just -
cargo install just - flutter_rust_bridge_codegen -
cargo install flutter_rust_bridge_codegen
# Install dependencies
just deps # Install both Flutter and Rust deps
just deps-flutter # Flutter dependencies only
just deps-rust # Rust dependencies only
# Format code
just format # Format both Rust and Dart
just format-rust # Format Rust only
just format-dart # Format Dart only
# Coverage
just coverage # Checks tests coverageYou need to install lcov to generate report
# Mac OS
brew install lcov
# Linux
apt-get install lcov# First run tests with coverage option
flutter test --coverage
# Generate coverage html report
genhtml coverage/lcov.info -o coverage/html
# Open coverage/html/index.html in your browser- We keep complexity low.
- We keep the app thin.
- We test our code.
- We delete dead code. Commented code is dead code.
- We use the Whitenoise Rust crate as the source of truth.
- We avoid caching in Flutter; the Whitenoise crate already persists data in a local DB.
- We put shared app state in providers.
- We put ephemeral widget state in hooks.
- We pass data to hooks, not widget refs.
- We let screens watch providers and pass data to hooks.
- We avoid comments unless strictly necessary and write self-explanatory code.
Contributions are welcome. Please read CONTRIBUTING.md before opening a PR.
TLDR: fork the repo, open or comment on an issue before building significant features, keep PRs under ~500 lines, open as a draft if it's not ready for review, always run just precommit, and include screenshots for UI changes.






