Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
150 lines (104 loc) · 3.43 KB

CONTRIBUTING.md

File metadata and controls

150 lines (104 loc) · 3.43 KB
Raw

Contributing to TTP

Thanks for your interest in contributing to the Trust Transfer Protocol (TTP).

TTP is security-critical infrastructure. We optimize for clarity, correctness, and interoperability over speed.

Role-Based Contribution Paths

You can contribute from different roles in the trust network:

1) Trust Authority / Network Core Contributors

Focus areas:

  • aggregation correctness and determinism
  • key management and signing flows
  • admin/operator workflows (registration, quarantine, block, provisioning)
  • scalability, persistence, and reliability hardening

2) Issuer Contributors

Focus areas:

  • issuer adapters (API gateways, runtime monitors, network telemetry)
  • receipt quality and event taxonomy
  • signature integrity and replay resistance
  • independent issuer deployment patterns

3) Verifier / Service Contributors

Focus areas:

  • middleware and policy adapters
  • low-latency token verification
  • fallback behavior by risk tier
  • action-level enforcement patterns

4) Agent / SDK Contributors

Focus areas:

  • token lifecycle UX (cache, refresh, expiry handling)
  • framework integrations (agent runtimes, orchestration platforms)
  • typed SDK ergonomics and docs
  • secure defaults for application developers

5) Security Contributors

Focus areas:

  • threat modeling and adversarial scenarios
  • fuzzing and malformed input handling
  • signature validation hardening
  • trust-manipulation and collusion resilience

6) Documentation & Adoption Contributors

Focus areas:

  • quickstarts and tutorials
  • operator runbooks
  • architecture diagrams and reference deployments
  • migration and interoperability guides

Getting Started

  1. Fork the repository.
  2. Create a focused branch.
  3. Make atomic changes.
  4. Run relevant checks/tests.
  5. Open a PR with:
    • context/problem statement
    • rationale and tradeoffs
    • test/validation notes

Development Principles

  • Minimal core: avoid unnecessary abstraction and scope creep.
  • Interoperability first: multiple independent implementations must remain possible.
  • Security over convenience: assume adversarial environments.
  • Stateless preference: verification should not require persistent trust state.
  • Deterministic behavior: trust decisions should be explainable and reproducible.

Spec Changes (RFC Process)

For protocol-level changes:

  1. Open an issue labeled rfc.
  2. Propose:
    • problem statement
    • proposed change
    • alternatives considered
    • compatibility impact
  3. Discuss with maintainers/community.
  4. Merge only after consensus.

Pull Request Guidelines

PRs should:

  • be scoped and atomic
  • include tests when applicable
  • avoid unrelated refactors
  • document behavioral or API changes

Code Standards

  • Explicit > implicit
  • Readability > cleverness
  • Secure defaults
  • Clear error handling
  • Backward compatibility awareness

Good First Contributions

Look for issues labeled:

  • good first issue
  • documentation
  • sdk
  • examples

These are intentionally scoped for faster onboarding.

Reporting Security Issues

Do not open public issues for vulnerabilities.

Report privately to maintainers with:

  • reproduction steps
  • impact assessment
  • mitigation ideas (if available)

We will coordinate responsible disclosure.

Community Expectations

Be constructive. Challenge ideas, not people. Bias toward collaboration.

We are building infrastructure others will depend on.