64 lines
4.8 KiB
Markdown
64 lines
4.8 KiB
Markdown
|
|
# Shade by scenario — modular E2EE toolkit
|
|||
|
|
|
|||
|
|
This page is for **builders**, not cryptography specialists. Shade is packaged so you can **drop in small pieces** per project instead of importing a heavy “everything” stack.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Plain-language mental model
|
|||
|
|
|
|||
|
|
1. **Identity & session (the hard crypto):** Shade establishes a **secret channel** between two parties using the same kind of cryptographic core as Signal (initial setup + ongoing “ratchet” updates). **You mostly call high-level APIs** (`send`, `receive`, fingerprints) rather than assembling primitives by hand.
|
|||
|
|
|
|||
|
|
2. **Who is “the server”?**
|
|||
|
|
The **prekey server** only helps with **public key material** (so Alice can fetch Bob’s public bundle before the first message). It is **not** your general-purpose message relay unless **you** build that separately. Normal **message payloads and file chunks** typically flow over **your** transport (your HTTP routes, websocket, bridge, queue, etc.).
|
|||
|
|
|
|||
|
|
3. **Small vs large payloads:**
|
|||
|
|
Short messages ride the usual ratchet envelopes. Very large payloads use **Streams + Transfer**: secrets are negotiated over the ratchet; ** ciphertext chunks** ship over optimized HTTP/WebSocket transports with parallelism and resume.
|
|||
|
|
|
|||
|
|
4. **Trust:** Strong encryption does **not** replace **verifying who you are talking to**. For high-stakes use, compare **safety numbers** out-of-band (see [THREAT-MODEL.md](../THREAT-MODEL.md)).
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Scenario → minimum packages
|
|||
|
|
|
|||
|
|
Pull in **one row** that matches your project; add optional columns only when needed.
|
|||
|
|
|
|||
|
|
| Scenario | What you need | Minimum packages / surface | Where to start |
|
|||
|
|
|----------|----------------|----------------------------|----------------|
|
|||
|
|
| **Backend or Bun service** — encrypted messages between users | Session storage + crypto provider + prekey URL | `@shade/sdk` + `sqlite:` or `@shade/storage-postgres` | `createShade()` → `send` / `receive` |
|
|||
|
|
| **Browser / frontend** — same, in the client | Web crypto + durable or memory storage | `@shade/sdk` or `@shade/core` + `@shade/crypto-web` (+ storage you provide) | Same APIs; ensure `prekeyServer` is reachable from the browser (CORS, etc.) |
|
|||
|
|
| **Large files** — resumable E2EE upload/download | Above + stream protocol + HTTP (or WS) transport | `@shade/sdk` (re-exports transfer) + mount transfer routes on **your** HTTP server | `shade.upload` / `onIncomingTransfer` — see [streams.md](./streams.md) |
|
|||
|
|
| **React UI** — upload/download widgets | Runtime from SDK + widgets | `@shade/sdk` + `@shade/widgets` | `ShadeRuntimeProvider`, `useShadeUpload` / `useShadeDownload` |
|
|||
|
|
| **Prekey hosting only** — one container per product | No app crypto in the container | Docker image / `@shade/server` | Deploy prekey image; point `prekeyServer` at it from apps |
|
|||
|
|
| **Maximum control** — custom wire, custom transport | Wire + session manager | `@shade/core` + `@shade/proto` (+ your storage + crypto provider) | `ShadeSessionManager`, encode/decode envelopes yourself |
|
|||
|
|
| **HTTP or WebSocket convenience** | Auto-wrap application bytes | `@shade/transport` on top of your stack | Use when you want transport helpers, not a new protocol |
|
|||
|
|
| **Android** | Byte-compatible with TS (roadmap) | `shade-android` module | See [android/shade-android/README.md](../android/shade-android/README.md) — parity work in progress |
|
|||
|
|
|
|||
|
|
You can **mix rows**: e.g. backend with `@shade/sdk` + SQLite for sessions, separate service mounting `transfer` routes, browser clients using `@shade/widgets`.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## New project checklist (lightweight)
|
|||
|
|
|
|||
|
|
1. Run a **prekey server** (Docker or embedded `@shade/server`) for your environment.
|
|||
|
|
2. Pick **storage** (`sqlite:…`, Postgres, or project-specific adapter implementing the core storage interfaces).
|
|||
|
|
3. Choose **surface**: usually `@shade/sdk` unless you truly need `@shade/core` only.
|
|||
|
|
4. For files: enable **transfer routes** and authenticate chunk uploads using the patterns in the SDK (see streams doc).
|
|||
|
|
5. Run **`shade doctor`** when something fails in production-ish setups (install the CLI as in repository [Quick start](../README.md#quick-start)); coverage is evolving — roadmap in [V2.2](./V2.2.md).
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Related docs & roadmap
|
|||
|
|
|
|||
|
|
| Topic | Doc |
|
|||
|
|
|--------|-----|
|
|||
|
|
| File transfer architecture | [streams.md](./streams.md) |
|
|||
|
|
| Deployment & operations | [DEPLOYMENT.md](./DEPLOYMENT.md) |
|
|||
|
|
| Threat model | [THREAT-MODEL.md](../THREAT-MODEL.md) |
|
|||
|
|
| Planned improvements | [V2.1](./V2.1.md), feature backlog [V2.2](./V2.2.md), trust/ops [V2.3](./V2.3.md) |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Version note
|
|||
|
|
|
|||
|
|
This file describes how Shade is **intended** to be composed. Package names and re-exports may gain small aliases over time; the **scenario table** should remain the source of truth for “what to install for what job.” Update this page when adding major surfaces (new transport bridges, richer `shade init` templates, etc.).
|