8000 GitHub - bhmortim/quidnug: A decentralized cryptographic platform for trust, identity, and ownership. · GitHub
[go: up one dir, main page]
Skip to content
bhmortim
quidnug
Public

About

A decentralized cryptographic platform for trust, identity, and ownership.

Resources

Readme
Apache-2.0 license

Code of conduct

Code of conduct

Contributing

Contributing

Security policy

Security policy
Activity

Stars

4 stars

Watchers

1 watching

Forks

0 forks
Report repository
BranchesTags

Repository files navigation

Quidnug

CI codecov Go Report Card License: Apache 2.0

A decentralized protocol for relational trust, identity, ownership, and auditable state — where trust is personal, cryptographic, and contextual.

TL;DR

Quidnug is a P2P protocol and Go reference node that lets your application answer questions like:

  • "From my perspective, how much should I trust this counterparty?"
  • "Did this specific key authorize this action, and can I recover if it's lost or compromised?"
  • "Has this asset been passed through a chain of parties I can verify?"
  • "Has this event truly happened in a tamper-evident ledger?"

It does this with a typed trust graph, per-signer replay-safe nonces, M-of-N guardian-based key recovery with time-lock vetoes, cross-domain gossip with signed fingerprints, and a proof-of-trust consensus where each node independently decides which blocks to trust based on its own relational view of the signer.

Think of it as: a trust graph + a tamper-evident event log + key lifecycle primitives, designed for systems where trust is not one-size- fits-all and where losing a key shouldn't lose the business.

Who should use Quidnug?

You'll get the most value if you're building:

If you build... Quidnug gives you...
A financial system with multi-party approval M-of-N signing + time-locked recovery + replay protection
An AI platform where provenance matters Signed supply chain of training data → model → inference
A credentialing system Revocable issuer trust + transitive verification
A marketplace with reputation Trust personalized to each viewer's network
A custody / escrow / vault product Guardian recovery, epoch-based key rotation
Any system where "who signed this?" matters ECDSA P-256 identities + on-chain rotation audit trail

You're probably not the target audience if:

  • You need a high-throughput payment chain (Quidnug targets auditability and correctness over raw TPS).
  • You want a single universal reputation score (the protocol deliberately refuses to produce one).
  • Your users expect "forgot password" email flows for key recovery (you can build that on top, but the protocol is cryptographic).

A 30-second demo

Start a node, create an identity, record a trust relationship, query it back:

# 1. Run a node
make build && ./bin/quidnug &
# -> listening on :8080

# 2. Create Alice's identity (your application would keep the key)
curl -X POST http://localhost:8080/api/identities \
  -d '{"quidId":"alice","name":"Alice","creator":"alice"}'

# 3. Alice declares she trusts Bob at 0.9 for "contractors.home"
curl -X POST http://localhost:8080/api/trust \
  -d '{"truster":"alice","trustee":"bob","trustLevel":0.9,"domain":"contractors.home"}'

# 4. Query trust FROM Alice's perspective
curl "http://localhost:8080/api/trust/alice/bob?domain=contractors.home"
# -> {"trustLevel":0.9,"trustPath":["alice","bob"],"pathDepth":1,...}

Now from Carol's perspective — if Carol trusts Alice at 0.8 and Alice trusts Bob at 0.9, Carol transitively trusts Bob at 0.72:

curl "http://localhost:8080/api/trust/carol/bob?domain=contractors.home"
# -> {"trustLevel":0.72,"trustPath":["carol","alice","bob"],"pathDepth":2}

The same target (Bob) has different trust levels from different observers. That's the whole point.

Key capabilities

Capability What it means for you See
Relational trust Every node computes trust from its own perspective. No universal score. Core concepts
Typed transactions Trust, Identity, Title, Event, Anchor, Guardian, ForkBlock — all signed. Transactions
Proof-of-Trust consensus Acceptance tiered (Trusted / Tentative / Untrusted / Invalid) per observer. docs/architecture.md
Per-signer monotonic nonces Strong replay protection without locking or global coordination. QDP-0001
Guardian-based recovery Lost or compromised keys? Recover via M-of-N guardian quorum with time-lock veto. QDP-0002
Cross-domain gossip Rotations in one domain propagate to others via signed fingerprints. QDP-0003
Push gossip Fresh rotations reach interested peers in seconds, not polling cycles. QDP-0005
K-of-K bootstrap Fresh nodes seed state from quorum of trusted peers — no blind single-source trust. QDP-0008
Fork-block activation Coordinate protocol changes on-chain at a future block height. QDP-0009
Compact Merkle proofs Light-client-friendly anchor verification — ~70% less gossip bandwidth. QDP-0010
Event streams Tamper-evident append-only event logs bound to any quid or title. Transactions

Use cases

A dozen-plus detailed use-case designs live under UseCases/. Each folder is a self-contained implementation plan with problem statement, architecture, Quidnug-specific integration, concrete code, and threat model.

Two cross-cutting documents you should read first:

  • UseCases/ARCHITECTURE.md — the one-document tour of the protocol substrate, the three architectural pillars (QDPs 0012 / 0013 / 0014), the common shape every use case takes, and the four archetypes (reputation / attestation / coordination / infrastructure).
  • UseCases/BUILDING-A-USE-CASE.md — the six-phase recipe for designing a new use case on top of Quidnug. Use when you're ready to add your own.

FinTech:

AI:

Consumer rights / Anti-centralization:

  • UseCases/decentralized-credit-reputation/ — Full replacement for credit bureaus and social-credit systems. Borrower owns their credit history (BYOQ); each potential lender computes their own relational trust score; no central bureau, no universal number, no state-capturable citizen-score infrastructure. Encrypted access grants give the subject control over who sees what.
  • examples/reviews-and-comments/ — Trust-weighted reviews at web scale. The full QRP-0001 spec, a reference rating algorithm, a working end-to-end demo against a live node (showing the same 5 raw reviews producing three divergent per-observer ratings), and drop-in widgets for every major web framework. Replaces "one star rating for everyone" with "the rating your trust graph justifies."

Government / Elections:

  • UseCases/elections/ — Full-stack election design: bring-your-own voter quid, authority-signed registration trust edges replacing the voter registration database, precinct-scoped poll books as queries, blind- signature ballot issuance for anonymity with eligibility, votes-as-trust-edges, paper-ballot parity, instant recount anyone can run, and individual voter verification. The most detailed use case in the library.

Cross-industry high-value:

Infrastructure / internet plumbing:

  • UseCases/dns-replacement/ — Replace DNS with a cryptographically-owned, censorship-resistant, guardian-recoverable naming system. Every record is signed at publish, every delegation is governance-enforced, and DANE- integrated TLS removes CAs from the trust path. Deployable first as a parallel .quidnug TLD, then via DNS gateway for legacy clients, eventually as an alternative root for existing TLDs.

Each folder contains a full README.md (problem + why Quidnug + high-level design), architecture.md (data model + sequence diagrams), implementation.md (concrete API calls + pseudocode), and threat-model.md.

Core concepts

Quids: cryptographic identities

A quid is the primitive identity object. It's a public key plus metadata. The quid ID is the first 16 hex chars of sha256(publicKey).

type Quid struct {
    ID        string  // 16-char hex derived from public key
    PublicKey []byte  // ECDSA P-256 (32 bytes compressed)
    Created   int64
    MetaData  map[string]interface{}
}

A quid can represent a person, organization, device, AI agent, document, contract, or any entity that needs to sign things.

Trust: relational, observer-centric

Trust in Quidnug is always a statement "observer O trusts target T at level L in domain D", cryptographically signed by O. There is no global "what is Bob's trust score" — only "from my perspective..." answers.

Direct:       A ──0.9──► B                                   = 0.9
Two-hop:      A ──0.9──► B ──0.8──► C                        = 0.72
Three-hop:    A ──0.9──► B ──0.8──► C ──0.7──► D             = 0.504

Multiple paths? The algorithm takes the max — a single strong recommendation beats many weak ones. Depth-bounded BFS; default 5 hops.

Domains: hierarchical context

Domains give trust context. A DNS-like naming scheme lets you scope trust by use:

contractors.home.services
doctors.credentials.texas.medical-board.gov
oracles.price-feeds.ethereum.mainnet

A doctor trusted in doctors.credentials.texas.medical-board.gov is not automatically trusted in oracles.price-feeds.ethereum.mainnet. Domains can inherit along a parent/child axis when it makes sense.

Proof-of-Trust consensus

This is the part that surprises people. Quidnug does not produce a single globally-agreed chain. Instead, each node tiers incoming blocks:

Tier Condition Behavior
Trusted Trust in validator ≥ domain threshold Added to main chain; transactions applied
Tentative Between distrust and trust thresholds Stored separately, not built on
Untrusted Below distrust threshold Only trust-edge data extracted
Invalid Cryptographic verification fails Rejected

Why different nodes see different chains. Alice trusts validators A and B; Bob trusts A and D. They agree on A-sealed blocks. They disagree about B's and D's — which is correct, because they disagree about those parties.

This is not Byzantine Fault Tolerance. It's trust-aware consensus where the observer's context determines acceptance. It fits domains where "one chain for everyone" isn't the goal — private/consortium/ federated deployments, where parties disagree about who to trust.

Transactions

Seven core transaction types, each signed and anchored into blocks:

Type Purpose
TRUST Declare trust from one quid to another in a domain.
IDENTITY Name, attributes, home domain for a quid.
TITLE Asset ownership (full or fractional).
EVENT Append a signed event to a subject's stream.
ANCHOR Rotate key epoch, cap old epoch, invalidate epoch.
GUARDIAN_SET_UPDATE Install/replace guardian quorum for a quid.
GUARDIAN_RECOVERY_* Init / Veto / Commit time-locked guardian recovery.
GUARDIAN_RESIGN Guardian withdraws consent from a subject's quorum.
FORK_BLOCK Coordinate on-chain protocol feature activation.

Event streams

Every quid or title can have an append-only, monotonically-sequenced event stream — tamper-evident audit log. Payload inline up to 64 KB, or referenced via IPFS for larger data.

type EventTransaction struct {
    SubjectID   string  // quid or title ID
    SubjectType string  // "QUID" or "TITLE"
    Sequence    int64   // monotonic per subject
    EventType   string  // app-defined, e.g. "order.placed"
    Payload     map[string]interface{}
    PayloadCID  string  // optional IPFS CID
}

Key lifecycle: rotation, recovery, revocation

The protocol treats keys as having a lifecycle. When a key is compromised or retired:

  • Rotation (AnchorRotation). Signer publishes a signed anchor moving from epoch n to n+1. Optionally caps old-epoch nonces so in-flight transactions under the old key have a bounded window.
  • Invalidation (AnchorInvalidation). Freezes an epoch so no further transactions at that epoch are admitted.
  • Guardian recovery (GuardianRecoveryInit). M-of-N guardians can initiate a rotation on behalf of a subject who's lost their key. A time-lock delay (default 1h to 1yr) gives the legitimate owner a window to veto. Guardians must have on-chain consented to their role.
  • Guardian resignation. Guardians can withdraw consent without the subject's cooperation; prospective only — doesn't unwind in-flight recoveries.

Quick start

Build & run

Prerequisites: Go 1.25+ (the module targets Go 1.25; earlier toolchains cannot build it).

git clone https://github.com/bhmortim/quidnug.git
cd quidnug
make build
./bin/quidnug

Or Docker:

make docker-build
make docker-run

Health check:

curl http://localhost:8080/api/health
# {"success":true,"data":{"status":"ok",...}}

First interactions

Your first five API calls — an identity, a trust declaration, a trust query, an event, and a key rotation:

# 1. Create an identity
curl -X POST http://localhost:8080/api/identities -d '{
  "quidId":"alice","name":"Alice","creator":"alice","updateNonce":1
}'

# 2. Declare trust
curl -X POST http://localhost:8080/api/trust -d '{
  "truster":"alice","trustee":"bob","trustLevel":0.9,
  "domain":"contractors.home","nonce":1
}'

# 3. Query trust (relational, from Alice's view)
curl "http://localhost:8080/api/trust/alice/bob?domain=contractors.home&maxDepth=5"

# 4. Record an event against Alice's stream
curl -X POST http://localhost:8080/api/events -d '{
  "subjectId":"alice","subjectType":"QUID",
  "eventType":"profile.updated","payload":{"name":"Alice Chen"}
}'

# 5. Rotate Alice's key (epoch 0 → 1)
curl -X POST http://localhost:8080/api/anchors -d '{
  "kind":"rotation","signerQuid":"alice",
  "fromEpoch":0,"toEpoch":1,
  "newPublicKey":"<hex>","anchorNonce":1,...
}'

Full API reference: docs/openapi.yaml (OpenAPI 3.0).

Architecture at a glance

          ┌───── Client SDKs (Go, Python, JS, Rust) ────────────┐
          │  + framework adapters (React, Vue, Astro, WP, …)    │
          ▼                                                     ▼
        ┌──────────────────────────────────────────────────────────┐
        │                     HTTP REST API                         │
        │  /api/v1 (core)   /api/v2 (guardian + gossip + bootstrap) │
        └──────────────────────────────────────────────────────────┘
                                │
                                ▼
        ┌──────────────────────────────────────────────────────────┐
        │                   QuidnugNode (Go)                         │
        │                                                            │
        │  ┌──────────────┐ ┌────────────┐ ┌──────────────────┐     │
        │  │Trust Engine  │ │Nonce Ledger│ │Guardian Registry │     │
        │  │(BFS pathing) │ │(QDP-0001)  │ │(QDP-0002)        │     │
        │  └──────────────┘ └────────────┘ └──────────────────┘     │
        │                                                            │
        │  ┌──────────────┐ ┌────────────┐ ┌──────────────────┐     │
        │  │Block Engine  │ │Push Gossip │ │Bootstrap / Forks │     │
        │  │(PoT tiered)  │ │(QDP-0005)  │ │(QDP-0008/9/10)   │     │
        │  └──────────────┘ └────────────┘ └──────────────────┘     │
        └──────────────────────────────────────────────────────────┘
                    ▲         ▲         ▲         ▲
                    │         │         │         │
             HTTP+sig    Gossip    Probes    Snapshot pull
                    │         │         │         │
                    ▼         ▼         ▼         ▼
        ┌──────────────────────────────────────────────────────────┐
        │             Peer QuidnugNode instances (P2P)              │
        └──────────────────────────────────────────────────────────┘

Detailed design: docs/architecture.md.

Protocol evolution is tracked in versioned design docs under docs/design/:

QDP Title Status
0001 Global Nonce Ledger Landed
0002 Guardian-Based Recovery Landed
0003 Cross-Domain Nonce Scoping Landed
0004 Phase H Roadmap Landed
0005 Push-Based Gossip (H1) Landed
0006 Guardian Resignation (H6) Landed
0007 Lazy Epoch Propagation (H4) Landed
0008 K-of-K Snapshot Bootstrap (H3) Landed
0009 Fork-Block Migration Trigger (H5) Landed
0010 Compact Merkle Proofs (H2) Landed
0012 Domain Governance (cache/consortium/governor roles) Draft
0013 Network Federation Model (one protocol, many networks) Draft
0014 Node Discovery + Domain Sharding (operator → nodes, well-known discovery, quid index) Landed
0015 Content Moderation & Takedowns (append-only + legal compliance) Draft
0016 Abuse Prevention & Resource Limits (multi-layer rate limiting) Draft
0017 Data Subject Rights & Privacy (GDPR/CCPA compliance) Draft
0018 Observability + Tamper-Evident Operator Log Draft
0019 Reputation Decay & Time-Weighted Trust Draft
0020 Protocol Versioning & Deprecation Draft

When to use Quidnug — and when not to

Strong fit:

  • Your data model has "who trusts whom" as a first-class question. Reputation, credentials, consortium fraud detection, cross-org approvals.
  • Your keys must be recoverable without central escrow. Institutional custody, high-value signing, long-lived credentials.
  • You need replay-safe, auditable state transitions without global consensus. Most internal/consortium systems don't need "everyone agrees on one chain" — they need "this specific party signed this specific action and I can verify it didn't get replayed."
  • You need coordinated protocol upgrades across a federated set of operators. Fork-block transactions (QDP-0009) give you on-chain, operator-queryable activation boundaries.

Weak fit:

  • High-TPS payment rails — Quidnug prioritizes auditability and correctness over raw throughput. Target: thousands of tx/sec per node with aggressive tuning, not millions.
  • Fully-public permissionless chains — the proof-of-trust model assumes some initial trust seeding. A truly open network without prior trust relationships would behave as an untrusted gossip graph (still correct, just not useful).
  • Systems that need a single universal score — Quidnug refuses to produce one by design. You can build an aggregator on top, but the protocol itself won't give you "what is Alice's reputation?"

Installation & deployment

Dependencies

Go 1.25+, optional IPFS node for large-payload event streams.

Binary

make build        # → bin/quidnug
make test         # fast unit tests
make test-integration
make lint

Config

Environment variables (see config.example.yaml for YAML equivalents and the full schema):

# Server
PORT=8080
DATA_DIR=/var/lib/quidnug              # node identity + chain + scoreboard persist here
LOG_LEVEL=info
RATE_LIMIT_PER_MINUTE=100

# Node-to-node auth (HMAC)
NODE_AUTH_SECRET=<32-byte hex>
REQUIRE_NODE_AUTH=true

# IPFS for large event payloads
IPFS_ENABLED=true
IPFS_GATEWAY_URL=http://localhost:5001

# Supported domains (write filter)
SUPPORTED_DOMAINS=*.finance.example,*.ai.example

# Operator identity (long-lived; deployable on N nodes)
OPERATOR_QUID_FILE=/etc/quidnug/operator.quid.json

# Peering — three peer sources feed the same admit pipeline
SEED_NODES=["peer1.example:8080","peer2.example:8080"]
PEERS_FILE=/etc/quidnug/peers.yaml      # static, fsnotify-watched
LAN_DISCOVERY=true                       # mDNS on _quidnug._tcp.local.
REQUIRE_ADVERTISEMENT=true               # gate gossip-learned peers
PEER_MIN_OPERATOR_TRUST=0.5              # min OperatorQuid → NodeQuid TRUST
PEER_MIN_OPERATOR_REPUTATION=0.0         # weighted-aggregate gate (0 = off)

# Peer scoring (Phase 4) — quarantine + eviction policy
PEER_QUARANTINE_THRESHOLD=0.4
PEER_EVICTION_THRESHOLD=0.2
PEER_EVICTION_GRACE=5m
PEER_FORK_ACTION=quarantine              # log | quarantine | evict

# Phase H feature flags
ENABLE_NONCE_LEDGER=false                # QDP-0001
ENABLE_PUSH_GOSSIP=false                 # QDP-0005
ENABLE_LAZY_EPOCH_PROBE=false            # QDP-0007
ENABLE_KOFK_BOOTSTRAP=false              # QDP-0008

Persistence

Everything that should survive a restart lives in DATA_DIR:

File What
node_key.json Per-process ECDSA keypair (PKCS8). NodeID is sha256(publicKey)[:16]; persisting the file keeps it stable across restarts.
blockchain.json Block history snapshot. Snapshot every 30 s + on shutdown.
trust_domains.json TrustDomains + DomainRegistry index — dynamic POST /api/v1/domains registrations land here.
pending_transactions.json Pending tx queue.
peer_scores.json Per-peer composite scores + recent-event ring. Snapshot every 5 min.

OPERATOR_QUID_FILE is not in DATA_DIR by convention — it's the long-lived operator identity (often shared across multiple nodes the same operator runs), so it lives somewhere stable like /etc/quidnug/ and gets read-only mounted into containers.

Peering

Three peer sources, all gated by the same admit pipeline (handshake → NodeAdvertisement lookup → operator-attestation TRUST check):

  • SEED_NODES / seed_nodes: — bootstrap list, gossip-discovered peers come from these. Boot retry on 1s/2s/4s/8s/16s/30s backoff until at least one seed responds (Docker DNS races etc.); then steady-state every 5 min.
  • PEERS_FILE / peers_file: — explicit YAML peer list with per-peer allow_private: true for LAN escape hatches. Live-reloaded on file change.
  • LAN_DISCOVERY — mDNS / DNS-SD for home/office/lab. Off by default; opt in.

Per-peer quality scoring (Phase 4) records every interaction (handshake / gossip / query / broadcast / validation) into a decay-weighted composite score; peers below PEER_QUARANTINE_THRESHOLD are excluded from routing, peers below PEER_EVICTION_THRESHOLD sustained beyond PEER_EVICTION_GRACE are dropped from KnownNodes (static-source peers are eviction-immune with a stern operator warning). Scores persist across restarts.

CLI surface for operators:

quidnug-cli quid generate --out /etc/quidnug/operator.quid.json
quidnug-cli peer list                     # known peers + composite scores
quidnug-cli peer show NODE_QUID           # full per-peer breakdown
quidnug-cli peer add ADDR [--allow-private] [--operator-quid Q]
quidnug-cli peer remove ADDR
quidnug-cli peer scan-lan                 # one-shot mDNS browse

API surface: GET /api/v1/peers (full scoreboard, worst-first) and GET /api/v1/peers/{nodeQuid}. The landing page at / surfaces a "Peer health" summary block.

Deployment patterns

See docs/integration-guide.md for:

  • Single-node development
  • Three-node consortium setup
  • TLS termination & reverse-proxy configuration
  • Inter-node HMAC authentication
  • Monitoring (Prometheus scraping)

Integration — SDKs, integrations, tooling

Quidnug ships first-class SDKs covering the full protocol surface (QDPs 0001–0010) in Python, Go, JavaScript, and Rust, plus scaffolds for Java/Kotlin, C#/.NET, Swift, and Android. See docs/integration-guide.md for side-by-side examples of the same workflow in every language.

Client SDKs

Core protocol SDKs:

Language Path Status Package
Python 3.9+ clients/python/ full — typed dataclasses, ECDSA P-256, Merkle verifier pip install quidnug
Go 1.25+ pkg/client/ full — context-aware, typed, OTel hooks go get github.com/quidnug/quidnug/pkg/client
JavaScript / TypeScript clients/js/ full — v1 + v2 mixin for guardians/gossip/merkle npm install @quidnug/client
Rust stable clients/rust/ full — async reqwest, wiremock-tested cargo add quidnug
Java 17+ / Kotlin clients/java/ scaffold — keypair + signing —
C# / .NET 8 clients/dotnet/ scaffold — keypair + signing —
Swift iOS/macOS clients/swift/ scaffold — CryptoKit-based —
Android (Kotlin) clients/android/ scaffold — planned Android Keystore integration —
Browser extension (MV3) clients/browser-extension/ scaffold —
ISO 20022 mapping clients/iso20022/ scaffold —
CLI cmd/quidnug-cli/ full — wraps the Go SDK go install .../cmd/quidnug-cli@latest

Reviews use case (QRP-0001) drop-in packages:

Package Path Status Install
@quidnug/web-components clients/web-components/ full — custom elements + <qn-aurora> / <qn-constellation> / <qn-trace> visualization primitives npm install @quidnug/web-components
@quidnug/reviews-widget clients/reviews-widget/ full — one-line HTML embed <script src=".../loader.js">
@quidnug/react-reviews clients/react-reviews/ full — hooks + components + React primitive wrappers npm install @quidnug/react-reviews
@quidnug/vue-reviews clients/vue-reviews/ full — Vue 3 primitive wrappers npm install @quidnug/vue-reviews
@quidnug/astro-reviews clients/astro-reviews/ full — SSR-first, emits real SVG at build time npm install @quidnug/astro-reviews
WordPress plugin clients/wordpress-plugin/ full — WooCommerce integration WP plugin upload
Shopify app clients/shopify-app/ scaffold —

See examples/reviews-and-comments/ for the end-to-end working demo (16 identities, 15 reviews, 3 divergent per-observer ratings rendered in-browser against a live node) and docs/reviews/rating-visualization.md for the rating-visualization design.

All canonical-bytes signing (the operation the node verifies) is byte-for-byte compatible across every SDK. A signature produced in Python verifies in Go, Rust, JavaScript, or on the reference node. See schemas/types/canonicalization.md.

Domain integrations

Turn-key adapters that bring Quidnug's per-observer trust into a specific ecosystem.

Integration Path Status
Sigstore / cosign integrations/sigstore/ shipping — record verified cosign bundles on artifact titles
C2PA integrations/c2pa/ shipping — record verified C2PA manifests on media-asset titles
HL7 FHIR integrations/fhir/ shipping — record FHIR R4/R5 resources on patient / practitioner / org titles
Chainlink External Adapter integrations/chainlink/ shipping — expose relational-trust to on-chain smart contracts
Kafka bridge integrations/kafka/ shipping — event-stream mirror into Kafka topics
ISO 20022 integrations/iso20022/ shipping — convert SWIFT MX / pacs.008 to Quidnug wire-approval titles
Schema.org reviews integrations/schema-org/ shipping — emit Review / AggregateRating JSON-LD for SEO
OIDC bridge cmd/quidnug-oidc/ shipping — bind IdP subjects (Okta/Auth0/Azure/Keycloak) to Quidnug quids
gRPC gateway integrations/grpc/ scaffold — proto schemas + grpc-gateway wiring
GraphQL gateway integrations/graphql/ scaffold — single-round-trip query surface
WebSocket push integrations/websocket/ scaffold — real-time event subscription protocol
Terraform provider integrations/terraform/ scaffold — declarative management of domains + guardian sets
Ledger Nano app integrations/ledger/ scaffold — hardware-wallet signing app
MQTT bridge integrations/mqtt/ scaffold — IoT-device event bridge
Postgres extension integrations/postgres/ scaffold — SQL function exposing relational trust
Elastic / OpenSearch integrations/elastic/ scaffold — event ingester

Signing backends

Plug any of these into the signer.Signer interface instead of using in-process private keys.

Backend Path When to use
PKCS#11 / HSM pkg/signer/hsm/ SoftHSM, YubiHSM, Thales Luna, AWS CloudHSM, Azure Key Vault HSM, GCP HSM.
WebAuthn / FIDO2 pkg/signer/webauthn/ Touch ID, Windows Hello, passkeys, YubiKey.

Deployment + observability

Asset Path Purpose
Helm chart deploy/helm/quidnug/ Production-grade StatefulSet with PVCs, PDB, anti-affinity.
Docker Compose consortium deploy/compose/ Three-node dev network with IPFS + Prometheus + Grafana.
Grafana dashboard deploy/observability/grafana-dashboard.json Importable dashboard covering the full quidnug_* metric family.
Prometheus alerts deploy/observability/prometheus-alerts.yml Production-ready alert rules.
Postman collection docs/postman/quidnug.postman_collection.json Importable collection covering every API endpoint.

CI / testing

  • .github/workflows/sdk-matrix.yml — parallel matrix CI for Go, Python (3.9–3.13), Node 18/20/22, Rust stable, and Helm-chart lint.
  • Each SDK ships its own tests; schemas/ provides language-agnostic JSON schemas ensuring all bindings produce byte-identical wire transactions.

Prometheus metrics

All operational metrics exposed at /metrics. The Grafana dashboard at deploy/observability/grafana-dashboard.json is importable as-is.

Comparison with alternative systems

Quidnug Bitcoin/Ethereum Traditional DB OAuth/OIDC
Trust model Relational, per-observer Universal consensus Centralized Federated central
Identity Self-sovereign (quids) Self-sovereign (addrs) Platform-owned Provider-owned
Key recovery Guardian M-of-N + time-lock Seed phrase Email reset Provider reset
Throughput Moderate (consortium-scale) Low (mainnet) Very high Very high
Replay protection Per-signer monotonic nonce Transaction hash uniqueness App-level JWT jti
Multi-party approval First-class (M-of-N, guardians) Smart contract App-level Not native
Best for Cross-org trust, high-value Global money / dApps Single-org data Login federation

Contributing

See CONTRIBUTING.md and CODE_OF_CONDUCT.md.

make test       # unit tests
make test-integration
make lint

Design docs for new features go in docs/design/ as a numbered QDP (Quidnug Design Proposal). Current template: look at any of 0001–0010.

Security

Vulnerability reports: see SECURITY.md. Do not open public issues for security problems.

License

Apache License, Version 2.0. See LICENSE and NOTICE.

About

A decentralized cryptographic platform for trust, identity, and ownership.

Resources

Readme
Apache-2.0 license

Code of conduct

Code of conduct

Contributing

Contributing

Security policy

Security policy
Activity

Stars

4 stars

Watchers

1 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors

Languages
0