Datenschutzerklärung

Verantwortlicher und Kontakt

Verantwortlich: Maximilian Stahl, Fritz-Reuter-Straße 9a, 15344 Strausberg, Deutschland. Datenschutzanfragen: contact@agentcart.eu. Weiterer direkter Kontakt: Kontaktformular unter https://stadtstack.eu/kontakt.

Diese Datenschutzerklärung betrifft stadtstack.eu, Ledger of Life, Ladenrunde, spiel, mitmachen und den gehosteten Civic MCP; die Offline-Mesh-Demo ist gesondert beschrieben. Stand: 10. Oktober 2026.

Hosting, Transport und Protokolle

Die Dienste laufen auf dem Talos-Cluster des Betreibers in der Hetzner-Cloud-Region hel1 (Helsinki, Finnland/EU). Die vorhandene hcloud-Bestandsaufnahme bestätigt diese Region für den Cluster und seine Volumes. Auch der eigene NetBird-Administrationsserver liegt in hel1; NetBird dient dem Verwaltungszugang, nicht einer zusätzlichen Anmeldung für Website-Besucher. Beim Verbindungsaufbau werden IP-Adresse und technische Anfragedaten verarbeitet, damit Seiten ausgeliefert und Angriffe abgewehrt werden können. Vorgesehene Grundlage: Art. 6 Abs. 1 lit. f DSGVO, berechtigtes Interesse an sicherem Betrieb.

Hosting-Anbieter ist Hetzner Online GmbH, Industriestraße 25, 91710 Gunzenhausen, Deutschland. Hetzner nennt für Finnland Hetzner Finland Oy, Huurrekuja 10, 04360 Tuusula, als Unterauftragnehmer für Gebäudevermietung und technischen Support. Laut Hetzner verbleiben Daten eines EU-Serverstandorts und dessen Provider-Backups innerhalb der EU; dies ist keine Aussage über andere App-Empfänger oder eigene externe Backups. Hetzner bietet einen AVV nach Art. 28 DSGVO (öffentliches Muster, Version 1.1 vom 10. Februar 2025); abgeschlossen wird er im Kundenkonto, einschließlich Datenarten und betroffener Personengruppen in Anlage 1. [BETREIBERBESTÄTIGUNG: HETZNER_AVV_ABSCHLUSS — Abschlussdatum und Geltungsbereich des tatsächlich akzeptierten AVV, Anlage 1 und etwaige abweichende Vertrags-/Backup-Vereinbarungen bestätigen.] Quellen: https://www.hetzner.com/AV/DPA_de.pdf ; https://www.hetzner.com/AV/subunternehmer.pdf ; https://docs.hetzner.com/general/company-and-policy/data-protection-at-hetzner/

Auf stadtstack.eu deaktiviert nginx Access-Logs; kritische Fehler gehen an stderr. Der gespeicherte Live-Ingress des Civic MCP enthält eine HAProxy-Regel, die Backend-Request-Logging vor der HTTPS-Weiterleitung unterdrückt. Das beweist weder deren Umsetzung im generierten HAProxy-Frontend noch Log-Freiheit für andere Dienste oder vorgelagerte Ablehnungen. [NICHT VERIFIZIERT: HAPROXY_FRONTEND_LOGS — die vorhandenen Cache-Daten enthalten keinen vollständigen generierten HAProxy-Log-Abschnitt; aktive Log-Ziele, Format, erfasste IP-/URL-/Header-Felder und Vor-Routing-Ablehnungen sind damit nicht belegt.]

Talos 1.13 dokumentiert lokale System-/Container-Logs unter /var/log und ausdrücklich konfigurierbare Weiterleitung. Kubernetes rotiert Container-Logs standardmäßig größenbasiert (10 MiB je Datei, fünf Dateien je Container), nicht nach einer festen Tagesfrist. Das sind öffentliche Plattformvorgaben, keine Bestätigung der aktiven Cluster-Einstellungen oder einer Löschfrist. Hetzners sieben Tage für Managed-Webhosting-/Apache-Logs gelten nicht automatisch für diesen selbst verwalteten Cloud-Cluster. [BETREIBERBESTÄTIGUNG: LOG_DATEN_RETENTION — tatsächliche Rotation/Weiterleitung, Sicherheits- und App-Fehlerlog-Felder sowie zweckbezogene Löschfristen und Kopien/Backups je Dienst festlegen und bestätigen.] Quellen: https://docs.siderolabs.com/talos/v1.13/configure-your-talos-cluster/logging-and-telemetry/logging ; https://kubernetes.io/docs/concepts/cluster-administration/logging/#log-rotation

Gespeicherte HTTPS-Prüfungen bestätigen gültige hostname-geprüfte Zertifikate für stadtstack.eu, Ledger, Ladenrunde, spiel, mitmachen und Civic MCP. Der gespeicherte ClusterIssuer nutzt den produktiven Let's-Encrypt-ACME-Endpunkt; für mcp.stadtstack.eu und netbird.stadtstack.eu ist Let's Encrypt YR2 als tatsächlicher Aussteller bei TLS 1.3 dokumentiert. Let's Encrypt wird von der Internet Security Research Group (ISRG), Kalifornien/USA, betrieben. Zertifikatsausstellung verarbeitet Domain-, Validierungs-, Server-/IP- und gegebenenfalls Betreiber-Kontaktdaten; Zertifikatsdaten erscheinen öffentlich in Certificate-Transparency-Protokollen. ISRG nennt für Ausstellungs-/Verwaltungsdaten mindestens zwei Jahre Aufbewahrung. Bei einer gesonderten Zertifikatsstatus-Abfrage kann der Browser IP-/Browser-/Betriebssystemdaten an ISRG übermitteln; die dortigen temporären Logs werden normalerweise in weniger als sieben Tagen gelöscht, bei Fehler-/Missbrauchsuntersuchungen gegebenenfalls später. Die Zertifikatsausstellung allein übermittelt keine Nutzerfragen oder Seiteninhalte. Diese Anbieterfristen sind keine Fristen unserer App-Logs. ISRG beschreibt mögliche USA-Transfers und Schutzmaßnahmen in seiner Datenschutzerklärung: https://letsencrypt.org/privacy/

Cookies und Browser-Speicher

Die aktuelle zentrale Homepage ist eine statisch exportierte Projektübersicht mit selbst gehosteten Schriftdateien. Im gemounteten Homepage-Code wurden keine Analyse-, Werbe- oder Cookie-Speicherfunktionen gefunden. Dies ist keine Aussage über alle Apps oder künftig eingebundene Dienste.

Cookies, localStorage und sessionStorage können Anmeldungen, Sprache, Einstellungen, Passkey-Metadaten und Entwurfswiederherstellung ermöglichen; app-spezifische Angaben folgen unten. Browser-Daten bleiben bis zur beschriebenen Ablaufzeit, einem App-Löschvorgang oder manueller Löschung bestehen. Geräte-/Cloud-Passkey-Synchronisation liegt auch bei Ihrem Plattformanbieter. Biometrische Prüfung erfolgt beim Authenticator; die Apps erhalten WebAuthn-Nachweise, nicht den Fingerabdruck oder das Gesichtsbild.

Vorgesehene Einordnung: unbedingt erforderlicher Speicher für ausdrücklich angeforderte Funktionen nach §25 Abs.2 Nr.2 TDDDG; zugrundeliegende personenbezogene Verarbeitung nach Art.6 Abs.1 lit.b oder f DSGVO abhängig vom Zweck. [NICHT VERIFIZIERT: SPEICHER_RECHTSGRUNDLAGEN — Erforderlichkeit jedes Schlüssels/Cookies und tatsächliches Privy-SDK-Verhalten prüfen; nicht erforderlicher Speicher benötigt vorherige Einwilligung nach §25 Abs.1 TDDDG, gegebenenfalls Art.6 Abs.1 lit.a DSGVO. Dieses Dokument ersetzt keine Einwilligungsfunktion.]

Ledger of Life — Privy, Wohnen, Karten und Stadt-KI

Ledger verwendet Privy für Passkey-Anmeldung und eingebettete Ethereum-/Solana-Wallets; der Server prüft Zugriffstokens und fragt Nutzer-/Wallet-Daten ab. Privys öffentliche Datenschutzerklärung (Stand 20.05.2026, https://www.privy.io/privacy-policy) nennt Horkos, LLC d/b/a Privy, US-Hosting und mögliche Verarbeitung in weiteren Ländern sowie einen Datenverarbeitungsvertrag mit Standarddatenschutzklauseln als Transfermechanismus. Sie unterscheidet eigene Verantwortlichkeit von Auftragsverarbeitung für Kunden und nennt Account-/Wallet-Kennungen, Geräte-/IP-Daten und Webanalysedaten; das belegt nicht, dass jede genannte Kategorie in Ledger erhoben wird. Die Developer-Bedingungen nennen abweichend Horkos, Inc. (https://www.privy.io/developer-terms-of-service). Ein vollständiger AVV/SCC-Anhang war in den geprüften öffentlichen Quellen nicht abrufbar; eine öffentliche Policy belegt keinen vom Betreiber abgeschlossenen Vertrag. [NICHT VERIFIZIERT: PRIVY_AVV_TRANSFER — tatsächlich vereinbarte Vertragspartei, AVV/SCC einschließlich Anlagen, Rollen je Zweck und Transferprüfung des Betreiberkontos bestätigen.] Vorgesehene Grundlage für angeforderte Accountfunktionen: Art.6 Abs.1 lit.b DSGVO. Passkeys sind keine vollständig selbst gehostete Identität.

Privys öffentliches Unterauftragsverarbeiter-Verzeichnis (https://trust.privy.io/subprocessors, abgerufen 10.10.2026) nennt Amazon Web Services (Datenbank; Vercel über AWS), Cloudflare, Datadog, GitHub, Google Drive, Coingecko, Google Workspace, Hightouch, Hubspot, Infura (RPC), Metabase, Socket, Semgrep und Rippling. Dies ist Privys allgemeine Liste, kein Nachweis, dass alle Anbieter Ledger-Nutzerdaten erhalten; Länder und kontoabhängige Datenflüsse sind daraus nicht vollständig ersichtlich. Die öffentliche Policy beschreibt essentielle, funktionale und Analyse-Cookies und Aufbewahrung während eines offenen Accounts oder soweit für Dienste nötig, mit möglichen längeren gesetzlichen/Streitfallfristen; sie nennt keine feste Löschfrist für Ledger. [NICHT VERIFIZIERT: PRIVY_ACCOUNT_STORAGE — tatsächlich aktiver SDK-Speicher, Zwecke/Einwilligungsbedarf, Empfänger/Regionen und accountbezogene Löschfristen bestätigen.]

Die App verarbeitet Accountkennungen, Wallet-Adressen, Inserate, Vereinbarungsdaten, Annahme-Digests, gehashte Einladungen, Nachweisnotizen und signierte Transaktionsdaten. Sichtbarkeit von Inseraten und Vereinbarungen unterscheidet sich; nicht alles ist öffentlich. Eine allgemeine Account-Löschfunktion ist laut Katalog noch nicht vorhanden; Datenschutzanfragen bleiben möglich. [NICHT VERIFIZIERT: LEDGER_ACCOUNT_RETENTION — genaue Felder, Empfänger/Zugriffe, Löschfristen und Abwicklung festlegen.]

Native Diskussionen und Meinungsbilder speichern Account-Autorschaft und einzelne Auswahl-/Operationsdatensätze. Gemeinsame Ansichten zeigen nicht die individuellen accountbezogenen Stimmen; der Datenbankbetreiber kann sie trotzdem lesen. Dies ist nicht die ZK-Stimmabgabe von mitmachen. Individuelle Antwort-/Accountverknüpfungen und Rohantworten werden30 Tage nach Schließung gelöscht; personenbezogene Autorverknüpfungen und selbstidentifizierender Diskussionstext spätestens24 Monate nach letzter Aktivität. Nur nichtidentifizierende Topologie, Positionen, ausreichend anonyme Zählwerte und eingefrorene Nachweishashes bleiben dauerhaft. Diese Funktion schreibt keine Poll-Inhalte/Hashes auf eine Blockchain. Quellinventar: Ledger docs/PRIVACY.md, Abschnitt native Diskussionen. Die freiwillige Loyalty-Kartenebene lädt den festen öffentlichen Händlerfeed von loyalty.stadtstack.eu ohne Ledger-Credentials/Cookies/Referrer; dessen Server sieht Browser-IP und Ledger-Origin.

ledger-session ist ein browsergeschriebener Anmeldemarker mit Wert1, SameSite=Lax, Laufzeit bis ein Jahr, Löschung bei Abmeldung; sein Setter setzt nicht Secure oder HttpOnly. local_ai_visitor ist ein zufälliger Besucher-Token, HttpOnly, SameSite=Strict, Pfad /api/local-ai, ein Tag; in Produktion Secure. Widerruf über den Library-Session-Endpunkt bereinigt Desk-Texte und Cookie, nicht alle Quota-/Zahlungsmetadaten. localStorage hält Interessen, Home-/Work-Kartenpins, Folgen-/Besuchspräferenzen und Einladungslinks; sessionStorage enthält Navigation sowie Request-/Receipt-/Wiederaufnahme-Referenzen. Keine allgemeine automatische lokale Ablaufzeit wurde dafür festgestellt. Privy-eigener Speicher ist separat zu prüfen.

Standortzugriff erfolgt nach einer Nutzeraktion zum Setzen eines Home-/Work-Pins; Pins werden lokal gespeichert. OpenFreeMap-Ressourcen werden über den App-Server als Proxy geladen. Der Proxy leitet Browser-IP, Cookies und Browser-Header nicht an OpenFreeMap weiter; angefragte Kachelpfade können dennoch betrachtete Gebiete erkennen lassen. Eigene Proxy-/Ingress-Logs und deren Verknüpfbarkeit sind nicht verifiziert. Vorgesehene Grundlage für Kartenfunktionen: Art.6 Abs.1 lit.b DSGVO; optionaler Geräte-Standortzugriff ist gesondert zu prüfen.

Stadt-KI verarbeitet Fragen auf freigegebenen Betreiber-/Community-Connector-Hosts oder bei direkter Konfiguration über Ollama /api/chat, nicht allein auf Ihrem Gerät. Der Host erhält die zur Inferenz nötigen Nachrichten. Die geprüften gehosteten Werte aktivieren die kostenlose Bibliothek und lassen direkte Ollama-Anbindung leer; dies belegt keine Identität oder Geografie eines tatsächlich eingesetzten GPU-Rechners. Der Code verlangt publicQuestion für Stadt-Host-Fragen und freePublicAnswers als Opt-in des kostenlosen Hosts; Auswahl prüft Verfügbarkeit/Modell und Host-Zuordnung. Drei Versuche je Besucher-Token und 30 gemeinsame Versuche je UTC-Tag sind technische Quoten. Als öffentlich markierte Desk-Fragen erlauben Stadt-Host-Routing; Zugriff auf den Desk-Datensatz bleibt auf den betreffenden Besucher/Account beschränkt, nicht automatische Veröffentlichung des Verlaufs. Quellen: Ledger src/server/local-ai.ts:24–41,199–204,237–254,402–416; src/server/local-ai-hosts.ts:290–300,431–432; deploy/values/ledger.stadtstack.eu.yaml:13–21. [NICHT VERIFIZIERT: AI_HOST_VERARBEITUNG — tatsächliche Host-Betreiber/Rechner/Standorte, Vereinbarungen sowie Host-Logging, Trainingsnutzung, Telemetrie und Host-Löschfristen bestätigen.] Keine vertraulichen oder besonderen personenbezogenen Daten eingeben.

KI-Desk-Datensätze speichern Prompt/Antwort, Modell, Kontext, Host-Auswahl/Public-Markierung, Request-Kennung/-Digest, Besucher-Token oder Account-/Wallet-Kennungen, Zeit-/Status-/Nutzungsdaten und gegebenenfalls Zahlungs-/Freigabejournale. Besucher- und Tagesquoten sowie Connector-Registrierung sind separate Kategorien. Private Desk-Texte werden nach konfigurierbarer Schonfrist bereinigt (Code-Standard 600 Sekunden nach zutreffendem End-/Ablaufzeitpunkt; konfigurierbar 0–86400 Sekunden); laufende/ungeklärte Zahlungszustände haben Ausnahmen. Bereinigung entfernt Prompt/Antwort, nicht alle Kennungen/Journale; keine garantierte exakte Löschung zehn Minuten nach Eingabe. Öffentliche @city-ai-Beiträge enthalten Antwort, Modell, Quellen und Datum. Separate Civic-AI-Jobs speichern Account-/Themen-/Beitragskennung, geerdeten Prompt, Versuch-/Status-/Zeitdaten und Publikationsmetadaten; diese fallen nicht unter Desk-Purge. Quellen: Ledger src/server/local-ai.ts:24–35,237–254,402–416; src/server/local-ai-hosts.ts:40–57; src/server/local-ai-retention.ts:14–42; src/server/civic-ai.ts:26–33,279–303,339–355. [NICHT VERIFIZIERT: AI_RECORD_RETENTION — tatsächliche Schonfrist und Bereinigungsbetrieb, Fristen/Grundlagen für erhaltene Kennungen, Quoten, Connector- und Zahlungsjournale sowie Civic-Prompts/öffentliche Beiträge festlegen.]

Der vorhandene Live-Audit vom 10.10.2026 bestätigt den aktiven, nicht pausierten CronJob ledger-of-life-backup mit 0 */6 * * * und Etc/UTC: zuletzt geplant 12:00:00 UTC, erfolgreich 12:00:20 UTC; zugehöriger Job/Pod abgeschlossen. ledger-data und ledger-backups sind eingebunden; die Backup-Volume liegt laut Provider-Audit in hel1. Zwischen Läufen kann sie abgehängt sein, ohne ungenutzt zu sein. Quellen: vorhandener cluster-ops/volume-audit-20261010.md:27–32 und volume-audit-evidence-20261010/workloads.json (CronJob ledger-of-life-backup). Das geprüfte SQLite-Backup-Skript behält die neuesten 28 Snapshots, leert vor Veröffentlichung sämtliche local-ai:request:-Prompts/-Antworten, führt VACUUM/Integritätsprüfung aus und setzt Dateirechte 0600. Andere Kategorien, Civic-Beiträge und optionale Adapter-Zugangsdaten werden nicht bereinigt. Quelle: Ledger deploy/chart/files/backup.mjs:6–44. Bei erfolgreichem Rhythmus entsprechen 28 Snapshots ungefähr sieben Tagen; keine garantierte zeitliche Maximalfrist. Der Audit belegt Job-Erfolg, nicht durchgeführten Restore oder geprüften Snapshot-Inhalt. [NICHT VERIFIZIERT: LEDGER_BACKUP_CONTROLS — weitere/offsite Kopien, Volume-/Snapshot-Verschlüsselung, vollständige Zugriffsrechte, Restore-/Löschverfahren und eventuelle zusätzliche PostgreSQL-Backups bestätigen.]

Der lokale Home Node bietet stdio-MCP. Home-Assistant-Tokens können in einer lokalen zugriffsbeschränkten Datei gehalten werden; ein über einen KI-Toolaufruf eingegebener Token kann jedoch im Assistant-Transcript landen. Pairing-Codes sind ebenfalls geheim. Optionale ältere Server-Adapter können HA-Tokens in der Datenbank speichern; diese Pull-Funktion ist in den geprüften gehosteten Werten deaktiviert. [NICHT VERIFIZIERT: HOME_NODE_TOKEN_POLICY — aktive Adapter, lokale Backups, Token-Scope/Widerruf und Assistant-Anbieter-Retention bestätigen.] Keine Tokens in diese Erklärung oder öffentliche Fragen aufnehmen.

Die vorhandene Abnahme HOSTED_CITY_APP_2026-10-09.json dokumentiert eine tatsächliche Qwen-Antwort (qwen3.8:27b-ud-q3-k-xl) über die vom Eigentümer autorisierte private LAN-Schnittstelle eines lokalen Home Nodes, während der öffentliche Internetzugang der Seite blockiert war. Die separate lokale HTTP-Seite sendet keine Ledger-Accounts/Wallets und löscht ihren Gesprächsverlauf beim Reload. Lokaler HTTP-Verkehr ist für Netz-/Node-Betreiber lesbar. Die damalige gehostete @city-ai-Abnahme meldete den einzigen Host noch ohne freePublicAnswers-Opt-in; sie beweist keine erfolgreiche freie öffentliche Antwort. LAN-Inferenz beweist weder geografischen Standort noch eine Host-seitige Nichtprotokollierung/Nichttrainingsgarantie.

Die geprüften Zahlungsmanifeste verwenden Solana devnet und Robinhood testnet. Wallet-Konfiguration enthält zusätzlich Mainnet-Definitionen; das ist kein Nachweis ausgeführter Mainnet-Zahlungen. Aktive Netz-/RPC-Overrides müssen bestätigt werden.

Ladenrunde / ZK Loyalty

Ladenrunde nutzt WebAuthn/PRF-Passkeys für Safe-Smart-Accounts (ERC-4337) und einen HKDF/AES-256-GCM-verschlüsselten lokalen Identitätstresor. localStorage enthält Credential-ID/öffentlichen Schlüssel, Ursprung, Safe-Adresse, Tresor, öffentlichen Commitment-Wert, Mitgliedschafts-/Block-Caches und Shop-Entwürfe. Für Entwürfe/Caches gibt es keine automatische Löschfrist. Die entsperrte Identität sperrt nach fünf Minuten sowie beim Verlassen/Verbergen der Seite; gespeicherte Metadaten bleiben. Sprachpräferenz: einjähriges SameSite=Lax-Cookie, Secure bei HTTPS.

Heruntergeladene verschlüsselte Identitäts-Backups benötigen ursprünglichen Passkey/Ursprung zur Wiederherstellung. Lokale Löschung entfernt keine Blockchain-Daten oder eigenen Backup-Dateien. Wallet-Adressen, Mitgliedschaften und Transaktionsdetails sind öffentlich. Zama FHE auf Sepolia verschlüsselt Punktestände, nicht sämtliche Metadaten. Entschlüsselungsanfragen übermitteln Adresse/Signatur/Vertragsbezug an Gateway/Relayer. SDK/WASM kommt von derselben Origin; Default-RPC im geprüften Code ist ethereum-sepolia-rpc.publicnode.com.

Shop-/Adresssuche nutzt gebündelte OSM-Daten lokal. Karten laden direkt von tiles.openfreemap.org; IP und technische Ressourcenanfragen werden dafür übertragen. Anbieter ist Hyperknot Software Kft., Ungarn. Dessen öffentliche Datenschutzerklärung (Stand8.Oktober2026, https://openfreemap.org/privacy/) nennt keine Accounts/Cookies/Tracking, Access-Logs ohne IP, allgemeine Loglöschung nach sieben Tagen sowie mögliche IP-/URL-Fehlerlogs. Sicherheitsbedingte IP-Protokollierung endet nach Abschluss der Untersuchung oder spätestens30 Tagen. Cloudflare kann als CDN verwendet werden und hat eigene Verarbeitung. Dies sind Aussagen des Anbieters, keine eigene Live-Prüfung seiner Server.

Shop-Veröffentlichung übermittelt Name, Stadt, Koordinaten, Programm-ID und Eigentümeradresse an die App; signierte Registry-Einträge werden in SQLite öffentlich angezeigt. Vorgesehene Grundlage: angeforderte Funktionen Art.6 Abs.1 lit.b DSGVO, Missbrauchsschutz lit.f. Gateway-Sitzungen zehn Minuten, Challenges zwei Minuten, Händler-Challenges zehn Minuten mit Bereinigung bei neuer Ausstellung; IP-/Origin-Hash-Throttles sind minutenbezogen im Speicher. Gültigkeit ist keine allgemeine Löschfrist.

[NICHT VERIFIZIERT: LOYALTY_EMPFAENGER_RETENTION — ausgeführte Verträge/aktiv konfigurierte Zama-, RPC-, Bundler-/Gateway-Dienste und Drittlandgarantien sind nicht aus öffentlichen Code-Defaults belegt. OFFENE BETREIBERENTSCHEIDUNG: Registry-Aufbewahrung, Löschung und konkreter SQLite-Backup-Zeitplan/-Aufbewahrung; geprüfter Chart hat keine solche Automatik.]

spiel — browserlokaler Spielstand

Das Spiel speichert Editions-/Probenfortschritt, Aktivitätsergebnisse und Entdeckerpass-Stempel im localStorage. Diese Daten bleiben browserlokal bis zur Löschung der Website-Daten; keine automatische Ablaufzeit ist in den geprüften Pfaden festgelegt. Welt-/Audiodateien werden von derselben Origin geladen. In den geprüften App-Pfaden wurde kein Wallet-, Gnosis-, Anmelde-, Analyse- oder Standortaufruf gefunden. Ein generischer Sidebar-Cookie-Setter hat keinen gefundenen App-Aufrufer.

nginx deaktiviert Access-Logs und sendet nur kritische Fehler an stderr. Die bestehende Live-Evidenz vom 10.Oktober bestätigt Helm-Revision13 und Bytegleichheit der geprüften Seiten zum Image sha256:4f42aba5b4218458b5abd9f0413ffcd8c286869384634e3bb95c2ace92fdea48 (Commit dac7a05348336a15160c5fc458f72e1c4eb4e842). Hosting: Helsinki, siehe gemeinsamer Hosting-Abschnitt. Vorgesehene Grundlage für angeforderte Spielstandsfunktionen: Art.6 Abs.1 lit.b DSGVO, technisch notwendiger Speicher §25 Abs.2 Nr.2 TDDDG. [OFFENE BETREIBERENTSCHEIDUNG: SPIEL_LIVE_RETENTION — gewünschte lokale Speicherfrist und etwaige Betreiber-Backups festlegen; Infrastruktur-Loglimits siehe gemeinsamer Abschnitt.]

mitmachen — Berechtigung und ZK-Stimmabgabe

Die Beteiligung ist nach der geprüften Policy 2026-10-09.closed geschlossen: Platzhalter-Attestor-Keys ermöglichen keine reale Bestätigung. Die Host-Werte lassen CHAIN_ID, REGISTRY_ADDRESS und PUBLIC_RPC_URL leer; eine aktive Blockchain-Anbindung wird deshalb nicht behauptet. OPERATOR_IS_MUNICIPALITY ist false. Bei einer späteren Öffnung muss diese Erklärung die dann tatsächlichen Rollen, Adapter und Chain-Empfänger abbilden.

WebAuthn fordert Resident-Key, Benutzerprüfung und PRF. localStorage enthält rollen-/gemeindebezogene Credential-IDs. Abstimmungs-/Nostr- und Attestor-Schlüssel werden über gemeindebezogenes PRF/HKDF abgeleitet. SQLite verarbeitet Subjekt-Public-Key ↔ Voting-Commitment ↔ Nachweis-/Enrollment-Verknüpfung, Authentifizierungsereignisse, Attestierungen/Widerrufe und Zeitpunkte. Das ist kein System ohne personenbezogene Metadaten.

Der Browser erstellt einen ZK-Mitgliedschaftsnachweis und reicht Stimmzettel ohne Anmeldeidentität ein. Gespeichert werden Poll-ID, Nullifier, Auswahlindex, Signal-Hash, Nachweis, öffentliche Anchor-Blätter und Ergebnis. ZK schützt die Identitätszuordnung im Protokoll, nicht gegen jede IP-/Timing-Korrelation. Bei aktivierter Registry würden Gemeinde, Anchor-Root, Metadatenhash, Zeitfenster und Ergebnishash/-anzahl öffentlich; einzelne Stimmen wären keine einzelnen Blockchain-Transaktionen.

Der Chart sieht Backups alle sechs Stunden UTC vor, Integritätsprüfung, Datei-Modus0600 und neueste28 Snapshots. Das Skript verschlüsselt nicht selbst; dies ist keine garantierte Sieben-Tage-Frist. Akzeptierte Stimmzettel/geöffnete Anchors sind durch SQL-Trigger vor Änderung/Löschung geschützt; ein allgemeiner Purge fehlt. Receipt-/Cache-Gültigkeit ist keine Löschfrist. [OFFENE BETREIBERENTSCHEIDUNG: MITMACHEN_LOESCHUNG_BACKUP — zweckgebundene Aufbewahrung und Rechteabwicklung auch für immutable Records/Backups festlegen; Zugriff/Verschlüsselung/Offsite-Wiederherstellung sind technisch nicht aus der Evidenz belegt.] Kameranutzung betrifft lokale QR-Erfassung; Geolocation ist serverseitig untersagt.

Civic MCP und persönliche Tokens

mcp.stadtstack.eu/mcp stellt veröffentlichte kommunale Quelldaten nur lesend für KI-Werkzeuge bereit. Es gibt keinen Modellaufruf durch diesen Server; die veröffentlichten Datensätze werden nicht bei jeder Anfrage neu gesammelt. Der Server prüft einen persönlichen Bearer-Token gegen ID und SHA-256-Hash. Die Grenzen sind 60 Anfragen je UTC-Minute und Token, vier parallele Anfragen je Token, 32 KiB Request-Body und 30 Sekunden Request-Deadline. Die minutenbezogenen Zähler und Parallelitätszustände liegen im Arbeitsspeicher und werden bei Neustart zurückgesetzt. Das Protokoll ist zustandslos, ohne persistente MCP-Sitzung oder implementiertes OAuth. Tokens sind Zugangsdaten: niemals in Fragen, URLs oder öffentlichen Beiträgen teilen.

Die dokumentierte Ausgabe erzeugt einen persönlichen Token aus 32 kryptografisch zufälligen Bytes. Der Klartext liegt in einer persönlichen lokalen Datei mit Modus 0600 in einem geschützten 0700-Verzeichnis; das Ausgabemanifest enthält nur Token-ID und SHA-256-Hash. Nur dieses Hash-Manifest wird als geschütztes Kubernetes Secret zum Server übertragen und beim Prozessstart geladen. Widerruf entfernt den Hash: wirksam wird er erst, nachdem das aktualisierte Secret veröffentlicht und jede Serverinstanz neu gestartet wurde. Rotation verwendet eine neue ID. Die alte lokale Klartextdatei wird beim Widerruf nicht automatisch gelöscht; ihr Besitzer kann sie nach Widerruf und Beendigung der Clients entfernen. Eine automatische zeitliche Token-Ablauffrist ist im dokumentierten Verfahren nicht vorgesehen. [BETREIBERBESTÄTIGUNG: MCP_TOKEN_AUFBEWAHRUNG — tatsächliches Ausgabe-/Personenzuordnungsregister, Widerrufsverantwortung sowie Löschfristen für lokale Dateien, entfernte IDs/Hashes und Betreiber-/Secret-Backups bestätigen.]

Die MCP-Anwendung protokolliert aggregierte Zähler, keine IPs, Token-IDs, URLs, Fragen, Request-Bodies, Tool-Argumente oder Ergebnisse. Der gespeicherte Live-Ingress unterdrückt Backend-Request-Logging; die gemeinsame Lücke zu HAProxy-Frontend-/Vor-Routing-Logs ist im Hosting-Abschnitt beschrieben. Vorgesehene Grundlage für Zugangskontrolle und Missbrauchsschutz: Art. 6 Abs. 1 lit. f DSGVO. Technische Quelle: lokal geprüfte Projektdokumentation stadtstack-data/docs/HOSTED_MCP.md, Abschnitte HTTP-Vertrag, Ausgabe, Widerruf und Rollout.

Ihre gewählte KI-Anwendung kann Prompts, Antworten, Accountdaten und abgerufene kommunale Quellen nach ihren eigenen Bedingungen verarbeiten. Der Civic-MCP-Server ist nicht deren Modellanbieter. Dokumentierte Client-Optionen sind Claude Code, lokale stdio-Bridges für unterstützte Claude-Desktop-/Cursor-Versionen und Cursor mit dynamischem Bearer-Header; deren native GUI-Kompatibilität wurde nicht bestätigt. ChatGPTs nativer OAuth-Connector wird durch diesen Bearer-only-Dienst nicht unterstützt. Konkreter Client, Anbieter, Verarbeitungsländer und Transferbedingungen ergeben sich aus Ihrer Wahl, nicht aus einer serverseitig festgelegten Modellintegration. Prüfen Sie die Datenschutzhinweise Ihres Clients; geben Sie keine vertraulichen Daten oder Tokens in Prompts ein.

Wallets und öffentliche Blockchains

Wallet-Adressen, Transaktionen, Signaturen, Beträge, Zeitpunkte und veröffentlichte Vertrags-/Mitgliedschaftsdaten können öffentlich, dauerhaft und mit anderen Informationen verknüpfbar sein. Auch pseudonyme Testnetz-Adressen können personenbezogen sein. Ledger nutzt Solana devnet und Robinhood testnet; Ladenrunde nutzt Sepolia. Gnosis mainnet betrifft nur die bestehende kleine Mesh-Demo, nicht eine allgemeine Freigabe für Echtgeld-Dienste.

Öffentliche Blockchain-Einträge können wir nicht aus allen Kopien löschen oder berichtigen. Das hebt DSGVO-Rechte nicht auf: wir prüfen Anfragen, löschen beeinflussbare Off-Chain-Daten soweit geboten und erläutern konkrete Grenzen. Geben Sie keine Namen, Adressen, Ausweisdaten oder private Informationen in öffentliche Payloads ein. RPC-Dienste und Explorer können IP-/Anfragedaten erhalten; Explorer werden beim Öffnen eines Links kontaktiert. [NICHT VERIFIZIERT: CHAIN_EMPFAENGER_TRANSFER — tatsächlich konfigurierte RPC-/Bundler-/Gateway-Anbieter, Verarbeitungsländer, Rechtsgrundlagen und Drittlandmechanismen bestätigen.]

Offline-Mesh / Ledger Lite (gesonderte Labor-Demo)

Die bestehende lokale Demo verwendet eine neue ledger-lite.v1-Speichernamenswelt; ältere Demo-Speichereinträge werden nicht automatisch entfernt. Ein ausdrücklich erstellter Demo-Privatschlüssel liegt unverschlüsselt im localStorage; gespeicherte signierte Transaktionen und Jobdaten ermöglichen Wiederaufnahme. Nur frische Demo-Schlüssel und winzige Beträge verwenden. Lokaler HTTP-Zugriff ist nicht verschlüsselt; ein kompromittierter Spot oder LAN-Angreifer kann Code und Daten verändern. Das ist keine vertrauenslose Wallet.

Die Demo sendet eine Nullwert-Selbstüberweisung auf Gnosis mainnet (Chain 100); Gas wird verbraucht. Kurze KI-Fragen (maximal 384 UTF-8-Bytes) werden über LoRa/Reticulum zum vorhandenen lokalen reticulum-qwen-Gateway übertragen, das Qwen auf dem Betreiber-GPU-System aufrufen kann. Gesprächsverlauf und City-Pack werden nicht mitgesendet; Antworten sind auf 600 Bytes begrenzt. Eine ausstehende Frage bleibt zur Wiederaufnahme im Browser gespeichert. Der Spot sendet Fragen/Antworten standardmäßig nicht in Betreiber-Logs und unterdrückt beliebige HTTP-URL-/Header-/Body-Access-Logs.

Der Spot hält Jobzustände und Ergebnisse im Arbeitsspeicher. Abgeschlossene/fehlgeschlagene Jobs werden beim nächsten Einreihen oder Statusabruf nach mindestens einer Stunde entfernt; bei Erreichen der Grenze von 128 Jobs können ältere abgeschlossene Jobs früher verdrängt werden. Das ist keine stündliche Hintergrundlöschung und gilt nicht für Browser-Speicher, gespeicherte signierte Transaktionsdateien, Funkzustand oder andere Logs. Signierte Transaktionsdateien und die dauerhaften Client-/Gateway-Budgetreservierungen bleiben für Wiederaufnahme und das lebenslange Demo-Ausgabenlimit erhalten; Neustart setzt dieses Limit nicht zurück. Löschen oder Zurücksetzen zur erneuten Nutzung des Budgets ist nicht zulässig.

Der dokumentierte Gateway-RPC ist https://rpc.gnosischain.com ; Myotis läuft lokal am Gateway. Der Browser selbst kontaktiert keinen öffentlichen RPC/CDN-Anbieter. Gateway-Logs können Anforderungs-ID, Nutzlastgröße, öffentliche Adressen, Transaktionshash und Ergebnis enthalten; Reticulum verarbeitet Transportidentitäten und Funk-/Routenmetadaten. Die Ein-Stunden-Jobgrenze beweist keine entsprechende Löschung dieser Daten oder von Qwen-/Ollama-Systemlogs. [BETREIBERBESTÄTIGUNG: MESH_BETRIEB_RETENTION — tatsächliche Gateway-RPC-Auswahl, Betreiber/Verarbeitungsländer dieses RPC, Funk-/Gateway-/Modell-Logkonfiguration und Löschfristen, Ende der Demo sowie kontrollierte Löschung/Archivierung von Transaktions-, Budget- und Backup-Daten ohne Umgehung des Ausgabenlimits bestätigen.] Quellen: gnosis-mesh-relay README (Ledger Lite, Safety and funding), spot.py (HISTORY_TTL und _prune), gateway.py und chain.py im lokalen geprüften Projekt.

Ihre Rechte, Löschung und Beschwerde

Sie haben nach Maßgabe der DSGVO Rechte auf Auskunft (Art. 15), Berichtigung (Art. 16), Löschung (Art. 17), Einschränkung (Art. 18) und Datenübertragbarkeit (Art. 20). Bei Verarbeitung auf Grundlage berechtigter Interessen können Sie aus Gründen Ihrer besonderen Situation widersprechen (Art. 21). Eine erteilte Einwilligung können Sie jederzeit mit Wirkung für die Zukunft widerrufen. Es besteht ein Beschwerderecht bei einer Datenschutzaufsichtsbehörde (Art. 77), insbesondere am Wohnort, Arbeitsort oder Ort des mutmaßlichen Verstoßes. Kontaktieren Sie uns unter contact@agentcart.eu; wir verlangen nur für die Anfrage erforderliche Identitätsnachweise, keine unnötigen Ausweiskopien.

Für den hier benannten privaten Verantwortlichen mit Sitz in Strausberg ist die Landesbeauftragte für den Datenschutz und für das Recht auf Akteneinsicht Brandenburg (LDA Brandenburg) die einschlägige Landesaufsicht: Stahnsdorfer Damm 77, 14532 Kleinmachnow; Poststelle@LDA.Brandenburg.de; Telefon +49 33203 356-0. Andere nach Art. 77 zuständige Beschwerdestellen bleiben möglich. Quelle: https://www.lda.brandenburg.de/lda/de/ueber-uns/kontaktanreise/

Vorläufige Einschätzung, keine festgestellte Befreiung: Bei einem kleinen privat betriebenen Pilotprojekt ohne die folgenden Auslöser ist voraussichtlich kein Datenschutzbeauftragter zu benennen. Art. 37 DSGVO verlangt ihn insbesondere bei Behörden/öffentlichen Stellen (mit der gesetzlichen Ausnahme für Gerichte), umfangreicher regelmäßiger und systematischer Überwachung als Kerntätigkeit oder umfangreicher Verarbeitung besonderer Datenkategorien bzw. strafrechtlicher Verurteilungen/Straftaten als Kerntätigkeit. § 38 Abs. 1 BDSG verlangt ihn zusätzlich bei in der Regel mindestens 20 ständig mit automatisierter personenbezogener Verarbeitung beschäftigten Personen; unabhängig von der Personenzahl auch bei DSFA-pflichtiger Verarbeitung oder geschäftsmäßiger Verarbeitung für Übermittlung, anonymisierte Übermittlung sowie Markt-/Meinungsforschung. Auch ein Treueprogramm kann Überwachung sein; die tatsächliche Größenordnung und Kerntätigkeit sind entscheidend. Politische Meinungen in kommunalen Beiträgen/Abstimmungen können besondere Datenkategorien nach Art. 9 DSGVO sein; Beteiligungsfunktionen brauchen deshalb eine sorgfältige dokumentierte Risikoprüfung nach Art. 35 DSGVO, einschließlich DSFA-Pflicht bei voraussichtlich hohem Risiko. Kleine Personenzahl oder verschlüsselte Stimmzettel sind keine pauschale Ausnahme. [BETREIBERBESTÄTIGUNG: DSB_PFLICHT — Personenzahl, tatsächliche Kerntätigkeiten/Größenordnung und DSFA-/Übermittlungs-/Forschungsfälle dokumentiert bewerten; gegebenenfalls unabhängigen DSB benennen und Kontakt ergänzen. Die allgemeine Datenschutzadresse ist nicht automatisch ein DSB-Kontakt.] Quellen: https://www.edpb.europa.eu/sme/be-compliant/data-protection-officer_en ; https://www.gesetze-im-internet.de/bdsg_2018/__38.html ; https://www.edpb.europa.eu/sme/be-compliant/be-compliant_en

[BETREIBERBESTÄTIGUNG: LOESCHKONZEPT — für Account-, Beitrags-, Beteiligungs- und Kontaktanfragedaten zweckbezogene Speicherfristen und gesetzliche Aufbewahrung sowie Backup-Löschung und Wiederherstellungsprozess festlegen und bestätigen. Technische Token-/Mesh-Grenzen in den jeweiligen Abschnitten ersetzen dieses Konzept nicht.]

Die Nutzung ist freiwillig; für geschützte Funktionen sind Authentifizierung und technisch nötige Angaben erforderlich. Ohne sie sind diese Funktionen nicht verfügbar. [NICHT VERIFIZIERT: ART13_REVIEW — Pflicht-/Vertragsangaben, Empfänger, Art. 14-Quellen bei Fremddaten, automatisierte Entscheidungen einschließlich Art. 22, spezielle Datenkategorien und alle vorgesehenen Rechtsgrundlagen je Funktion vollständig rechtlich prüfen.] KI-Antworten sind keine amtlichen Entscheidungen und ersetzen keine Rechts-, Medizin- oder Notfallberatung.

Kontaktformular und private selbst gehostete Inbox

Das Kontaktformular unter /kontakt verarbeitet Ihre Nachricht, Antwort-E-Mail und optionalen Namen zur Beantwortung. Keine Ausweise, Gesundheitsdaten oder vertraulichen politischen Angaben senden. Die Angaben sind freiwillig; ohne Nachricht/Antwortadresse können wir die Formularanfrage nicht bearbeiten. Grundlage: Art6 Abs.1 lit.b DSGVO bei vorvertraglichen Anfragen, sonst lit.f (berechtigtes Interesse an direkter Kommunikation); Missbrauchsschutz lit.f.

Nach erfolgloser iCloud-Authentifizierung wurde SMTP vollständig abgeschaltet. Das Formular sendet keine Nachricht an Apple/iCloud oder einen anderen Mail-/Formanbieter. Es speichert sie in der eigenen privaten Kontakt-Inbox auf der Hetzner-Infrastruktur. Nachrichten werden vor dem Schreiben mit AES-256-GCM verschlüsselt; der Schlüssel liegt getrennt als zugriffsbeschränktes Dienst-Secret. Verschlüsselung schützt nicht gegen einen kompromittierten laufenden Dienst oder einen privilegierten Betreiber mit Schlüsselzugriff. Nachrichten werden automatisch90 Tage nach Eingang gelöscht; dies ist die jetzt beauftragte Kontaktservice-Frist, nicht die noch zu genehmigende allgemeine Retention anderer Apps.

Kein Payload-/IP-Logging durch den Kontaktserver. Begrenzte IP-/globale Rate-Limit-Zähler bestehen vorübergehend im RAM. Honeypot, Mindestfüllzeit und Größenlimits begrenzen Missbrauch. Die öffentliche API stellt keine Inbox-/Admin-Routen bereit. Adminzugriff erfolgt über separaten privaten Port mit Authentifizierung und ohne öffentliche Ingress-Route, vorerst mittels autorisiertem kubectl port-forward über bestehenden Verwaltungszugang, später nach eigener Freigabe über NetBird.

Der eigene ntfy-Dienst unter https://ntfy.stadtstack.eu ist nur authentifiziert nutzbar, standardmäßig deny-all. Ein privates Topic benachrichtigt ausschließlich den Eigentümer mit „Neue Kontaktanfrage auf stadtstack.eu“, ohne Inhalt, Name oder Antwortadresse. Der Kontaktservice besitzt nur Publish-Rechte, der Eigentümer Subscribe-Rechte. Detailzugriff bleibt in der privaten Admin-Inbox. Für iOS-Sofortzustellung sendet ntfy einen poll_request an https://ntfy.sh: SHA-256 des Topic-URLs und ursprüngliche Nachrichten-ID, nicht den Kontakttext. Laut https://docs.ntfy.sh/config/#ios-instant-notifications wird der Trigger über Firebase (Google) und APNS (Apple) zugestellt; iOS ruft danach die generische Meldung bei unserem Server ab. Inhaltsfrei bedeutet nicht garantiert anonym: Empfänger können Topic-Hash, ID, Zeitpunkt, Transport-IP und gerätebezogene Push-Metadaten verarbeiten. [NICHT VERIFIZIERT: PUSH_PROVIDER_RETENTION_TRANSFER — konkrete Upstream-/Firebase-/APNS-Speicherfristen und Transfergarantien rechtlich prüfen.] Eigene ntfy-Cache-/Auth-Daten haben getrennte Aufbewahrung; Benachrichtigungsfehler verwerfen keine gespeicherten Anfragen. Exporte, eigene Antwort-E-Mail und zusätzliche Backups benötigen gesonderte Löschregeln.

Aufbewahrung personenbezogener Daten und dauerhafte öffentliche Evidenz

Diese vom Eigentümer freigegebenen Fristen gelten ausschließlich für personenbezogene Daten: Accounts, Beiträge, individuelle Meinungsbild-Antworten, KI-Fragen, Logs und Kontaktanfragen. Wir löschen oder anonymisieren diese Daten spätestens nach den nachstehenden Fristen. Die organisatorische Löschpflicht besteht unabhängig vom Stand automatisierter Jobs; eine noch nicht live verifizierte Automatik wird nicht behauptet.

Öffentliche kommunale Sach-/Quelldaten (Ratsunterlagen, Beschlüsse, Haushaltszahlen, Messwerte, OSM und belegte Fakten) und tatsächlich anonymisierte/aggregierte Ergebnisse (Meinungsbilder, Topic-Outcomes, Release-Manifeste/-Hashes) bleiben dauerhaft für Städtevergleich und Nachprüfbarkeit erhalten. Soweit dabei personenbezogene Restdaten erforderlich bleiben, bedarf dies einer gesonderten Rechtsgrundlage und Prüfung der Archiv-/Forschungszwecke mit Garantien nach Art.89 DSGVO; Art.89 ist keine pauschale Rechtsgrundlage oder Freistellung. Namen privater Personen werden maskiert oder nicht erneut veröffentlicht; Angaben von Amtsträgern in amtlicher Funktion nur soweit zweckbezogen erforderlich. Quellenverweise bleiben möglich, ohne private Namen unnötig zu spiegeln. Kleine Gruppen/seltene Ergebnisse sind nicht automatisch anonym.

Blockchains sind technisch dauerhaft: keine zusätzlichen identifizierenden oder sensiblen Payloads (Namen, Adressen, Ausweise, private Meinungen) veröffentlichen. Wallet-Adressen und Signaturen sind von Natur aus öffentlich und können selbst personenbezogen sein; eine Löschbarkeit aller Blockchain-Kopien wird nicht zugesichert.

Civic-Beiträge und native Diskussionen: personenbezogene Account-/Autorverknüpfungen und selbstidentifizierenden Freitext spätestens24 Monate nach letzter Aktivität löschen oder echt, nicht rückverknüpfbar anonymisieren. Nichtidentifizierende Topologie, Positionen, ausreichend anonyme Zählwerte und eingefrorene Nachweishashes dürfen dauerhaft bestehen bleiben. Nutzer können vorher Löschung beantragen. Civic-AI-Arbeitsprompts und Job-Text:30 Tage nach Abschluss, soweit keine laufende Fehlerklärung erforderlich ist; veröffentlichte Antworten folgen der Beitragsfrist. Öffentliche Quellenzitate ohne Personenbezug können als Aggregat/Evidenz bestehen bleiben.

Individuelle Meinungsbild-Antworten: Account-/Antwort-Verknüpfung und Rohantwort30 Tage nach Schließung löschen; nur ausreichend große, nicht personenbeziehbare Aggregate weiterführen. Kleine Gruppen/seltene Optionen nicht als vermeintlich anonym veröffentlichen. Technische Missbrauchs-/Operationskennungen ebenfalls nach30 Tagen entfernen, soweit kein belegter Sicherheitsfall offen ist. Private politische Meinungen nicht auf Blockchain schreiben.

Accounts: bis Löschanfrage oder spätestens24 Monate Inaktivität insgesamt; die30-tägige Warn-/Exportfrist liegt vor dieser Löschgrenze, nicht danach. Warnung und Möglichkeit zum Herunterladen/Export werden in der App bereitgestellt; eine E-Mail-Erinnerung wird nicht zugesichert. Test-Vereinbarungen und Transaktionsjournale: personenbezogene Off-Chain-Daten nur nach nachweislichem Abschluss/Kündigung eines Testablaufs nach12 Monaten löschen; aktive, ausstehende oder unklare Zahlungs-/Wiederherstellungszustände bis zur Klärung erhalten. Gesetzlich erforderliche echte Vertrags-/Steuerunterlagen nur im konkret vorgeschriebenen Umfang/Zeitraum gesondert aufbewahren, nicht pauschal den ganzen Testaccount. Eine reale rechtliche Pflicht muss vor der Aufbewahrung feststehen.

Händlerregistry: aktive Veröffentlichungen bis Widerruf/Schließung; personenbezogene Off-Chain-Registry-Einträge spätestens30 Tage nach Entfernung löschen, öffentliche sicherheitsnotwendige Revokationsnachweise minimal halten. Öffentliche Sepolia-Einträge sind technisch nicht aus sämtlichen Blockchain-Kopien löschbar.

MCP-Tokens: gültig bis explizitem Widerruf, wie bestehend. Widerruf durch Hash-Entfernung und Neustart aller Instanzen; lokale Klartextdatei danach löschen. Personenbezogenes Ausgaberegister und nicht mehr benötigte alte Hash-Kopien binnen30 Tagen löschen; minimaler nichtpersonenbezogener Sperrstatus nur soweit nötig. Keine neue automatische Gültigkeitsdauer behauptet.

Betriebs-/Fehler-/Sicherheitslogs: maximal14 Tage, außer konkret dokumentierter Sicherheitsvorfall bis Abschluss mit erneuter30-tägiger Prüfung; keine Prompt-/Kontaktmessage-Inhalte oder Secrets loggen. Kontaktservice-IP-Schlüssel sind ausschließlich vorübergehend im RAM. Die14-Tage-Richtlinie ist organisatorisch freigegeben, kein aus unvollständigen HAProxy-/Talos-Evidenzen bewiesener automatischer Default.

Backups: vorhandene28 erfolgreiche Snapshot-Rotationen behalten; keine garantierte Sieben-Tage-Maximalfrist. Gelöschte Daten können bis Ablauf in gesperrten Sicherungen bleiben; bei Restore Löschjournal erneut anwenden. Löschvermerke ohne Inhalte werden zur Verhinderung einer Wiederherstellung bis zu 90 Tage aufbewahrt. Davon getrennt werden minimale pseudonyme, inhaltsfreie Laufzeitsperren für stillgelegte Vereinbarungs-, Account- und Gerätezustände nur so lange aufbewahrt, wie zur Verhinderung veralteter Operationen oder deterministischer Wiederanlage erforderlich (Art.6 Abs.1 lit.f DSGVO). Diese Sperren enthalten keine Freitexte, Wallet-Adressen, Signaturen oder Kontaktdaten; dies erlaubt keine pauschale unbefristete Aufbewahrung von Nutzerdaten. Die Restore-/Sperrautomatik wird nicht als bereits live verifiziert behauptet. Desk-Texte bleiben aus Ledger-Backups entfernt. Kontaktservice: eigener verschlüsselter Store mit automatischer90-Tage-Löschung ab Eingang, nicht ab Erledigung. Keine iCloud-SMTP-Zustellung. Eigenständig exportierte/gesicherte Kopien und Antwortkorrespondenz müssen gesondert zweckbezogen gelöscht werden.