# Is argala the right tool?

argala is for applications where **"we cannot read it" is the feature**.

Most sync engines send plaintext through a server the vendor can read, because
server-side search, notifications and AI features all need it. If you want
those, use one of those — they are better at it, and argala gives them up on
purpose.

Use argala if:

- your data is health, legal, financial, journalistic, or otherwise the kind
  where "our server was breached" is an ending rather than an incident;
- you want a local-first app whose reads never wait on a network;
- you are prepared to give up server-side search, server-side notification
  content, and server-side anything-that-reads-the-data.

Do not use argala if:

- you need full-text search across a corpus larger than a device holds;
- you need the server to compute over the data (analytics, ranking, LLM calls);
- your compliance story requires server-side inspection of user content.

**A short honesty checklist**, expanded in SECURITY.md:

| you want                                      | argala gives you                                                   |
| --------------------------------------------- | ------------------------------------------------------------------ |
| the server cannot read record contents        | yes — the primary claim, tested mechanically                       |
| the server cannot forge a record              | yes — signatures inside the ciphertext                             |
| the server cannot tell who wrote what         | yes                                                                |
| the server cannot tell _who talks to whom_    | **no** — membership and pairwise graphs are visible                |
| the server cannot serve stale or omit records | **detected, not prevented** — see Part 13                          |
| a device the server invented cannot get a key | yes — see Part 14, and it ends at a person comparing 12 characters |
| a member can be given read-only access        | yes — enforced at the relay, see Part 15                           |
| one member cannot overwrite another's records | **no** — `write` is all-or-nothing; see below                      |
| a browser app nobody can backdoor             | **no** — whoever serves the JavaScript could ship a leak           |

**The authorization gap is worth reading twice**, because it is the one people
assume is closed. Inside a shared graph, every member is effectively an owner.
Signatures prove who wrote a record; nothing says whether they were allowed
to. Any member holding the key can rotate it, overwrite somebody else's
records, or delete them. There is no read-only seat and no admin role that
means anything to another device — roles shown in your UI are a convention
your own client keeps, not a rule anybody else's client obeys. If your app
needs one member to be able to read but not write, argala cannot give you that
today.

---