Loading...
private.me Docs
Explore ACIs
PRIVATE.ME PLATFORM

xGit: Protected Code Distribution

Push noise. xGit integrates XorIDA splitting into your git and npm workflows. Pre-push hooks split your code into cryptographic noise — customers npm install and get noise. Runtime reconstructs via xGhost. Your code distributes everywhere. Exists nowhere.

Code Distribution COMING SOON 201 Tests XorIDA Powered
COMING SOON — DEVELOPER WORKFLOW
xGit is the developer workflow layer for xGhost. While xGhost handles the runtime protection (split/reconstruct/purge), xGit handles distribution — integrating XorIDA splitting into git hooks, CI/CD pipelines, and npm publish. Combined with xPass billing enforcement, it creates a double-lock distribution model.
Section 01

The Problem

Code distributed via git and npm is readable. Every npm install delivers plaintext source. Every git clone copies your IP. Obfuscation is reversible. License keys are shareable. Your algorithm becomes someone else's the moment you publish.

SDK vendors, open-core companies, and AI model distributors face the same dilemma: distribute code to customers (and accept piracy, reverse engineering, and license violations) or keep it server-side only (and accept latency, connectivity requirements, and architectural constraints).

Current approaches fail at the distribution layer:

ApproachWhat You ShipWhat They Get
npm publishPlaintext sourceYour entire codebase
ObfuscationMangled sourceDe-obfuscatable code
License keyPlaintext + key checkCode + removable check
Private registryAccess-controlled plaintextPlaintext once downloaded

The Distribution Gap

git push (plaintext) npm install (plaintext) node_modules/ (your source) Distribute code = lose code
Section 02

The Solution

xGit integrates XorIDA splitting into the code distribution workflow. A pre-push hook or CI action splits your code into shares before it leaves your machine. What gets pushed to the registry is cryptographic noise. Share 2 auto-uploads to your heartbeat server.

Customers npm install your package and get Share 1 — noise that reveals zero information about your code. Not obfuscated code. Not minified code. Actual cryptographic noise. Information-theoretically. At runtime, xGhost handles per-call reconstruction.

The developer workflow is transparent: git push and npm publish work exactly as before. xGit hooks into the pipeline and splits automatically. No changes to your build process. No changes to your customer's install process.

The xGit Way

git push pre-push hook Share 1 (noise) npm registry Share 2 (noise) heartbeat server npm install gets noise xGhost reconstruct Run
Key Insight
xGit handles distribution. xGhost handles runtime. xPass handles billing. Three ACIs, three layers, one integrated protection stack. Customers experience a normal npm install. You experience a normal git push. The cryptography is invisible.
Section 03

How It Works

xGit adds a protection layer between your source code and the distribution channel. Four steps: init, protect, push, install. Each step is automated — no manual cryptography.

XGIT DISTRIBUTION PIPELINE 1. xgit init Configure repo Install git hooks 2. xgit protect Mark exports Set threshold 3. git push Hook triggers split Upload vendor share 4. npm install Customer gets noise xGhost reconstructs PROTECTION STACK LAYER 1 xGit — Distribution Protection Pre-push hook + CI/CD + npm publish integration LAYER 2 xGhost — Runtime Protection Per-call reconstruct/execute/purge + 30s heartbeat LAYER 3 xPass — Billing Enforcement XorIDA-embedded billing + MPC session binding
Transparent Integration
xGit works with your existing toolchain. No changes to package.json scripts. No changes to CI/CD build steps. No changes to customer install commands. The pre-push hook intercepts after your build and before the push — your normal workflow stays identical.
Section 04

Developer Workflow

xGit provides a CLI and CI/CD integrations that make protecting your code as simple as pushing to git. Four commands cover the entire lifecycle.

CLI Commands

xGit Command Line Interface
# Initialize xGit in your repository
xgit init --server https://heartbeat.yourcompany.com
  → Installs pre-push hook
  → Creates .xgit/config.json
  → Configures heartbeat server endpoint

# Mark files and exports for protection
xgit protect --source src/algorithm.ts --exports "score,classify,predict"
  → Adds protection manifest entry
  → Configures XorIDA threshold (default 2-of-2)

# Check protection status
xgit status
  → Protected files: 3
  → Exports: score, classify, predict
  → Heartbeat: https://heartbeat.yourcompany.com (connected)
  → Last split: 2026-04-03T10:30:00Z

# Revoke access for a customer DID
xgit revoke --did "did:key:z6Mk..."
  → Removes DID from heartbeat server license list
  → Customer's next heartbeat fails → code stops within 30s

GitHub Actions Integration

.github/workflows/xgit-protect.yml
name: xGit Protected Publish
on:
  push:
    tags: ['v*']

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci && npm run build
      # xGit splits before publish
      - run: npx xgit protect --ci
        env:
          XGIT_SERVER: ${{ secrets.HEARTBEAT_URL }}
          XGIT_API_KEY: ${{ secrets.HEARTBEAT_KEY }}
      # Publish noise to npm
      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

GitLab CI Integration

.gitlab-ci.yml
xgit-publish:
  stage: deploy
  script:
    - npm ci && npm run build
    - npx xgit protect --ci
    - npm publish
  only:
    - tags
npm Publish Integration
xGit hooks into the npm publish lifecycle via a prepublishOnly script. When you run npm publish, xGit automatically splits your protected files, uploads vendor shares to your heartbeat server, and replaces the source with Share 1 (noise) in the published package. The published tarball contains noise. Your node_modules/ stays untouched locally.
Section 05

Self-Protection: We Eat Our Own Dogfood

PRIVATE.ME uses xGit + xGhost + xPass to distribute its own ACIs. Every npm install @private.me/* delivers noise. This is the double-lock distribution model.

PRIVATE.ME DOUBLE-LOCK DISTRIBUTION Lock 1: IP Protection xGit splits at publish • xGhost at runtime Can't reverse-engineer — it's noise Lock 2: Billing Enforcement xPass embeds billing in encryption Can't skip payment — need shares Double Lock Stop paying → both locks engage within 30 seconds npm install @private.me/xlink → noise
DOGFOODING PROOF
Every ACI in the PRIVATE.ME catalog is distributed via xGit. When a customer runs npm install @private.me/xlink, they get Share 1 — cryptographic noise. The xGhost runtime handles per-call reconstruction. xPass enforces billing. If we trust it to protect our own revenue, you can trust it to protect yours.
Section 06

Use Cases

📦
SDK Vendors
npm SDK Distribution

Publish your SDK to npm as noise. Customers npm install and get a working package — but the source is cryptographic noise. No obfuscation needed. No license key validation. The protection is information-theoretic.

Anti-Piracy
🔓
Open-Core
Protect Premium Features

Open-source your community edition normally. Protect premium modules with xGit — xgit protect marks which exports are premium. Community code ships as plaintext. Premium code ships as noise.

Open-Core Model
🤖
AI / ML
Model Weight Distribution

Distribute trained models as XorIDA shares. Customers run inference via xGhost reconstruction. Model weights never exist as plaintext on customer machines. Piracy of fine-tuned models stops.

Model Security
📈
FinTech
Trading Algorithm Firms

Ship proprietary trading algorithms to on-prem customer infrastructure via npm. Customers get native-speed execution. You keep IP control. Subscription lapse = code stops within 30 seconds.

Proprietary IP
🎮
Gaming
Game Logic Distribution

Distribute server-authoritative game logic as noise. Anti-cheat algorithms, matchmaking engines, and economy balancing code are protected at the distribution layer — before they even reach the player.

Anti-Cheat
🏢
Enterprise SaaS
On-Prem Deployment

Ship enterprise software to customer data centers via npm packages. Customers install and run locally — but the code is noise. Your pricing engine, recommendation algorithm, and core IP stay protected.

On-Prem Protection
Section 07

Integration

Initialize xGit in Your Repository
// Initialize xGit in your project
$ xgit init --server https://heartbeat.yourcompany.com

// Mark exports for protection
$ xgit protect --source src/engine.ts \
    --exports "score,classify,predict,optimize"

// Push normally — hook handles the split
$ git add . && git commit -m "feat: new scoring model"
$ git push origin main
  → [xgit] Splitting 4 protected exports...
  → [xgit] Share 1 → dist/ (noise)
  → [xgit] Share 2 → heartbeat.yourcompany.com (uploaded)
  → [xgit] Manifest → dist/xgit-manifest.json
  → Push complete.
Customer Side — Normal npm Install
// Customer installs your package normally
$ npm install @yourcompany/scoring-engine

// Usage — identical to a normal import
import { score, classify } from '@yourcompany/scoring-engine';

// Under the hood: xGhost fetches Share 2, reconstructs, executes, purges
const result = await score(inputData);
// result is the output — the algorithm existed for ~50µs
xgit init --server <url>
Initializes xGit in the current repository. Installs the pre-push git hook, creates .xgit/config.json with heartbeat server endpoint, and generates a vendor DID for authentication.
xgit protect --source <file> --exports <names>
Marks specific file exports for XorIDA protection. Adds entries to the protection manifest. Supports glob patterns for multiple files. Configurable threshold (default 2-of-2), heartbeat interval (default 30s), and export filtering.
xgit status
Shows current protection status: protected files, exported functions, heartbeat server connectivity, last split timestamp, and customer license count.
xgit revoke --did <did:key:...>
Revokes access for a specific customer DID. Removes the DID from the heartbeat server license list. Customer's next heartbeat check fails, and code stops functioning within 30 seconds.
Section 08

Enhanced Identity with Xid

xGit can optionally integrate with Xid to enable unlinkable commit attribution — verifiable within each repository context, but uncorrelatable across projects or time.

Three Identity Modes

Basic (Default)
Static DIDs
One DID per developer, persistent across all commits and repositories. Simple, but linkable — same identity can be tracked across projects.
Current xGit behavior
xGit+ (With Xid)
Ephemeral Per-Commit DIDs
Each commit gets a unique DID derived from an XorIDA-split master seed. DIDs are unlinkable across repositories and rotate per epoch. Verifiable within repo context, but cross-repo correlation is impossible. ~50µs overhead per commit.
Unlinkable attribution
xGit Enterprise
K-of-N Converged High-Assurance Commits
Require 3-of-5 signals (biometric + device TPM + location + time + YubiKey) to generate a commit DID. IAL2/3 assurance levels for classified, financial, or compliance repos. Continuous refresh ensures only authorized team members can commit.
IAL2/3 compliance

How Ephemeral DIDs Work

Developer Workflow (xGit+ with Xid)
// Initialize xGit with Xid integration
$ xgit init --identity-mode ephemeral

// Commit as usual — xGit derives ephemeral DID automatically
$ git commit -m "feat: Add new feature"
  → [xGit] Deriving ephemeral DID from master seed...
  → [xGit] DID: did:key:z6MkA... (unique to this commit + repo + epoch)
  → [xGit] Signed commit with ephemeral key (~50µs)
  → [xGit] Key purged (<1ms exposure)

// Commit is signed with unlinkable DID
// Verification works within repo, but cross-repo correlation fails

What This Enables

  • Cross-repo unlinkability — Can't track developers across projects
  • Per-verifier derivation — Same developer has different DIDs per repo
  • Epoch rotation — DIDs automatically rotate daily/weekly/monthly
  • Split-protected derivation — Master seed is XorIDA-split, never reconstructed
  • eIDAS 2.0 ARF compliance — Meets EU unlinkability requirements
Integration Pattern
xGit+ is not a new ACI — it's an integration of two existing ACIs (xGit + Xid). This demonstrates ACI composability — building blocks combine to create enhanced capabilities without requiring new primitives.

See the Xid white paper for details on ephemeral identity primitives and K-of-N convergence.

Integration Tiers

Tier Capabilities ACIs Used
xGit Basic Static DIDs, basic watermarking xGit only
xGit+ Ephemeral unlinkable DIDs, epoch rotation xGit + Xid
xGit Enterprise K-of-N high-assurance commits, IAL2/3 xGit + Xid + Xfuse

Target Markets

  • Software vendors (anti-piracy) — Ship protected npm packages to customer data centers. Unlinkable commit attribution prevents piracy tracking while maintaining developer accountability. Enterprise customers install cryptographic noise—runtime reconstructs via licensed keys. Revocation window: 30 seconds.
  • Defense contractors — Classified repos with IAL3 commits, cross-context unlinkability for compartmentalized projects
  • Financial services — SOX/SEC compliance with verifiable but unlinkable attribution for algorithmic trading code
  • Healthcare/Pharma — HIPAA-compliant repos, unlinkable commits protect researcher identity across trials
Section 09

Security Properties

PropertyMechanismGuarantee
Distribution ConfidentialityXorIDA 2-of-2 splitting at pushPublished package = zero information (information-theoretic)
Runtime ProtectionxGhost per-call reconstruct/purge~50µs code exposure per function call
AuthorizationxLink 30s heartbeatDID-authenticated, timestamp-bound, nonce replay prevention
Billing EnforcementxPass MPC session bindingCannot decrypt without active subscription
Share IntegrityHMAC-SHA256 per shareTampered shares rejected before reconstruction
Audit TrailxProve HMAC chainTamper-evident log of all reconstructions

Competitive Comparison

ApproachWhat ShipsCryptographic?Revocable?Billing Enforced?
npm publishPlaintext sourceNoNoNo
ObfuscationMangled sourceNoNoNo
License keySource + key checkNoPartiallyBypassable
Private registryAccess-gated plaintextNoAccess onlyNo
SaaS-onlyNothing (API)N/AYesYes
xGitNoiseYes (XorIDA)30sxPass
0 bits
Info per share
~50µs
Code exposure
30s
Revocation window
3
Protection layers
Section 10

Contributor Access Model

External developers need to read, modify, and submit changes to protected code — without permanently exposing plaintext. xGit provides session-gated, per-file, watermarked access with automatic revocation.

Three Contributor Tiers

TierAccessSessionFile QuotaCapabilities
ReviewerDiff only2 hours10 filesRead diffs, comment
ContributorFull source8 hours50 filesRead, write, create PRs
MaintainerFull repo24 hoursUnlimitedRead, write, merge, manage

Session-Gated Share Delivery

Contributors never clone the full repository. Instead, they start a time-limited session that delivers Share 2 per-file on demand. Every file access is logged, quota-checked, and bound to the contributor’s DID.

SESSION LIFECYCLE
Start → License verified, DID authenticated, billing checked via xPass, session created with TTL.
Heartbeat → 30-second interval refreshes session. License revocation detected within one heartbeat — immediate eviction.
Work → Per-file Share 2 delivery. XorIDA reconstruction. DID watermark embedded. Quota enforced.
End → Session marked expired. All cached shares zero-filled. Audit log finalized.

DID-Based Watermarking

Every file reconstruction embeds a steganographic watermark derived from the contributor’s DID. The fingerprint is encoded as trailing whitespace patterns (invisible in editors) and is deterministic: same source + DID = same watermark. If leaked code surfaces, extractWatermark() identifies the contributor.

Server-Side Code Review

Reviewers never see full source. The server reconstructs both base and PR versions, computes a unified diff, then zero-fills both buffers. Reviewers see only the changed lines — never the surrounding context beyond a 3-line window.

Push & PR Workflow

When a contributor pushes, xGit automatically:

1. Strips the watermark from modified files.
2. Re-splits via ghostBuild() (2-of-2 XorIDA).
3. Stores the new vendor share (encrypted at rest, AES-256-GCM).
4. Returns the customer share (noise) for the git commit.
5. Signs the commit hash with the contributor’s Ed25519 identity.

Pull requests follow the same merge model: maintainers merge the noise branch in git, and xGit promotes the PR’s vendor shares to the main branch.

Access Control

SeatxPass ScopeAccess Level
Reviewerxgit:reviewDiff-only, read access
Contributorxgit:contributorRead + write, limited files
Maintainerxgit:adminFull repository access

Enforced via xPass: createConnectionId(orgDID, contributorDID, scope). Revocation takes effect within 30 seconds.

30s
Revocation window
3 tiers
Access control
Per-file
Share delivery
DID
Watermarked
SECTION 10

CLI Toolkit

The @private.me/xgit-cli package provides a complete command-line interface for managing protected repositories. Eight commands cover the full lifecycle: initialization, file protection, server operation, contributor management, audit queries, and key generation.

Commands

CommandPurpose
xgit initInitialize a protected repository — creates record + generates repo ID
xgit protectSplit source files into XorIDA noise + store vendor shares encrypted
xgit serveStart the contributor access server (16 API routes)
xgit statusShow session state, license info, quota usage
xgit add-contributorCreate a contributor license (reviewer/contributor/maintainer)
xgit revokeRevoke a contributor’s access (takes effect within 30 seconds)
xgit auditQuery the contribution audit log with DID/action/time filters
xgit keygenGenerate a fresh AES-256 encryption key + .env template

Quick Start

# Generate encryption keys
$ xgit keygen

# Initialize a protected repository
$ xgit init --repo my-project

# Protect source files (split into noise + vendor shares)
$ xgit protect "src/**/*.ts" --repo my-project

# Start the contributor access server
$ xgit serve --port 3200

# Add a contributor
$ xgit add-contributor --did did:key:z6Mk... --tier contributor --repo my-project

# Check status
$ xgit status --repo my-project

Deployment

Includes Dockerfile (multi-stage Alpine, non-root, read-only filesystem), docker-compose.yml, and a 10-section deployment guide covering architecture, configuration, backup, monitoring, and emergency procedures. Health check at /health. Structured JSON logging for SIEM integration.

8
CLI Commands
78
CLI Tests
201
Total Tests
Docker
Ready
SECTION 11

Admin Control Panel

A web-based dashboard for managing protected repositories, contributors, sessions, and audit trails. Available at private.me/admin with SSO authentication. Six tabs provide full operational visibility.

Dashboard

Real-time server health, active sessions, protected file count, and contributor totals. Auto-refreshes every 30 seconds.

Dashboard Repos Contributors Sessions Files Audit ACTIVE SESSIONS 3 CONTRIBUTORS 5 PROTECTED FILES 33 REPOSITORIES 1 Server healthy Uptime: 12h 34m Memory: 48 MB Node v22.x
DASHBOARD TAB — REAL-TIME SERVER HEALTH + STATS

Contributors

View, add, and revoke contributor access. Three permission tiers — reviewer (read-only), contributor (read + write), and maintainer (full access). Each row shows the contributor's DID, repository, tier badge, status, and granted scopes.

Dashboard Repos Contributors Sessions Files Audit DID REPO TIER STATUS ACTIONS did:key:z6Mk...ggow privateme-platform contributor active Revoke did:key:z6Mk...uEvy privateme-platform maintainer active Revoke did:key:z6Mk...j7Kp privateme-platform reviewer active Revoke
CONTRIBUTORS TAB — 3-TIER RBAC WITH REVOCATION

Sessions & Files

The Sessions tab shows all active, expired, and revoked sessions with status indicators, time remaining, and files accessed. Filter by status or repository. Auto-refreshes every 15 seconds.

The Files tab lists every protected file path for a selected repository with a client-side search filter and total count.

Dashboard Repos Contributors Sessions Files Audit Status: All Repo: privateme-platform SESSION DID TIER STATUS FILES TIME LEFT sess_a1b2c3 did:key:z6Mk...ggow contributor active 12 23m 45s sess_d4e5f6 did:key:z6Mk...j7Kp reviewer expired 5
SESSIONS TAB — REAL-TIME MONITORING WITH FILTERS

Audit Trail

Every action — session start, file access, heartbeat, expiration — is logged with DID, repository, action type, authorization status, and timestamp. Paginated view with DID, action, and time range filters. Integrate with SIEM via structured JSON logging.

Dashboard Repos Contributors Sessions Files Audit All DIDs Action: All Last 24h DID ACTION DETAIL AUTH TIMESTAMP did:key:z6Mk...ggow session:start privateme-platform Yes 14:23:01 UTC did:key:z6Mk...ggow file:access packages/crypto/src/xorida.ts Yes 14:23:15 UTC
AUDIT TAB — EVERY ACTION LOGGED WITH DID + TIMESTAMP
DEPLOYMENT
The admin panel is a self-contained static HTML page with SSO authentication. Deploy on any static host — no server-side rendering required. API calls are proxied through the main server with admin authorization. Both private.me/admin and xail.io/admin/xgit serve independent copies of the same panel.
Section 11

Benchmarks

Performance characteristics measured on Node.js 22, Apple M2. xGit protects source code with sub-100ms overhead for typical repository operations.

201
Test Cases
~50ms
Protect 100 KB
~33ms
Reconstruct
16
API Routes
OperationTimeNotes
xgit protect 10 KB~5msXorIDA split + HMAC + DID watermark
xgit protect 100 KB~50msTypical source file batch
xgit protect 1 MB~100msLarge file or bundle
Share 1 delivery<1msImmediate delivery to contributor
Share 2 retrieval (session-gated)~5–50msNetwork-dependent, DID auth required
Reconstruct from shares~33msHMAC verify + XOR reconstruction (1 MB)
DID watermark embed<0.1msContributor DID embedded in share metadata
Session validation<1msEd25519 signature + session token check
Audit log entry<0.5msJSONL append with HMAC chain

Source Code Protection Comparison

PropertyGit + Access ControlGitCryptGitHub EnterprisexGit
At-rest protectionNone (plaintext)AES-256-GCMServer-side onlyIT-secure (XorIDA)
Insider threatFull access once clonedFull access with keyAdmin can accessSession-gated shares
Leak traceabilityNoneNoneAudit logDID watermark per contributor
Quantum resistanceNoNo (AES)NoInformation-theoretic
Contributor tiersBranch-levelBinary (has key or not)Role-based3-tier (reviewer/contributor/maintainer)
Section 12

Honest Limitations

Six known limitations documented transparently. xGit’s security model trades some git workflow flexibility for source code protection.

LimitationImpactMitigation
Server connectivity requiredContributors need network access to the xGit server for Share 2 retrieval. Offline development with protected files is not possible without pre-cached shares.Session tokens allow Share 2 caching for the duration of the session (configurable TTL). Contributors working offline can pre-fetch shares before disconnecting.
Binary file support limitedXorIDA splitting works on any binary data, but diff and merge operations are not meaningful for binary files. Only whole-file protection is supported.Binary files are protected as opaque blobs. Version history is maintained via separate snapshots. For large binaries, consider Git LFS integration with xStore backends.
No merge conflict resolutionxGit protects files but does not provide merge tooling. Conflicts in protected files must be resolved in plaintext before re-protecting.Standard git merge tools work on reconstructed plaintext. Re-protect after resolution. The protect/reconstruct cycle adds <100ms overhead per file.
Watermark traceabilityDID watermarks in share metadata enable leak tracing, but a determined leaker could strip metadata before exfiltrating reconstructed plaintext.Watermarks are embedded in the share structure, not the plaintext. Stripping requires understanding the xFormat binary layout. Behavioral monitoring (access patterns) provides a secondary detection layer.
Linear scaling with file countProtecting N files requires N independent XorIDA split operations. Repositories with thousands of files have proportional protect/reconstruct times.Parallel splitting across CPU cores. Incremental protection (only re-protect changed files). Typical repositories protect 10–100 sensitive files, not the entire codebase.
Three fixed contributor tiersThe reviewer/contributor/maintainer model is fixed. Custom roles or fine-grained per-file permissions are not supported.Three tiers cover most organizational structures. Per-repository tier assignment provides granularity. Enterprise deployments can map existing RBAC to the three tiers.
VERIFIED BY XPROVE

Verifiable Code Distribution

Every xGit split and every xGhost reconstruction produces a verifiable audit trail via xProve. HMAC-chained integrity proofs confirm that code was split correctly at publish, reconstructed faithfully at runtime, and purged completely after execution.

XPROVE AUDIT TRAIL
Every xGit distribution event generates HMAC-SHA256 integrity tags. xProve chains these into a tamper-evident audit trail that proves the code was handled correctly at every step — splitting at publish, share upload to heartbeat server, reconstruction at runtime, and purge after execution. Upgrade to zero-knowledge proofs when licensors or auditors need public verification.

Read the xProve white paper →
GET STARTED

Ready to push noise?

Talk to Sol, our AI platform engineer, or book a live demo with our team.

Book a Demo