Thank you for your interest in contributing to LMP! This document provides guidelines and instructions for contributing.
- Code of Conduct
- Getting Started
- How to Contribute
- Development Setup
- Coding Standards
- Commit Guidelines
- Pull Request Process
- Security Vulnerabilities
This project adheres to a Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to the maintainers.
- Rust 1.75+ - Install Rust
- Git - For version control
- A C compiler - Required for post-quantum crypto libraries (gcc/clang)
LMP_Lattice-Mesh-Protocol/
├── MAIN.md # Protocol specification (read first!)
├── SECURITY.md # Security details
├── GUIDE.md # Developer guide
├── CONTRIBUTING.md # This file
│
└── lmp-core/ # Core library
├── src/
│ ├── crypto/ # Cryptographic primitives
│ ├── protocol/ # Protocol logic
│ ├── network/ # Mesh networking
│ ├── storage/ # Persistence
│ └── device/ # Identity management
└── tests/ # Integration tests
- 🐛 Bug Reports - Found a bug? Open an issue!
- ✨ Feature Requests - Have an idea? We'd love to hear it!
- 📝 Documentation - Help improve our docs
- 🧪 Testing - Write tests, find edge cases
- 🔧 Code - Fix bugs, implement features
- 🔒 Security - Review crypto implementations
Look for issues labeled:
good first issue- Great for newcomershelp wanted- We need assistancedocumentation- Documentation improvements
# Fork the repository on GitHub, then:
git clone https://github.com/AaryanBansal-Dev/LMP_Lattice-Mesh-Protocol.git
cd LMP_Lattice-Mesh-Protocolcd lmp-core
cargo build# Run all tests
cargo test
# Run with verbose output
cargo test -- --nocapture
# Run a specific test
cargo test test_name# Format code
cargo fmt
# Run linter
cargo clippy
# Check for security issues
cargo auditcargo doc --open- Follow Rust API Guidelines
- Use
cargo fmtbefore committing - Address all
cargo clippywarnings - Write documentation for public APIs
//! Module-level documentation explaining purpose.
use crate::error::{Error, Result};
/// Brief description of the function.
///
/// More detailed explanation if needed.
///
/// # Arguments
///
/// * `input` - Description of the input parameter
///
/// # Returns
///
/// Description of return value.
///
/// # Errors
///
/// * `Error::InvalidInput` - When input is invalid
///
/// # Example
///
/// ```rust
/// let result = my_function(input)?;
/// ```
pub fn my_function(input: &[u8]) -> Result<Vec<u8>> {
if input.is_empty() {
return Err(Error::InvalidInput("Input cannot be empty".into()));
}
// Implementation
Ok(input.to_vec())
}
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn test_my_function_success() {
let result = my_function(b"test").unwrap();
assert_eq!(result, b"test");
}
#[test]
fn test_my_function_empty_input() {
let result = my_function(b"");
assert!(result.is_err());
}
}For cryptographic code:
- Use constant-time operations for comparisons
- Zeroize secrets when they go out of scope
- Avoid branching on secrets (timing attacks)
- Document security assumptions
- Add security-focused tests
use zeroize::{Zeroize, ZeroizeOnDrop};
#[derive(Zeroize, ZeroizeOnDrop)]
struct SecretKey {
bytes: [u8; 32],
}
// Use constant-time comparison
use crate::storage::memory::constant_time_eq;
if constant_time_eq(&received, &expected) {
// OK
}<type>(<scope>): <subject>
<body>
<footer>
| Type | Description |
|---|---|
feat |
New feature |
fix |
Bug fix |
docs |
Documentation only |
style |
Formatting, no code change |
refactor |
Code refactoring |
test |
Adding tests |
chore |
Maintenance tasks |
security |
Security improvements |
feat(crypto): add Kyber768 key encapsulation
Implements the NIST-standardized Kyber768 post-quantum KEM.
Includes encapsulate and decapsulate functions with proper
error handling.
Closes #123
fix(ratchet): prevent nonce reuse in edge case
When message counter overflows, the nonce could potentially
be reused. Added check to trigger ratchet step before overflow.
Security: Prevents potential nonce reuse attack
docs(guide): add section on key rotation
Added detailed explanation of when and how different key types
are rotated, including code examples.
- ✅ Read the docs - Understand the codebase
- ✅ Create an issue first - For significant changes
- ✅ Branch from main - Create a feature branch
- ✅ Keep changes focused - One feature/fix per PR
- ✅ Write tests - Cover new functionality
- ✅ Update docs - If behavior changes
- Code compiles without warnings (
cargo build) - All tests pass (
cargo test) - Code is formatted (
cargo fmt) - Clippy is happy (
cargo clippy) - Documentation updated if needed
- Commit messages follow guidelines
- PR description explains changes
- Automated checks - CI runs tests
- Code review - Maintainer reviews code
- Discussion - Address feedback
- Approval - Maintainer approves
- Merge - Squash and merge
- Delete your feature branch
- Update your fork's main branch
- Celebrate! 🎉
If you discover a security vulnerability:
- Do NOT open a public issue
- Email the maintainers privately
- Include:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (if any)
We will:
- Acknowledge receipt within 48 hours
- Provide a timeline for the fix
- Credit you in the security advisory (if desired)
See SECURITY.md for our security policy.
- 📖 Check the Developer Guide
- 💬 Open a Discussion on GitHub
- 📧 Email the maintainers
Contributors will be:
- Listed in the project's contributors
- Credited in release notes
- Thanked in our community
Thank you for contributing to LMP! Together we're building a more private future. 🔐