Files
Shade/docs/archive/V2.3.md
Sterister e6fdf31b49
Some checks failed
Test / test (push) Has been cancelled
Cross-platform vectors / TypeScript vectors (bun) (push) Has been cancelled
Cross-platform vectors / Kotlin vectors (gradle) (push) Has been cancelled
Docker build and publish / docker (push) Has been cancelled
Publish / publish (push) Has been cancelled
release(v4.0.0): Shade GA — V3.x consolidation + audit prep
V3.1 → V3.12 consolidated and tagged for the first GA release. Wire
format unchanged from 0.4.x — 4.0 peers interoperate with 0.4.x peers
byte-for-byte. The version bump is semantic: audit-cycle complete,
opt-in surface fully exposed, threat model refreshed for every new
surface.

Highlights:
- All 24 @shade/* packages bumped to 4.0.0 in lockstep.
- CHANGELOG 4.0.0 section is the canonical manifest of what landed.
- THREAT-MODEL extended (§10 fingerprint gates, §11 WebRTC P2P, §12
  Web-Worker boundary) + residual-risks table refreshed.
- OpenAPI now covers all 27 routes: prekey, transfer, KT, inbox,
  bridge, observer, /metrics, /healthz, /ready.
- MIGRATION 0.3.x → 4.0 documented + smoke-tested against
  shade migrate-storage on a real SQLite DB.
- docs/audit/REVIEW-BUNDLE.md + SCOPE.md ready for external reviewer.
- scripts/soak.ts harness for the GA-stable 2-week soak window.
- All V*.md plans archived under docs/archive/ with Status: Done.
- Voice/Video carved out into V5.0; 4.0 audit focuses on the frozen
  non-realtime stack.

Tests: TS 1000/1000 + Kotlin 11/11 cross-platform vectors green.
Docker: gt.zyon.no/stian/shade-prekey:4.0.0 builds and reports
  version 4.0.0 on /health.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-03 18:35:35 +02:00

4.6 KiB

Shade V2.3 — Tillit, retention, integrasjon og observability

Dette dokumentet beskriver høyere ambisjonsnivå og plattformkryssende arbeid: brukertilfeller der tillit må være eksplisitt, data må utkrympes/ryddes automatisk, apper må enkelt koble seg på kjente transportmønstre, og drift må observere uten å lekke innhold.


1. Key transparency / bundle-attestasjon eller kritiske fingerprint-øyeblikk i UI

Dette kan sees som to spor samme mål: redusere tillit til én korrumperbar prekey-server uten brukerens merknad.

Spor A — Key transparency / bundle-attestasjon (ambisiøst)

Idé: Logging av hvilket bundle som ble utlevert når, kryptografisk forankret og verifiserbar av klienter eller tredjeparts-audit (inspirert av KT-litteratur, tilpasset Shade sin trusselmodell).

Leveranser (målpris høyt):

  • Trusselmodell-oppdatering: hva CT/attest løser vs fortsatt MITM før første verifisering.
  • Designnotat: datastruktur, friskhetsbevis, klient-verifikasjonssteg, operatørkost.

Risiko: Kompleks drift og kryptodesign — bør være valgfritt lag for motiverte deploys.

Spor B — Fingerprints i app-UI på kritiske hendelser (pragmatisk)

Idé: Gjør safety numbers synlige og handlingspålagte i presiserte flyt:

  • Før første stor fil (eller før første stream over terskel i bytes).
  • Før «trust this device» / backup-importer / ny enhet som gjenbruker identitet.

Leveranser:

  • @shade/widgets + SDK-hooks: modal/sheet med fingerprint, kopier-OOB-tekst, «jeg har verifisert».
  • Dokumenterte UX-retningslinjer (unngå «alert fatigue» kun på lave risiko-events).

Felles akseptansekriterier

Enten spor A eller B må ha eksplisitt testcoverage på «blokkerer/handhever verifisering» der det er lovet, og trusselmodellen må nevne kombinasjonen av OOB + tekniske grep.


2. Retention policies

Vision: Standardiserte TTL- og oppryddingsregler for data Shade-økosystemet etterlater på server eller i klient-lagring — spesielt:

  • Stream-state og midlertidige chunk-referanser etter fullførte/avbrutte transfers.
  • Eventuell inbox/relay-ciphertext (V2.2).
  • Prekey-server: kobling til eksisterende SHADE_STALE_DAYS / cleanup, plus policy-dokumentasjon for operatører.

Leveranser:

  • Default-anbefalinger (f.eks. «ferdige streams: prune etter N dager») i @shade/storage-* helpers eller server-factory.
  • Konfigurerbare hooks: maxAge, maxBytesPerIdentity, cron vs on-access prune.

Akseptansekriterier: Ingen «uendelig vekst» som default i nye templates; dokumentert adferd i streams.md / deployment.


3. Ferdig «bridge» (transport)

Vision: Apper som ikke kan eller vil bruke WebSocket, får ferdig mønster for mottak av små meldinger eller kontroll-signaler.

Eksempler:

  • Server-Sent Events (SSE) som ren ciphertext-pipe eller som signal «hent fra inbox» uten plaintext på server (kombinasjon med V2.2).
  • Lang-poll fallback dokumentert ved siden av WS i @shade/transport.

Leveranser:

  • Modulær bridge-pakke eller tydelig undermodul med få eksponerte typer og én felles IncomingMessage-modell på klient.

Akseptansekriterier: Ett fungende eksempel + test som viser dekryptering likt eksisterende transport.


4. Observability

Vision: Produksjonsteam får målepunkter og spor uten innholdslekkasjer eller kryptomatrise i logger.

Forslag til innhold:

  • Metrics (Prometheus-stil eller vendor-nøytralt): opplastings-/nedlastings-varighet, lane-telling, retry counts, abort vs complete rates, HTTP/WS-feilkoder (aggregert).
  • OpenTelemetry: spans rundt TransferEngine og prekey-endepunkter (uten payload-lengde i klartekst som PII — bruk binære størrelser eller binning).
  • Sampling og PII-policy dokumentert (ikke logg adresser i full hvis compliance krever maskering).

Akseptansekriterier: Opt-in flags (default av i lib, på i server-container der det gir mening), og docs/ avsnitt om hva som aldri skal logges.


Prioritering mot V2.1 / V2.2

Dette dokument (V2.3) Naturlig forutsetning
Retention Streams/transfer i bruk (V2.1 §5, V2.2 metadata)
Bridge V2.2 store-and-forward eller egen meldingskanal
UI fingerprints Widgets/SDK allerede i bruk
KT / attest Moden trusselmodell + juridisk/operativ vilje
Observability Stabil nok intern API for hooks

Versjonering

  • V2.3 — første samlet plan for tillit, retention, bridge og observability. Splitt i ADR-er når konkret design er valgt.