PICARD

Protocol-Introspecting Chunk Adapter for Resilient Data

For the self-taught, the unconventional, and anyone who was ever told to stay in their lane. Keep building, keep exploring.

PICARD encrypts your data, slices it into chunks, and scatters those chunks across whatever protocol endpoints you configure: DNS TXT records, social media APIs, MQTT brokers, S3 buckets, Bluetooth advertisements, or all of the above at once. Pull it back and it reassembles. With multi-adapter scatter, no single endpoint holds enough ciphertext to reconstruct anything. No central server. No monthly storage fees. It mounts as a regular filesystem.

Not efficient. Protocol-agnostic.

How It Works

plaintext
  → AES-256-GCM encrypt     (Argon2id key, per-block salt + nonce)
  → PCHK chunk              (protocol-sized pieces)
  → scatter across adapters (DNS, Redis, Reddit, S3, MQTT, …)
  → sealed envelope          (HKDF sub-key, correlation tag per adapter)

retrieve
  ← fan out to all adapters
  ← collect, verify, assemble
  ← decrypt

Each block is independently encrypted with its own random salt and nonce. Chunks scatter round-robin or via RAID profiles. No adapter sees plaintext; no adapter sees enough ciphertext to reconstruct anything.

The local index (an AES-256-GCM encrypted SQLite database) maps paths to chunk locations. Lose the passphrase, lose the data.

Web Dashboard

picard web opens a browser dashboard at http://localhost:8471.

Storage surface by category, adapter health, and encryption details at a glance.

259 adapters browsable by category, with required parameters and one-click add.

Quickstart

pip install picard-store

export PICARD_PASSPHRASE="your-passphrase"   # or picard will prompt

picard init                                  # create picard.toml

# edit picard.toml to add your adapters, then:
picard put myfile.txt --as /docs/myfile.txt
picard get /docs/myfile.txt -o recovered.txt
picard ls
picard tree /

From source:

git clone https://github.com/neitzert/picard
cd picard
pip install -e ".[dev]"
python -m pytest --tb=short -q

Configuration

# picard.toml

[general]
block_size = 65536

[[adapters]]
name       = "dns-primary"
type       = "dns"
enabled    = true
params     = { nameserver = "10.10.10.10", domain = "chunks.example.com" }

[[adapters]]
name       = "s3-backup"
type       = "s3"
enabled    = true
tor_proxy  = true              # route through Tor SOCKS5
params     = { bucket = "picard-chunks", prefix = "data/" }

[[adapters]]
name         = "reddit-stash"
type         = "reddit"
enabled      = true
browser_mode = "headed"        # api | headless | headed
params       = { subreddit = "u_myuser" }

[[raid]]
level    = "raid5"
adapters = ["dns-primary", "s3-backup", "filesystem"]

[scatter.paranoid]
raid_level   = "raid10"
min_adapters = 4

Scatter profiles: quiet, resilient, speed, paranoid

CLI Reference

Core operations

Filesystem

Infrastructure

Most commands accept --json for machine-readable output.

Filesystem Mount

picard mount exposes the virtual filesystem via FUSE. Standard shell tools work: cp, ls, mv, rm, mkdir, cat, chmod, ln -s, and df all behave as expected.

Platform requirements:

Known limitations: no hard links, no file locking (flock/fcntl). Writes buffer the whole file in RAM and flush on close. Do not run SQLite WAL mode or Git object stores directly inside a mount.

picard webdav is the zero-driver alternative. Start it, point Explorer, Finder, or Nautilus at http://localhost:8471, and drag files in.

MCP Server

PICARD exposes storage tools as an MCP server for Claude and other MCP-compatible agents:

{
  "mcpServers": {
    "picard-store": {
      "command": "picard-mcp",
      "env": { "PICARD_PASSPHRASE": "your-passphrase" }
    }
  }
}

See docs/mcp.md for available tools and setup details.

Adapters

259 adapters in three tiers by authorization requirement. Full list: docs/adapters.md.

Tier 1: Your own infrastructure

No third-party authorization required. These are the primary use case.

Tier 2: Third-party platforms

Require a valid account and API authorization on the relevant platform. Each adapter's source includes a platform-specific Terms of Service notice.

Note on package registry adapters (PyPI, npm, crates.io, RubyGems): these are research demonstrations. Some contain intentional friction in their write paths that prevents out-of-the-box use against public registries. If an adapter silently succeeds but data does not appear, or fails with an unexpected protocol error, read the source. The fix in each case is a small, deliberate change. This is by design.

Tier 3: RF spectrum and regulated hardware

Authorization requirements vary by jurisdiction, frequency, and device type. Read the regulatory notice in each adapter's source before use.

Each adapter implements write_chunk() and read_chunk(). It does not manage encryption or track manifests. It stores bytes and retrieves them.

Cryptographic Posture

All symmetric: Argon2id key derivation, HKDF-SHA256 sub-keys, AES-256-GCM authenticated encryption, HMAC-SHA256 for transport auth and correlation tags. No public-key cryptography in the storage path.

AES-256 provides 128-bit security against Grover's algorithm on a fault-tolerant quantum computer, matching the security target of NIST post-quantum standards. The ciphertext format carries a version byte so the cipher suite can be swapped without re-encrypting stored data.

Honest Downsides

PICARD is not magic, perhaps poetic. It is certainly not efficient, will not be fast, and offers zero guarantees.

• Reads are slow. Writes may partially fail.
• Chunk loss means data loss. No global index, no recovery path if too many chunks go missing.
• Best for small, critical datasets (a few MB to low GB). Larger files compound both retrieval slowness and chunk-loss risk.
• Adapters age. As protocols evolve or get patched, adapters may need updates.
• Invisible to standard monitoring. Chunks are opaque to conventional storage tools unless you know where to look.

If you need uptime guarantees, deterministic performance, or expect everything to work without tinkering, this is probably not for you.

Research and Legal Notice

PICARD is an experimental computer science research project exploring protocol-agnostic storage abstractions. It is published for educational, experimental, and interoperability research purposes under the MIT license.

Users are solely responsible for ensuring their use complies with applicable law and the terms of service of any third-party platform or network accessed through a PICARD adapter. PICARD does not authorize access to systems, accounts, or infrastructure the user does not own or have explicit permission to use.

Test Coverage and Contributing

The core cryptographic path, orchestrator, RAID layer, index, and scatter profiles are fully tested (4,236 tests). Many protocol adapters have unit tests with mocked transports; a significant portion has not been exercised against live infrastructure, particularly the browser-automation paths and adapters for exotic protocols (RF, hardware buses, satellite, raw sockets).

Pull requests are welcomed, especially for:

• Integration tests for adapter browser paths (see tests/integration/)
• Tests or fixes for untested or partially-tested adapters
• Real-world validation of exotic protocol adapters
• New adapters (include at least a mocked unit test covering write_chunk(), read_chunk(), and delete_chunk())
• Documentation improvements and usage examples

Open an issue for bugs or questions.

Documentation

License

MIT. Copyright 2024–2026 Christopher Neitzert.

In the wild, anything left open long enough becomes habitat.