--- name: piggyback-hosting version: 1.0.0 type: skill author: Lukas Geiger + Claude created: 2026-08-02 updated: 2026-08-07 description: Hosting-Muster, um eine lokal gebaute Anwendung (eigene Datenbank, eigener API-Key, In-Process-State) sicher hostbar zu machen, ohne Nutzerverwaltung zu bauen. Kernzug — der Host speichert nichts, der Browser des Besuchers speichert alles — sodass Pro-Besucher-Accounts, Zugriffsprüfungen und Löschfristen gegenstandslos werden, statt gelöst werden zu müssen. Nutzen, wenn eine lokal gebaute App für mehrere Besucher gehostet werden soll, bei "mach das ohne Login hostbar", "keine Nutzerkonten bauen", "Datenschutzerklärung für ein gehostetes Tool verkleinern", "wer ist verantwortlich, wenn wir nichts speichern" oder beim Wählen/Implementieren eines Server-Modus (`local`, `huckepack-gift`, `huckepack-only-host`, `pay-membership`). Liefert eine Data-Flow-Plan-Vorlage, eine Datenschutz-Vorlage und eine rechtliche Ersteinschätzung (DSGVO/TDDDG/UWG, deutsch) als Referenzen. standalone: true anthropic_compatible: true bach_compatible: false bach_origin: false category: dev tags: [hosting, privacy, gdpr, dsgvo, byok, client-side-storage, deployment, no-login] language: de status: active visibility: public dependencies: tools: [] services: [] protocols: [] python: [] provenance: origin: "custom" origin_path: null origin_version: null origin_repo: "github.com/ellmos-ai/skills" last_sync_from_origin: null --- piggyback-hosting banner # piggyback-hosting **Ein Hosting-Muster für Anwendungen, die von vornherein niemals fremde Daten annehmen.** > Blaupause entstanden am 2026-08-02 beim Bau dreier Call-Agenten. > Wiederverwendbar für jede Anwendung, die für einen einzelnen lokalen > Nutzer entworfen wurde, aber auch für andere hostbar sein soll. ## Zum Namen Im Englischen heißt dieses Muster **piggyback** — auf fremder Infrastruktur mitreiten ist dort bereits der Fachbegriff dafür. Englischer Fließtext in diesem Skill sagt daher *piggyback*; **"huckepack" ist der deutsche Arbeitstitel**, unter dem das Muster gebaut wurde, und zugleich der Name des Repositories, aus dem dieser Skill migriert wurde. **Die wörtlichen Modus-Werte bleiben `huckepack-gift` und `huckepack-only-host`** — sie sind das, was in Code und Konfiguration verschifft wird, genau so geschrieben, unabhängig davon, in welcher Sprache der umgebende Fließtext steht. ## Das Problem Eine Anwendung wird lokal gebaut: eine Datenbank, ein API-Key, State, der im Prozess lebt. Auf der eigenen Maschine ist das schlicht korrekt. Sobald jemand sie für andere hostet, wird jede dieser drei Annahmen zu einem Bug — jeder Besucher teilt sich denselben State, dieselbe Datenbank, denselben Key. Wer die Seite öffnet, sieht die Daten aller anderen. Die übliche Lösung ist Nutzerverwaltung: Accounts, Login, Zugriffsprüfungen, Löschfristen, eine Datenschutzerklärung, ein Auftragsverarbeitungsvertrag. Oft ein größeres Unterfangen als die Anwendung selbst. ## Die Idee **Der Besucher behält alles auf dem eigenen Gerät. Der Host behält nichts.** Das löst die Nutzerverwaltung nicht — es macht sie **gegenstandslos**. Wo keine fremden Daten auf dem Server liegen, gibt es nichts zwischen Besuchern abzuschotten, nichts nach Zeitplan zu löschen, und die Datenschutzerklärung schrumpft auf das, was der Dienst tatsächlich tut. ## Die drei Modi | Modus | API-Key | Daten | Nutzerverwaltung | |---|---|---|---| | **`huckepack-gift`** | vom Host | auf dem Gerät des Besuchers | keine | | **`huckepack-only-host`** | vom Besucher | auf dem Gerät des Besuchers | keine | | **`pay-membership`** | des Hosts, abgerechnet | Server | erforderlich | - **`huckepack-gift`** — der Host liefert seinen eigenen Key und verschenkt die Ausführung. Eine reibungslose Einladung, das Tool auszuprobieren. - **`huckepack-only-host`** — der Besucher bringt seinen eigenen Key mit. Der Host zahlt nichts und speichert nichts. - **`pay-membership`** — bewusst als Stub belassen. Hier wird alles wieder nötig, was die anderen beiden vermeiden — Accounts, Abrechnung, serverseitige Speicherung. Ein eigenes Unterfangen, kein Schalter zum Umlegen. Es gibt immer einen **`local`**-Standard: wer nichts konfiguriert, bekommt die Anwendung genau so, wie sie vorher lief, auf der eigenen Maschine. ## Die Bausteine | Baustein | Zweck | |---|---| | Modus als Install-Time-Einstellung | eine Eigenschaft des Deployments, nicht der Session | | Austauschbare Speicherschicht | dieselbe Datenbank, anderer Ort | | SQLite im Browser (WASM + OPFS) | dasselbe Schema, dieselben Queries, anderer Ausführungsort | | Key-Feld, maskiert | nur im `only-host`-Modus, nie geloggt | | Export und Import | **nicht optional** — Browser-Daten sind flüchtig | | Beleg als herunterladbare Datei, Zielordner wählbar | kein Server an der Auslieferung beteiligt | Der eigentliche Engineering-Aufwand liegt darin, die Speicherschicht austauschbar zu machen: die Anwendung schreibt so oder so nach SQLite, aber eine Zwischenschicht entscheidet, ob dieses Schreiben auf dem Server oder im Browser des Besuchers landet (`sql.js` / der offizielle SQLite-WASM-Build, persistiert über das Origin Private File System). Die Browser-Speicher-Optionen nach Gewicht ordnen, falls WASM zu schwer ist: SQLite-WASM + OPFS (eine echte Datenbank, größte Kapazität) > IndexedDB (strukturiert, eigenes Query-Modell) > `localStorage` (nur für Kleinigkeiten wie Sprache und Theme geeignet). ## Was dieses Muster nicht löst — offen gesagt - **Gelöschte Browser-Daten heißt, alles ist weg.** Es gibt keine serverseitige Kopie. Deshalb ist Export eine Bedingung, kein Nice-to-have. - **Kein Gerätewechsel** ohne Export und Import. - **Der im Browser lebende Key** (`only-host`) ist weniger geschützt als einer auf einem Server. Er gehört aber dem Besucher, und die Alternative wäre, ihn dem Host zu übergeben — nicht offensichtlich die sicherere Wahl. - **Die Ausführung läuft weiterhin über den Host.** Bei Diensten, die einen Dritten erreichen — etwa einen Telefonanruf — verarbeitet der Host die Daten dieses Dritten unabhängig davon, wo die eigenen Aufzeichnungen des Besuchers liegen. Eine Datenschutzerklärung wird dadurch nicht überflüssig, nur kurz. ## Was die Rechtsprüfung ergab Eine rechtliche Ersteinschätzung (`references/RECHT.md`, deutsch — sie prüft deutsche und EU-Vorschriften, weshalb ein Zitieren in Übersetzung weniger genau, nicht zugänglicher wäre) prüfte das Muster gegen DSGVO, TDDDG und UWG. **Ersteinschätzung mit Fundstellen, keine Rechtsberatung.** Drei Befunde in je einer Zeile: - **Der Host bleibt Verantwortlicher, auch wenn er nichts speichert.** Art. 4(7) DSGVO knüpft die Verantwortlichkeit an das Entscheiden über Zwecke und Mittel, nicht an die Speicherung; der EuGH hat das ausdrücklich so gesagt (C-683/21). Gegenstandslos wird die **Nutzerverwaltung**, nicht die Verantwortung. - **Für die kontaktierte Person schrumpft nichts.** Informationspflichten nach Art. 14, eine dokumentierte Abwägung der Rechtsgrundlage, ein Auftragsverarbeitungsvertrag mit dem Dienst, der den Kontakt ausführt — das sind meist die längsten Abschnitte einer Datenschutzerklärung, und das Muster rührt sie nicht an. - **Die Haushaltsausnahme hilft dem Besucher, nicht dem Host.** Sie deckt rein persönliche Nutzung durch eine natürliche Person; ein Dienst, der anderen angeboten wird, ist keine rein persönliche Tätigkeit. Genau dort beginnt Piggyback-Hosting. Der Gewinn liegt im **Umfang der Pflichten und der Größe der Angriffsfläche**, nicht in ihrer Art — was zugleich die ehrlichere Aussage über das Muster ist. ## Wie dieses Muster angewendet wird 1. `references/DATA-FLOW-TEMPLATE.md` lesen und für die tatsächliche Anwendung ausfüllen, belegorientiert (jede Zeile braucht ein `file:line` oder "nicht gefunden"). Das legt genau offen, welche lokalen Annahmen unter Multi-Besucher-Hosting brechen, bevor Code geändert wird. 2. Entscheiden, welche Modi die Anwendung tatsächlich braucht — `local` ist immer der Standard; `huckepack-gift` und `huckepack-only-host` sind die beiden, die Nutzerverwaltung vermeiden; `pay-membership` bleibt ein Stub, solange kein konkreter Grund für echte Accounts besteht. 3. Die Speicherschicht austauschbar machen (der oben genannte Kern-Schritt), das maskierte Key-Feld für `only-host` ergänzen und Export/Import verdrahten, bevor irgendetwas ausgeliefert wird — es ist das Sicherheitsnetz für flüchtigen Browser-Speicher. 4. `references/PRIVACY-TEMPLATE.md` für das konkrete Deployment ausfüllen; nicht zutreffende Blöcke löschen, jede Anbieter-Angabe gegen aktuelle Verträge prüfen und eine fallbezogene Rechtsprüfung einholen, bevor echte Daten verarbeitet werden. Die Vorlage ist ein Ausgangspunkt, keine fertige Erklärung. 5. Bei jeder Installation, die echte Dritte betrifft (Telefonanrufe, Nachrichten an Personen, die sich nicht selbst angemeldet haben) oder Forschungsteilnehmende, die Empfehlungen aus `references/RECHT.md` als Checkliste behandeln, nicht als Freigabe — vor dem ersten öffentlichen Lauf einen Anwalt einbeziehen. ## Referenzen - `references/DATA-FLOW-TEMPLATE.md` — Vorlage und Verfahren für einen Data-Flow-Plan: jede Zeile braucht ein file:line, sonst ist es eine Vermutung, kein Befund. - `references/PRIVACY-TEMPLATE.md` — Muster-Datenschutzerklärung mit markierten Platzhaltern für eine Piggyback-Installation. - `references/RECHT.md` — rechtliche Ersteinschätzung (deutsch) mit DSGVO-, TDDDG- und UWG-Fundstellen. Beide Vorlagen sind **Muster, keine Rechtsberatung**. Wer eine Anwendung hostet, passt sie an und ist für das Ergebnis verantwortlich. ## Herkunft Entstanden beim Bau von HungryCall, Ringedingeding und ResearchCall — drei Call-Agenten, bei denen ein Data-Flow-Audit zeigte, dass ein unverändertes Hosting ein Datenschutzvorfall mit angehängtem Namen gewesen wäre. Migriert aus dem eigenständigen `huckepack`-Repository in diese Skill-Bibliothek.