Project Status

Daplin has a v0.4.0 protocol specification and a working reference server implementation in Python/FastAPI. The server supports identity creation, card publishing, DID resolution, two-instance federation, card exchange, and dual-mode event delivery (WebSocket + HTTP polling). It runs on SQLite or PostgreSQL with content-addressable storage backed by the local filesystem or IPFS.

The project is actively developing toward full spec alignment. Both specification review and code contributions are valuable.

What We Need Now

Specification Review

Read the Protocol Specification carefully. Look for:

  • Ambiguities — places where the spec could be interpreted two different ways
  • Missing edge cases — scenarios the spec doesn’t address but should
  • Internal inconsistencies — places where two sections contradict each other
  • Underspecified behavior — areas where an implementor would have to guess

Open a GitHub issue for each finding. Be specific: quote the relevant section, describe the problem, and if you have a proposed resolution, include it.

Security Analysis

The cryptographic architecture, trust model, and threat model in the spec (§14) are designed to be sound, but independent review is essential. If you have expertise in:

  • Cryptographic protocol design
  • Decentralized identity systems
  • Threat modeling
  • Privacy engineering

…your analysis is particularly valuable. Open an issue or start a discussion.

Code Contributions

The reference server is a Python/FastAPI application in the server/ directory. Areas where contributions are welcome:

  • Spec alignment — the server’s activity types and flows need to be brought in line with the spec’s terminology (e.g., ExchangeRequest → Introduce)
  • NATS JetStream backend — the event queue currently uses an in-memory backend; a NATS JetStream backend is planned for production
  • Test coverage — unit, integration, and federation tests
  • Bug fixes and hardening — edge cases in federation, error handling, input validation

See the Code Contributions section below for setup instructions and guidelines.

Protocol Design Feedback

If you have substantive feedback on a design decision — the trust model, the capability key tiers, the federation model, the DID method choices — use the RFC process described below.

Documentation

If you find errors, unclear explanations, or missing context in the specification or this site, open an issue or submit a pull request with the correction.

How to Propose Changes

The Daplin protocol uses an open RFC process, as described in the Protocol Specification §13.4.

  1. Open a GitHub issue describing the proposed change. Title it clearly: RFC: <brief description>.
  2. Include rationale — explain why the current design is insufficient and what problem your proposal solves.
  3. Describe the impact — note any effects on existing protocol behavior, backwards compatibility, or security properties.
  4. Discussion period — substantive changes require a minimum 60-day discussion period before any decision is made. This is not a formality; it is how the protocol earns trust.
  5. Consensus — the protocol belongs to its community of implementors. No single organization controls it.

Minor corrections (typos, clarifications that don’t change behavior) can be submitted directly as pull requests without a formal RFC.

Code Contributions

The reference server lives in server/ and is a self-contained Python package.

Setup

# Prerequisites: Python 3.13, uv (https://docs.astral.sh/uv/)
cd server
uv sync --dev          # Install all dependencies
uv run pytest          # Run the test suite
uv run ruff check src tests   # Lint
uv run mypy src/daplin_server # Type check

Guidelines

  • Fork the repository and create a feature branch
  • Write tests alongside your implementation
  • All code must pass ruff check, mypy (strict mode), and pytest before submission
  • Submit a pull request with a clear description of what you’ve done and why
  • Keep pull requests focused — one logical change per PR

Architecture

The server follows a layered architecture:

  • api/ — FastAPI route handlers (thin layer, delegates to core)
  • core/ — Business logic (identity, crypto, federation, DIDComm)
  • schemas/ — Pydantic models for request/response validation
  • db/ — SQLAlchemy models and async session management
  • storage/ — Content-addressable storage backends (filesystem, IPFS)
  • queue/ — Event queue backends (in-memory; NATS planned)

See .state/ARCHITECTURE.md for the full architectural overview and design decisions.

Community Expectations

This project takes its name and its values seriously. Contributions should reflect that spirit.

  • Be respectful and constructive. Critique ideas, not people.
  • Be specific. Vague objections are not useful; precise analysis is.
  • Be honest. If you’re uncertain, say so. If you disagree, say why.
  • Discrimination, harassment, and bad-faith engagement are not tolerated.

License

Daplin is licensed under the Apache License 2.0.

By submitting a contribution — whether a pull request, an issue, or a discussion comment that is incorporated into the specification — you agree that your contribution will be licensed under the same terms.