# Ship sovereign storage by architecture. Without writing a line of cryptography.

> One client-side encryption SDK, in TypeScript: install it, point it at the object storage you already run, ship. Encryption, dispersion, and public anchoring happen behind a clean API, so none of it is code you write, own, or defend in a security review. Your users just see files.

Source: https://dataprism.co/developers

## Install, point, ship.

Initialize a client, create a project, upload a file, read it back. Everything below the API line, key derivation, chunking, erasure coding, anchoring, is code you never write, test, or keep patched. And when your security review asks what is actually inside those calls, the next section is the answer.

## Four stages. No magic.

### Content-defined chunking

Edit a large file and re-upload it, and only the parts that actually changed travel again: files are cut at natural content boundaries, not fixed offsets, so one insertion does not re-slice everything after it. You get delta-sized re-uploads without maintaining a diff format of your own.

### Convergent encryption, on your machine

Every chunk is encrypted on your machine before anything leaves it, so there is no key service to stand up and nothing to escrow. The derivation is deterministic, so unchanged content is recognised as already stored: a re-upload moves only what actually changed, and identical content occupies your storage once rather than once per copy.

### Erasure coding across independent providers

Encrypted chunks are expanded with redundancy you choose and dispersed across the independent providers you configured, so a provider outage, or a provider dropping your account, stays a non-event up to that redundancy. No failover path of your own to write, rehearse, and keep in sync.

### A sealed index, anchored on a public registry

What gets anchored is a constant-size encrypted index, whatever the file size, and its integrity does not rest on any operator, including us: reads reconstruct your data from any quorum of fragments and decrypt locally. Showing that a file was not altered is then a check the asker runs, not an endpoint you have to build and support.

## One client-side encryption SDK, three guarantees.

### Everything that leaves is ciphertext

Chunk keys are derived from the content itself, which is what makes re-uploading unchanged data cheap. The index that assembles them is sealed with a key derived from a secret you control, and neither key is ever sent to us: everything the SDK sends outward is already encrypted. Adding a provider never widens what anyone can read.

### No cryptography exposed to end users

No cryptographic plumbing is ever exposed to your users. Keys and execution stay behind your product's own login and UI, so there is no new step in your onboarding and nothing extra for your support team to answer. To them, it is just storage that happens to be unreadable to everyone else.

### Complete, public documentation

Every layer is documented in the open at docs.dataprism.co: the SDK reference, the file pipeline, the contracts, runnable Node.js and Next.js examples. If you can read a README, you can evaluate us before you ever talk to sales.

## Point it at the storage you already run.

No new storage vendor to onboard, no infrastructure migration, no protocol to learn: wherever the fragments land, the pipeline behind the SDK stays the same. Adding or dropping a provider is a config change, not a project.