08 · Why this lives on top of Arkiv (design FAQ)

Arkiv's query language has equality, ranges, STARTSWITH, EXISTS, AND/OR, one sort key and filtered counts. It has no JOINs, no foreign keys, no IN, no NOT, and no aggregates beyond count. Kalypso adds encrypted search, encrypted counts and a relational layer on top of it. This page explains why those features belong in a library rather than in Arkiv itself, and what we do and don't claim.

Short version#

Kalypso doesn't patch Arkiv or work around a missing feature. It compiles encrypted and relational queries down to primitives Arkiv already has:

• indexed equality
• OR
• count()
• atomic batches
• absolute expiry

Nothing in Arkiv changes, and it all runs on Rabdi today. Every result on these pages comes from a live script with real transaction hashes.

Why Arkiv's base layer doesn't do this, and shouldn't#

1. Arkiv nodes never hold user keys.

• Arkiv is a public DB-chain: every node indexes the same public attributes.
• A query over encrypted values can't run on the node unless the node can decrypt. That would break the privacy model.
• The other server-side options, FHE or ORAM, are orders of magnitude too slow for a shared chain.
• So encrypted search has to be a protocol between the client and public tags. That is a library's job.

2. The query language is small on purpose.

• Every node has to evaluate every query deterministically, at a bounded cost.
• The docs list node limits on query length and nesting depth (QueryError kind limits), and the hosted RPC charges a flat quota per query.
• JOINs and aggregates have unbounded cost on a public endpoint.
• Kalypso keeps every query inside those limits: at most 18 OR terms per query, with batching and keyset paging.

3. Leakage is a product decision.

• Each index leaks something: an equality tag shows equality within a month, a range tag shows approximate order, a foreign key shows siblings.
• Whether that leak is acceptable depends on the app. A base layer can't pick it for every app.
• Kalypso makes each index opt-in per field and documents what it leaks (07 §5.4, §6.3).

4. Arkiv's own guidance assigns relations to apps.

• From the data-modeling skill: "the SDK does not enforce foreign keys, uniqueness or cascading deletion".
• From the arkiv-graph package: "Relationships are application rules, not native joins".
• The same guidance warns that children can outlive parents unless the app uses the parent's absolute deadline.
• Kalypso implements exactly those rules (07 §6).

Questions we expect, with straight answers#

What we deliberately don't claim#

• "Zero leakage". Every index leaks something; each one is documented and opt-in.
• That Arkiv can't do range search, count or similar queries. It can, on plaintext.
• That guardians are trustless.
• Speedups at scale beyond what we measured. Rows for larger N are marked as extrapolated.

Where to check#