Thanks for your interest in contributing! Vesper is an open-source project and we welcome contributions of all kinds — bug fixes, new features, documentation, and more.
- Fork the repository on GitHub
- Clone your fork locally:
git clone https://github.com/YOUR_USERNAME/V3SP3R.git cd V3SP3R - Create a branch for your work:
git checkout -b feature/your-feature-name
- Open in Android Studio and let Gradle sync
- Build and test your changes
- Android Studio (latest stable recommended)
- JDK 17+
- Android SDK with API 26+ (Android 8.0)
- A Flipper Zero device (for testing hardware features)
- Follow standard Kotlin coding conventions
- Use meaningful variable and function names
- Keep functions focused — one function, one responsibility
- Use Jetpack Compose best practices for UI code
Vesper follows a layered architecture:
- UI Layer — Jetpack Compose screens + ViewModels (in
ui/) - Domain Layer — Business logic, command execution, risk assessment (in
domain/) - Data Layer — Persistence, API clients, BLE communication (in
data/,ai/,ble/)
When adding features, place code in the appropriate layer. If unsure, look at how existing features are structured.
Security is a core concern for Vesper. Please:
- Never commit API keys, secrets, or credentials
- Always validate and sanitize external input (LLM responses, BLE data, user input)
- Respect the risk classification system — new actions must have appropriate risk levels
- Test edge cases, especially around JSON parsing and BLE communication
- Run inputs through the existing
InputValidatorandInputSanitizerutilities
Write clear, descriptive commit messages:
Add SubGHz frequency validation to signal editor
Validates that user-entered frequencies fall within supported SubGHz
bands before attempting transmission. Shows an inline error for
out-of-range values.
- Use the imperative mood ("Add", not "Added" or "Adds")
- First line: concise summary (50 chars or less ideal, 72 max)
- Body: explain what and why, not how
- iOS version — SwiftUI port of the Android app
- Signal format parsers — Support for new RF/IR protocols
- Payload templates — BadUSB scripts, SubGHz signals, IR remotes, NFC tags
- UI/UX improvements — Animations, accessibility, responsive layouts
- Translations / i18n — Localization for non-English languages
- Test coverage — Unit tests, integration tests, UI tests
- Documentation — Guides, tutorials, API docs
Look for issues labeled good first issue — these are scoped, well-documented tasks ideal for new contributors.
- Ensure your code builds without errors or warnings
- Test your changes on a real device if possible
- Push your branch to your fork
- Open a Pull Request against the
mainbranch - Fill out the PR template completely
- Respond to review feedback promptly
- Keep PRs focused — one feature or fix per PR
- Include a clear description of what changed and why
- Reference related issues (e.g., "Closes #42")
- Add screenshots or recordings for UI changes
- Ensure no secrets or credentials are included
Use the Bug Report issue template. Include:
- Steps to reproduce
- Expected vs actual behavior
- Device info (Android version, Flipper firmware version)
- Logs or screenshots if available
Use the Feature Request issue template. Describe:
- The problem you're trying to solve
- Your proposed solution
- Any alternatives you've considered
Be respectful. We're all here to build something useful. Harassment, trolling, and unconstructive behavior won't be tolerated.
By contributing, you agree that your contributions will be licensed under the GPL-3.0 License.
Questions? Open a Discussion or reach out in an issue. We're happy to help you get started.