Everythink Studio
Globale Systemarchitektur

Sechs Abschnitte, ein System

Von der Produktvision bis zur realen Implementierung: Rust-Backend, Next.js-Frontend, Deployment und Roadmap.

Der Raum ist der Router

Jede Person hat ihre eigene persönliche Organisation und abonniert n Organisationen. Jede Organisation — Unternehmen · Behörde · Gewerkschaft · Gemeinschaft — enthält n Netzwerke; jedes Netzwerk enthält n Communities; jede Community enthält n Räume. Jeder Knoten hat sein eigenes Multipolygon: Enthaltensein verläuft nach innen (fragmentierte Communities innerhalb des Netzwerk-Polygons) oder nach außen (Communities außerhalb des Polygons). Die Topologie ist im mathematischen Sinne fraktal: Jede Ebene ist eine selbstähnliche Kopie der vorherigen — S = ⋃ fᵢ(S), der Attraktor des Hutchinson-Operators (Banachscher Fixpunktsatz). Netzwerke interopieren miteinander (Föderation): Ein Netzwerk verbindet sich mit einem anderen, indem es nur das Öffentliche teilt. Tritt eine Person einer Organisation bei, erhält sie Zugriff auf deren n Communities und n Räume. Die Arbeit, die sie in der Organisation leistet, wird in der Org erfasst und in ihre persönliche Org gespiegelt: Sie erzeugt Reputation pro Person, wird zu gelösten Problemen destilliert, und diese werden in ihr persönliches Netzwerk kopiert, das sie nachverfolgt. Aus den angesammelten Antworten baut HAI eine Kontextschicht pro Nutzer.

Die vier Schichten der Plattform

Jede obere Schicht komponiert die Garantien der darunterliegenden Schichten über typisierte Schnittstellen. Produkte (v1-Module): HAI, Matchmaking, Chat, Kalender, Market, Social. Über den 4 Schichten liegen 10 Sektoren-Instanziierungen.

Drei Prinzipien, die die Architektur regieren

Jedes Prinzip ist eine überprüfbare Garantie, keine Absichtserklärung. Gemeinsam begründen sie die Kompositionsregel (Ende-zu-Ende), die Sektor-Multiplikationsregel (Vererbung ohne Modifikation) und die Ehrlichkeitsregel (implementiert und gemessen = Garantie).

HAI-Engine — 13 Fragetypen

In Produktion seit 2016. Ein bewusst schmales, komponierbares Fundament: Eine Interaktion ist ein Workflow typisierter Fragen, und die Plattform ist eine geolokalisierte Topologie, sodass jede Antwort in einem wohldefinierten Kontext landet. In v2 läuft die Engine auf zwei Inferenzschichten: dem erlernten Netzwerk (deterministisch, ohne LLM) und der A2A-Inferenz, die nicht existierende Knoten auffüllt und das Netzwerk kollabieren lässt.

Kalender — Dienstleistungen verkaufen und den Kalender verwalten

Ein Verkäufer bietet Dienstleistungen (type_event) mit Preis, Kategorie und Verfügbarkeit an; Kunden buchen (event) mit Teilnehmer, Datum und Ort. Im White-Label-Modus ist jeder Verkäufer im selben Netzwerk sichtbar und bestellbar — "andere verkaufen in meinem Netzwerk". Die Zahlung legt einen Merchant im Netzwerk an und sucht Produkte über den product_key.

Market — Produkte verkaufen und andere in meinem Netzwerk verkaufen lassen

Der Verkäufer listet Produkte (market_product) mit Merchant, Anbieter und Preis und hängt Angebote/Coupons daran. Der Kunde baut den Warenkorb (market_item) auf und checkt aus (merchant_tx), mit dem Netzwerk-Schlüssel, der in json_data gestempelt ist. Streitfälle und Bewertungen auf beiden Seiten. Merchants sind über merchant.network an das Netzwerk gebunden — "andere verkaufen in meinem Netzwerk".

HAI + Matchmaking + Chat — das persönliche Netzwerk jedes Nutzers

HAI füllt das persönliche Netzwerk jedes Nutzers, indem es versteht, wonach dieser sucht: Netzwerke werden automatisch aus der Website oder dem Dokument des Unternehmens/der Behörde/der Gemeinschaft/der Gewerkschaft bevölkert, Fragenflüsse werden generiert — und ebenso die Querverweise zwischen Matchings aus verschiedenen Räumen (gleiche oder andere Community). Matchmaking automatisiert Prozesse: eine Nutzerabsicht → eine Bestellung im Dispatch-Kanal der Community, geolokalisiert im Zielraum. Echtzeit-Chat über Socket + FCM. Die Flüsse sind raumübergreifend (sie durchqueren Räume) und laufen auf den zwei Inferenzschichten: dem erlernten Netzwerk + A2A, das auffüllt und kollabieren lässt.

Social — Netzwerk-Promotions und Nutzerinteraktion

Das Netzwerk führt Promotionen in seinem Raum durch, und die Nutzer interagieren in einem Social-Modul: News/Stories mit Likes und Kommentaren, Kategorien vom Admin festgelegt. Der Social-Feed lebt in der Topologie — das Netzwerk publiziert, die Community fragmentiert, der Raum empfängt.

Zwei Inferenzschichten — das kollabierende neuronale Netz

Alle Module leben in Räumen eines Netzwerks und sind raumübergreifend: Ein Datenfluss (HAI) aus einem Gästeraum mit Pre-Sales verbindet sich mit einem aus einem Kunden mit technischem Support. Anders als in v1 (statische Graphen) gibt es hier neuronale Netze: Existiert der Folge-Knoten nicht, bestimmt A2A die nächsten Schritte, speichert sie, und das Netzwerk kollabiert. Der Umfang ist endlich — was ein Nutzer in einem Netzwerk fragt, wird für alle gespeichert — und der LLM-Verbrauch über A2A sinkt mit der Zeit, er wächst nie.

Überprüfbare Multi-Tenant-Isolation

Unternehmen, Regierungen, NGOs und Gemeinschaften teilen sich seit 2016 ein einziges KI-Substrat und halten das Private nachweislich privat. Vollständige Mediation durch den Reference Monitor; der einzige erlaubte Kanal = öffentliche Scopes.

Föderierte Netzwerke und stabiles Matchmaking

Netzwerke föderieren über ihre öffentlichen Projektionen. Matchmaking operiert nur auf öffentlichen Scopes innerhalb eines Nähe-Radius; Deferred Acceptance → stabiles Matching.

Typisierte Erhebung — Lernen mit wenigen Fragen

Das System fragt, der Nutzer antwortet, und die Antwort wird Kontext. Die Erhebung ist typisiert (die Engine rechnet ohne Überraschungen), treu und effizient. Sie läuft auf Schicht 1 (erlerntes Netzwerk, deterministisch); existiert ein Knoten nicht, bestimmt Schicht 2 (A2A) die Schritte, persistiert sie, und das Netzwerk kollabiert — Lernen mit wenigen Fragen, und jede neue Frage wird für alle gespeichert.

Agentische Workflows — die Envelope

Einige Knoten verlangen offene Arbeit: ein LLM-Agent, der Denken mit Werkzeugaufrufen verzahnt (ReAct-Stil), bis er eine Antwort vom richtigen Typ hat. Dies ist Inferenzschicht 2 (A2A): Existiert der Folge-Knoten im erlernten Netzwerk nicht, bestimmt der Agent die nächsten Schritte, persistiert sie, und das Netzwerk kollabiert — der LLM-Verbrauch sinkt mit der Zeit, er wächst nie. Die Envelope begrenzt die drei Fehlermodi.

Proaktive Assistenz — der Informationswert

Die Umkehrung eines reaktiven Chatbots: Sie initiiert, statt zu warten. Das Schwierige ist die Enthaltsamkeit — nur sprechen, wenn der erwartete Nettowert des Handelns den Wert des Schweigens übersteigt.

Begrenzte Autorität und Herkunft

Ein Agent, der handeln kann — Geld ausgeben, Dritte kontaktieren, Daten bewegen — muss durch das begrenzt sein, dem der Nutzer zugestimmt hat, Informationen nur für den gegebenen Zweck verwenden und eine Spur hinterlassen, die Erklären und Rückgängigmachen ermöglicht.

Autonome Netzwerke im Dienst der menschlichen Netzwerke

Begrenzte Delegation, Contract-Net-Zuteilung (announce → bid → award) und die ehrliche Grenze der Koordination: Liveness nur bei partieller Synchronie.

Sicherheit und das Evidenz-Protokoll

Zehn Sektoren-Instanziierungen

Jede Sektor-Bereitstellung instanziiert die Schichten 1–4, ohne sie zu modifizieren, und erbt deren Garantien.

Produktion / Design / projiziert

17 Crates, hexagonal, ein Postgres

Composition Root (api) → Use-Cases ×10 → Adapter (ledger, a2a, courier) → Domäne (core, ZERO I/O). Ein einziges Postgres (Timescale pg17 + pgvector) für alles: Ledger, Events, Embeddings, Jobs/Whisper-Geo-Cache. SQL wird zur Compile-Zeit verifiziert (.sqlx/-Offline-Cache, 107 Queries).

Ports & Adapter — die Domäne im Zentrum

Die Domäne (everythink-core) kennt kein I/O. Adapter implementieren Ports für DB, E-Mail, A2A. Use-Cases orchestrieren. Die Composition Root (everythink-api) verdrahtet alles.

Warum so viele Crates — eine explizite Rolle pro Crate

Jeder Crate hat eine Rolle: Composition Root (api), Client (sdk, cli), Use-Case ×10, Infra-Adapter (a2a, courier), Ports + Persistenz (ledger), Domäne (core).

17 Crates fließen in core zusammen

everythink-api ist der Hub; alles hängt von core ab (ZERO I/O). Das SDK lebt innerhalb des Workspace (backend/crates/everythink-sdk), weil es an core gekoppelt ist.

Von Auth bis Persistenz — ein vollständiger Request

Client → api (auth + rate-limit + validate) → loom (run) → ledger (Profil über das Repo-Trait auflösen) → sisters (fan out) → oracle (merge → normalisiertes Ensemble) → ledger (persistieren) → 200 OK.

Sechs Use-Cases: Orchestrierung, Auth und Daten

loom — Orchestrierung: persistiert über den Port LoomStore / den Adapter LoomPersistence. ingest — Signal-Pipeline: verarbeitet eingehende Signale. scry — Sentiment: der Referenz-Port SentimentReader / PgSentimentReader. eval — Regressions-Harness: kontinuierliche Auswertung. warden — Auth: JWT access/refresh, Google OAuth, IP-Binding. whisper — HMAC-signierte Webhooks mit Exactly-once-Zustellung.

Middleware-Kette — Trace → Timeout → CORS → Routing

Eingehender Request → Trace + request_id → Timeout 60s → 408 → CORS + Kompression → Routen-Subbaum mit 5 Zweigen.

Drei Auth-Regime koexistieren auf einem Router

Öffentlich (probes/register/login/refresh) · Eye-Key (HMAC, gleitendes 60s-Rate-Limit) · User-JWT (warden, Console) · Atlas-WS (selbst authentifiziert, Caps pro Nutzer).

RBAC ohne Vererbung — eine Funktion, eine explizite Matrix

can(role, action) als const fn: Owner → true; Profile Read/Write Self → true; expliziter Match auf (role, action); der Rest → nur Owner. AUTHORIZE im Handler → 403 bei Verweigerung.

Ein Datenspeicher für alles

timescale/timescaledb-ha:pg17 + pgvector (vector(1024) + HNSW). Ein Pool. Sechs Daten-Domänen: Ledger, Simulations, Users, Embeddings, geo_signals, Jobs. Health-Check: pg_isready in docker-compose (service_healthy).

Persistenz über einen Port, nie über ein Konkretum

Repository-TRAIT · Pg*Repository (hier lebt das gesamte SQL) · MockRepository (Tests ohne DB) · AppState: Arc<dyn Repository> · Use-Cases rufen das TRAIT auf.

Zur Compile-Zeit verifiziertes SQL, reversible Migrationen

.up.sql + .down.sql editieren (gepaart) → just sqlx-prepare → .sqlx/*.json committen (107 Queries) → Build/CI mit SQLX_OFFLINE=true ohne Live-DB.

Health-Checks + SQLX offline — präzise Deployments

docker-compose: postgres (pg_isready, 10s/5s/10) → dragonfly (redis-cli ping, 10s/3s/10) → api (service_healthy). app/admin: Health-Check deaktiviert (distroless/static). CI: SQLX_OFFLINE=true mit committetem .sqlx/-Cache.

SSE (Tide) + WebSocket (GeoHub) — Fan-out pro Tile

TideBroker: SSE mit zusammengesetzten Topics, Broadcast 256, Keep-alive 15s, Last-Event-ID-Reconnect. GeoHub: WS mit DashMap[Tile → broadcast 64], Viewport-Steuerung, gzip per Opt-in.

Sechs Use-Cases für Orchestrierung und Daten

everythink-warden — User-Auth

everythink-whisper — signierte Webhooks und dauerhafte Zustellung

A2A (Protokoll) und Courier (E-Mail)

everythink-cli und everythink-sdk

Sechs Invarianten, die nie verletzt werden

4 Apps, 13 Pakete, eine Identität

web (:3000) · app (:3001) · admin (:3002) · mobile (Expo). Pakete: types, sdk-core + Fassaden, domain, ui, auth, api-client, telemetry, config.

Vier Oberflächen, ein Backend, drei Akteure

Akteure: Endnutzer (Gast → authentifiziert) · Entwickler (Eye-Key) · Admin/Betreiber (Staff). Oberflächen: web/app/admin/mobile. Backend-API (REST + SSE unter /api/v1).

Container — das komplette Monorepo

4 Apps + SDK-Schicht (6 Fassaden) + Services (4) + Designsystem + Tooling + types (Leaf). Nutze den Zoom zum Erkunden.

web, app, admin, mobile — eine pro Zielgruppe

Sechs Fassaden, ein Core, null Endpoints im Core

sdk-core (HttpClient, consumeSSE, TokenProvider) · sdk-guest · sdk-auth · sdk-atlas · sdk-eye · sdk-admin.

Anwendungsservices, UI und Build-Time

domain (Mapper) · telemetry (Outbox) · api-client (Legacy) · auth (NextAuth v5 + RBAC) · ui (Kit + Tokens) · config (ESLint-Presets) · types (Zod, Leaf).

sdk-core kennt das WIE, nie das WAS

Endpoints leben NUR in den Fassaden; sdk-core validiert jede Antwort mit Zod gegen @everythink/types; ein SdkError-Baum mit ContractViolation bei Drift.

Feature-Sliced Design + MVVM — Imports fließen nach unten

Screen (View) → View-Model-Hook → feature.repository.ts (DIE einzige Tür zum SDK). ESLint-Grenze no-restricted-imports (INV-1). FSD-Schichten: shared → entities → features → widgets → app.

Ein Login, ein Origin, vier Oberflächen

apps/web /auth (ein Origin) → httpOnly-Cookie 'everythink_at' → Token im Speicher + localStorage-Seed → EverythinkAuthGuard + resolveMe (GET /api/v1/auth/me) → rollenbasiertes Gate.

can(role, action) — explizite Matrix, keine Vererbung

3 Schichten: (1) auth.ts pro App mit allowedRoles → (2) Middleware → (3) can() in der UI + Server-Actions. Spiegelt everythink_core::rbac aus dem Backend.

Ein Stylesheet, semantische Tokens, Tailwind v4

Eine einzige Source of Truth für das Design: CSS-Tokens in :root, semantisches Mapping über @theme (Tailwind v4) und NativeWind für Mobile mit gespiegelten Tokens. Die Apps konsumieren semantische Komponenten (bg-accent, text-foreground, font-display/mono), nie rohe Hex-Werte. Cosmic-Purple-Palette: --gold: #d9ab5c, --violet: #9d7df5, --emerald: #10B981.

Zod an der Netzwerkgrenze — ein einziger Vertrag

Wire-Typen sind genau einmal in @everythink/types mit Zod definiert. Das SDK validiert jede Backend-Antwort (z.parse(response)); eine ungültige Payload wirft ApiError, niemals einen Crash. Komponenten sehen nie rohes JSON: *.repository.ts parst, @everythink/domain mappt DTO → Modell, und das View-Model exponiert typisierten Zustand an die View.

apps/mobile — Expo, expo-router, NativeWind

React Native mit expo-router (dateibasiertem Routing) und NativeWind (Tailwind für RN). Das Theme-System spiegelt die Tokens des Web-Designsystems (tailwind.config.js + src/theme/index.ts). Es konsumiert sdk-guest, sdk-auth, sdk-atlas, domain und telemetry. Vom Web-CI ausgeschlossen: --filter=!@everythink/mobile.

Vier mechanisch erzwungene Regeln

Regeln, die ESLint + TypeScript verifizieren, keine Konventionen: (1) INV-1: nur *.repository.ts importiert ein SDK (no-restricted-imports); (2) FSD-Schichten: Imports fließen nach UNTEN (shared → entities → features → widgets → app), cross-feature nur über den öffentlichen Barrel; (3) Gemeinsames Sign-in: web + app teilen localStorage('everythink:auth') + resolveMe(); (4) 3-Schichten-RBAC: auth.ts allowedRoles → Middleware → can(role, action) in UI + Server-Actions.

docker-compose.prod.yml — der komplette Stack

ALB (TLS) → nginx :80 → api (:18081, Migrationen beim Start) · web (Next standalone) · app/admin (statisch distroless) · postgres (timescale/timescaledb-ha:pg17 + pgvector) · dragonfly (Redis-kompatibel). 7 Dienste: postgres · dragonfly · api · web · app · admin · nginx.

nginx als einziger Entry Point

nginx :80 ist der einzige interne Entry Point. Er routet /api/v1/* → api:18081, / → web:3000, /app/* → statisch, /admin/* → statisch. web spricht mit api über EVERYTHINK_API_INTERNAL_URL (http://api:18081). api hängt von postgres und dragonfly ab mit condition: service_healthy.

backend/.env — der einzige Ort für Secrets

docker-compose.prod.yml mountet backend/.env via env_file in die Dienste api und web. api hält alle Secrets (JWT_SECRET, EYE_KEY_HMAC_SECRET, GOOGLE_CLIENT_ID, BREVO_API_KEY). web erhält nur NEXT_PUBLIC_*-Variablen — es hält niemals BREVO_API_KEY. app/admin sind statisch distroless ohne Secrets im Build.

Direktes Preprod vs. das CI/CD-Gate

Zwei Deploy-Pfade: Preprod wird direkt aus dem Working Tree deployt (ohne Umweg über main); Prod verlangt einen Merge nach main und das Integritäts-Gate. Die Regel ist kritisch: das Deploy-Workflow NICHT für Preprod verwenden, denn es pullt :latest von main und überschreibt das direkte Deployment.

affected bei PRs, Integrität auf main

Eine 2-stufige Pipeline: Die PR-Stufe läuft nur das Betroffene (Backend: ci-affected-crates.sh; Frontend: turbo --affected), die main-Stufe läuft die volle Integrität (komplettes Backend + Frontend/Mobile + E2E + Security). main bleibt grün und deploybar.

Föderierte self-hosted Nodes · BYOK · DAO pro Netzwerk

Roadmap-Richtung für v2. Keines der Folgenden ist eine existierende Fähigkeit. Ablauf: Der Betreiber erzeugt ein lokales Ed25519-Paar → nur der Fingerprint geht an den Controller (BYOK) → self-hosted Node → Ledger-Anchoring → Föderation ausschließlich über öffentliche Projektionen → Netzwerk-DAO.

Fünf Phasen Richtung v2

Referenzarchitektur der Kandidaten-Chain

Architektur-Referenz für das Notarisieren von Postgres-Ledger-Hash-Commitments: Solana v0.8.13 (Yakovenko) — PoH als kryptografische Uhr, PoS-Konsens mit Bonds/Slashing, PoRep für Storage. Die Chain-Auswahl ist eine explizite Entscheidung des Betreibers; dies ist eine Referenz, keine Implementierung.