Contributing to Komms

Komms is an alpha built from source. Its core, transports, local RPC/CLI and UniFFI surfaces, and desktop/Android/iOS shells are implemented, while hardware qualification, distribution, hardening, and several product slices remain.

Where contributions help

Open an issue for anything in docs/ that is wrong, unclear, or missing:

• Highest value: holes in the threat model, flaws in the crypto spec, unrealistic assumptions in the transport design (LoRa airtime math especially; field experience with Meshtastic very welcome).
• Disagreement with a recorded decision? Respond to the specific ADR and address the alternatives it already weighed.
• Implementation work should start from the current gaps in the roadmap and feature delivery plan, then preserve the relevant security, storage, compatibility, and carrier constraints.

Implementation changes

• Read 09: Implementation Guide first; it defines crate boundaries, crypto coding standards, and review gates. Checked-in APIs are authoritative. PRs that change design without an ADR will be redirected to the ADR process, kindly.
• CI must be green: fmt, clippy (deny warnings), tests, fuzz smoke, cargo-deny.
• Keep PRs scoped to one concern; cite the spec section your change implements.

Process

• Issues for design discussion; PRs for concrete text/code changes.
• ADRs follow docs/adr/template.md and appear in the ADR index; new ADRs are numbered sequentially and never edited after acceptance (write a superseding one).
• Be direct about problems and generous with people. Security arguments win on merit, not volume.

Licensing of contributions

By contributing you agree your contribution is licensed under AGPLv3, the project license. No CLA: the license is the agreement, symmetrically, for everyone.