VX6 is being developed as a networking project with a narrow initial scope and a long technical runway. Contributions should improve correctness, clarity, and operational confidence.
- Keep IPv6 behavior explicit.
- Prefer simple designs over speculative abstraction.
- Build stable transport primitives before layering discovery or routing features.
- Document behavioral changes in the same change set as the code.
- Go 1.22 or newer
- Linux-first workflow
- An environment where IPv6 can be tested directly
cmd/contains executable entrypoints.internal/contains implementation packages.docs/contains architecture, roadmap, and protocol notes.
Keep pull requests focused. A good change set should:
- solve one clearly defined problem
- include tests when behavior can be exercised automatically
- update documentation when commands, structure, or semantics change
- explain operational impact in plain language
- Run
gofmton all Go changes. - Keep exported APIs minimal.
- Return contextual errors.
- Do not silently fall back from IPv6 to IPv4.
- Avoid introducing dependencies without a clear payoff.
Open an issue or short design note before changing:
- wire formats
- identity semantics
- routing behavior
- discovery models
- configuration layout
Do not commit private keys, captured traffic, credentials, or lab secrets. If a change affects trust boundaries or transport guarantees, document the assumptions directly in the pull request.
Unless separately agreed in writing, contributions submitted to VX6 are accepted under Apache-2.0 terms.
Commercial rights are handled only through separate written agreements with the licensor (see LICENSE-COMMERCIAL.md).