Project
Contributing to Attestix
How to get started contributing to Attestix, including development workflow, code conventions, and project architecture rules.
Contributing to Attestix
Thank you for your interest in contributing to Attestix. This guide covers how to get started, the development workflow, and project conventions.
Getting Started
Prerequisites
- Python 3.10+
- Git
Setup
git clone https://github.com/VibeTensor/attestix.git
cd attestix
python -m venv .venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
pip install -r requirements.txtVerify Setup
python main.py
# Should print "Attestix MCP server loaded: 47 tools registered" to stderr
# Then wait for MCP client connections on stdioPress Ctrl+C to stop.
Project Structure
attestix/
auth/ # Cryptography and token parsing
services/ # Business logic (one service per module)
tools/ # MCP tool definitions (thin wrappers around services)
docs/ # Documentation
examples/ # Runnable example scripts
config.py # Storage paths and helpers
errors.py # Error handling and logging
main.py # Entry pointArchitecture Rules
- Services contain all logic. Tool files are thin wrappers that call service methods.
- Services never import from tools. Dependencies flow: tools -> services -> config/auth.
- All output to stderr.
builtins.printis redirected to stderr to protect MCP JSON-RPC on stdout. - JSON storage with file locking. Use
_safe_load/_safe_savefromconfig.pyfor all file I/O. - Ed25519 signatures. All persistent records (UAITs, VCs, audit entries) must be signed.
How to Contribute
Reporting Issues
Open an issue on GitHub with:
- What you expected
- What happened
- Steps to reproduce
- Python version and OS
Submitting Changes
- Fork the repository
- Create a feature branch:
git checkout -b feature/your-feature - Make your changes
- Run the test suite to verify nothing is broken:
# Run all 284 tests (unit, e2e, conformance benchmarks) pytest tests/ -v -m "not live_blockchain" # Or run in Docker for a clean environment docker build -f Dockerfile.test -t attestix-bench . && docker run --rm attestix-bench - Commit with a descriptive message
- Push to your fork and open a Pull Request
Pull Request Guidelines
- One feature or fix per PR
- Keep changes focused - avoid mixing refactoring with new features
- Update documentation if you change tool parameters or behavior
- Add an example script if you add a new module
Code Conventions
Style
- Python standard library style (no external formatter enforced)
- Use type hints for function signatures
- Docstrings on all public methods and classes
- Keep imports sorted: stdlib, third-party, local
Naming
- Services:
{module}_service.pywith a class named{Module}Service - Tools:
{module}_tools.pywith aregister(mcp)function - Storage files: lowercase
{module}.json - IDs: prefixed with module abbreviation (e.g.,
attestix:,comp:,assess:,urn:uuid:)
Error Handling
Return error dicts instead of raising exceptions in service methods:
def my_method(self, agent_id: str) -> dict:
agent = self._find_agent(agent_id)
if not agent:
return format_error(
"Agent not found",
ErrorCategory.IDENTITY,
"AGENT_NOT_FOUND",
)
# ... do work
return {"result": "success"}Adding a New Module
- Create
services/your_service.pywith a service class - Create
tools/your_tools.pywith aregister(mcp)function - Add storage helpers to
config.pyif needed - Add error category to
errors.pyif needed - Import and register in
main.py - Update tool count in
main.pydocstring - Add documentation to
docs/api-reference.md - Create an example in
examples/
Security
- Never return private keys in tool responses
- Exclude mutable fields (proof, credentialStatus) from signature payloads
- Use
secretsmodule for generating random identifiers - Validate all URLs before making HTTP requests (SSRF protection)
- Report security vulnerabilities privately via email, not public issues
License
By contributing, you agree that your contributions will be licensed under the Apache License 2.0.