xStore: Universal Split-Storage

Fast Onboarding: 3 Acceleration Levels

From zero-click code patterns to one-click deploy buttons, xStore offers three acceleration levels that reduce setup time from ~2 minutes to as low as ~15 seconds. Each level targets a different deployment context.

Level 1: Zero-Click Accept (Lazy Store Initialization)

For trusted environments, the lazy store pattern defers backend configuration until the first storage operation. No explicit init() call required — the store automatically configures its backends on first use and auto-accepts backend connections from known partners.

import { XStore } from '@private.me/xstore';

// Store configures backends on first operation
const store = await XStore.lazy({
  name: 'my-storage'
});

// First put() triggers backend initialization automatically
const data = new TextEncoder().encode('Sensitive data');
await store.put('my-key', data);

// Retrieve data (reconstruction happens transparently)
const result = await store.get('my-key');

Setup time: ~80 seconds (backend initialization happens transparently during first operation)
Best for: Internal services, trusted partner integrations, development/testing

Level 2: One-Line CLI Setup (Invite-Based)

For production deployments, the one-line CLI command accepts an invite code and automatically configures the entire backend topology, credentials, and threshold settings in a single operation. No manual backend configuration, no credential juggling.

// Partner sends you invite code: XST-abc123def456
$ npx @private.me/xstore-cli init --invite XST-abc123def456

{
  "status": "initialized",
  "name": "my-storage",
  "backends": [
    {
      "id": "s3-us-east",
      "type": "s3",
      "region": "us-east-1"
    },
    {
      "id": "azure-eu-west",
      "type": "azure-blob",
      "region": "westeurope"
    },
    {
      "id": "local-fs",
      "type": "filesystem",
      "path": "/var/xstore/shares"
    }
  ],
  "threshold": 2,
  "totalShares": 3,
  "elapsed_seconds": 2.3
}

Setup time: ~40 seconds (single command, no manual configuration)
Best for: Production deployments, multi-cloud setups, compliance-driven topologies

Level 3: Deploy Button (One-Click Infrastructure)

For platform integrations, deploy buttons provide one-click infrastructure provisioning with xStore pre-configured. Clicking the button deploys a complete service with backend topology, credentials, and threshold configuration already set.

<!-- Add to your README.md or integration docs -->
[![Deploy to Vercel](https://vercel.com/button)](https://vercel.com/new/clone?repository-url=https%3A%2F%2Fgithub.com%2Fprivate-me%2Fxstore-starter&env=XSTORE_INVITE_CODE&envDescription=Paste%20your%20xStore%20invite%20code%20here&envLink=https%3A%2F%2Fprivate.me%2Fdocs%2Fxstore)

// Deployed service includes:
// - Auto-configured backend topology (S3, Azure, IPFS)
// - Pre-configured threshold settings from invite
// - API endpoints for put/get operations
// - Health check and monitoring

Setup time: ~15 seconds (one click, zero configuration)
Best for: SaaS integrations, marketplace apps, rapid prototyping

Setup Time Comparison

Getting Started: Fastest Path

The recommended onboarding path depends on your deployment context:

1. New to xStore? Start with a Deploy Button to see xStore running in production in ~15 seconds. Deploy the starter template, then explore the code.
2. Production deployment? Use the One-Line CLI with an invite code. One command configures your entire backend topology in ~40 seconds.
3. Internal services? Use Zero-Click Accept with lazy initialization. No setup time, backend configuration happens transparently on first use.
4. Want full control? Follow the standard 2-minute setup flow with explicit backend configuration.

// 1. Click "Deploy to Vercel" button (~15 sec)
// 2. Paste invite code when prompted
// 3. Service deploys with xStore pre-configured
// 4. Clone the deployed repo to see the code:

$ git clone https://github.com/your-username/deployed-xstore-service
$ cd deployed-xstore-service
$ cat src/index.ts

// You'll see the lazy store pattern in action:
const store = await XStore.lazy({ name: 'deployed-storage' });
app.post('/store', async (req, res) => {
  const result = await store.put(req.body.key, req.body.data);
  res.json(result);
});

Executive Summary

Every ACI reinvents storage. xStore eliminates the problem by providing a universal split-storage layer that abstracts XorIDA share persistence behind a pluggable backend interface.

Two functions cover 80% of use cases: store.put() splits data via XorIDA into k-of-n shares, computes HMAC-SHA256 per share, routes each to a designated backend (AWS S3, Azure Blob, filesystem, or custom), and returns a manifest with backend routing + integrity tags. store.get() fetches k shares, verifies HMAC on each before reconstruction, XorIDA-reconstructs the data, and returns the original byte-identical payload.

No keys. No rotation. No cross-backend consistency logic. xStore handles the storage orchestration; your application handles the business logic. Move from S3 to GCP by swapping a backend implementation — zero application code changes. Store Share 1 in the EU and Share 2 in the US for compliance. Keep Share 3 on an air-gapped filesystem for disaster recovery.

One universal abstraction. Backends are pluggable. Manifests are portable. Integrity is cryptographic. Threshold is configurable (k-of-n). Zero npm dependencies at the core.

Developer Experience

xStore provides progress callbacks for multi-backend visibility, structured error codes with recovery guidance, and a minimal API surface. Track uploads across regions. Handle failures gracefully. Debug storage orchestration with confidence.

Progress Callbacks

Every put() and get() operation accepts optional progress callbacks that emit per-backend status updates. Real-time visibility into which shares are being written to which backends.

const result = await store.put('large-dataset', data, {
  onProgress: (event) => {
    console.log(`Backend ${event.backendId}: share ${event.shareIndex}/${event.totalShares}`);
    console.log(`Status: ${event.status} | ${event.bytesTransferred}/${event.totalBytes} bytes`);
  }
});

Error Codes

15+ error codes across 5 categories: Backend Management, Share Operations, Data Operations, and more. Every error includes code, message, and recovery guidance.

The Problem

Every ACI that splits data with XorIDA writes its own storage logic. There is no standard interface, no backend portability, and no cross-ACI reuse.

When data is split into k-of-n shares, those shares must be stored across independent backends. Today, each application hardcodes where shares go — one app stores on S3, another on local disk, another in a database. There is no common abstraction, no manifest format, no integrity verification at the storage layer.

This creates three problems: Backend lock-in (moving from AWS to Azure means rewriting storage code), No portability (shares from one ACI cannot be consumed by another without bespoke integration), and No integrity guarantees (corrupted shares are discovered only at reconstruction time, when it is too late).

Use Cases

Architecture

Five-stage pipeline: pad, authenticate, split, route, store. Every stage independently verifiable. Manifest ties it all together.

Pluggable Backend Interface

The StorageBackend interface defines three methods: put, get, and delete. Any storage system implementing this interface can serve as a share backend. Zero application-layer changes to swap backends.

interface StorageBackend {
  readonly id: string;
  put(key: string, data: Uint8Array): Promise<Result<void>>;
  get(key: string): Promise<Result<Uint8Array>>;
  delete(key: string): Promise<Result<void>>;
}

ACI Interface

Complete Flow: Multi-Cloud 2-of-3 Storage

This example demonstrates xStore's core value: one interface, multi-backend orchestration, information-theoretic security.

import { createStore } from '@private.me/xstore';

// Configure three cloud backends
const s3 = new S3Backend({ region: 'us-east-1', bucket: 'shares' });
const azure = new AzureBlobBackend({ account: 'eu-storage', container: 'shares' });
const gcp = new GCPStorageBackend({ project: 'xstore', bucket: 'apac-shares' });

// Universal split-storage: 2-of-3 threshold
const store = createStore({
  backends: [s3, azure, gcp],
  threshold: { k: 2, n: 3 },
});

// Store 10MB dataset
const data = new Uint8Array(1024 * 1024 * 10);
const putResult = await store.put('patient-genome', data, {
  onProgress: (event) => {
    console.log(`Backend ${event.backendId}: ${event.status} | ${event.bytesTransferred}B`);
  }
});

const manifest = putResult.value;

// Later: retrieve from any 2 of 3 backends
const getResult = await store.get(manifest);
// getResult.value is byte-identical to data, HMAC-verified

Security Properties

xStore inherits XorIDA's information-theoretic guarantees and adds storage-layer integrity, manifest authentication, and backend isolation.

vs. Traditional Encryption

Benchmarks

Performance characteristics measured on Node.js 22, Apple M2. xStore adds minimal overhead while eliminating single-point-of-compromise risk.

Honest Limitations

Five known limitations documented transparently. xStore trades storage efficiency for security guarantees.

Cross-ACI Composition

xStore is the storage layer that other ACIs build on. Instead of each product reinventing share persistence, they delegate to xStore and focus on domain logic.

Get Started

Install xStore, implement a backend, and start storing threshold-split data in minutes.

npm install @private.me/xstore

import { createStore } from '@private.me/xstore';
import { S3Backend, AzureBackend, FsBackend } from './backends';

const store = createStore({
  backends: [
    new S3Backend({ bucket: 'shares-us-east' }),
    new AzureBackend({ container: 'shares-eu-west' }),
    new FsBackend({ path: '/mnt/airgap/shares' }),
  ],
  threshold: { k: 2, n: 3 },
});

const data = new TextEncoder().encode('patient record');
const { value: manifest } = await store.put('record-123', data);
const { value: restored } = await store.get(manifest);
// restored is byte-identical to data

Verifiable Split-Storage

Every xStore operation produces integrity artifacts that xProve can chain into a verifiable audit trail. Prove correct storage without revealing the data itself.

Enterprise CLI

Self-hosted split-storage server. Deploy xStore on your own infrastructure with Docker-ready, air-gapped capable deployment.

xStore Universal Split-Storage

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