Zum Inhalt springen
atvoto

Löschung eines Kontos

Status: Konzept, nicht umgesetzt (2026-10-26), ROADMAP Stufe 0c. Rechtsgrundlage: VERFASSUNG Art. 16a. Zuständig ist der Betreiber des PDS, nicht der Client (ARCHITECTURE_SPLIT §12 Nr. 1).

Grundsatz

Abschnitt betitelt „Grundsatz“
  • Was im Repo der Person liegt, verschwindet mit dem Konto: Profil, Kommentare, Bewertungen und die Originale von Argumenten und Gutachten. Löscht der PDS das Konto, sind die Daten dort weg.
  • Was auf das Community-Konto übergegangen ist, bleibt: angenommene Argumente und abgegebene Gutachten als kanonische Kopie. Das Recht auf deren Löschung tritt die Person beim Einreichen ab (Art. 16a Abs. 3).
  • Der Store muss nachziehen. Seine Tabellen sind eine Projektion. Ohne eigenes Zutun bleiben die Daten der gelöschten Person dort stehen.

Ablauf

Abschnitt betitelt „Ablauf“
  1. Die Person verlangt die Löschung beim Client (Art. 16a Abs. 1).
  2. Der Client meldet es dem Betreiber.
  3. Der Betreiber löscht das Konto auf dem PDS (Admin-Skript, noch zu schreiben). Der PDS sendet ein #account-Event (active: false, status: deleted).
  4. Der Indexer reagiert auf dieses Event (siehe unten).
  5. Die Mitgliedschaften werden widerrufen (registry.participants.revoked_at).

Bei externen Konten (ROADMAP.md, Stufe 1) entfallen die Schritte 2 und 3: Die Person löscht das Konto bei ihrem Anbieter, und das Event kommt über das Relay.

Was der Indexer tun muss

Abschnitt betitelt „Was der Indexer tun muss“

Heute verarbeitet der Indexer nur Records. Beim Löschen eines Kontos sendet der PDS keine einzelnen Lösch-Events für die Records, nur das #account-Event. Ohne Anpassung bleibt deshalb alles im Read-Model stehen.

Neu: das #account-Event verarbeiten und die Daten der DID entfernen bzw. markieren:

Tabelle Inhalt Vorschlag
app_comments Kommentare löschen bzw. deleted = true
app_likes Bewertungen löschen bzw. deleted = true
app_profiles Anzeigename, Profil löschen
app_activity_seen gelesene Aktivitäten löschen
app_acceptance_queue noch nicht verarbeitete Einreichungen offene Einträge verwerfen
app_content_creations Kontingent-Ledger offen (Frage 4)
app_arguments (author_did, origin_uri) kanonische Kopien bleiben, offen ist die Herkunft (Frage 1)
app_peerreview_responses (reviewer_did) Gutachten bleiben, offen (Frage 2)
app_peerreview_invitations (invitee_did) Einladungen offen (Frage 2)
registry.participants Mitgliedschaften widerrufen
labels (geplant) Labels auf dem Konto und seinen gelöschten Beiträgen entfernen (VO Moderation § 9 Abs. 1)

Deaktivieren ist nicht Löschen. status: deactivated oder takendown sind vorübergehend. Dann ausblenden statt löschen und bei active: true wieder zeigen (vgl. MODERATION.md).

Offene Fragen

Abschnitt betitelt „Offene Fragen“
  1. Herkunft an der kanonischen Kopie. Argumente tragen authorDid und originUri auf das gelöschte Original (Art. 16a, Diskussion). Bleibt die DID sichtbar? Varianten: unverändert lassen (die DID ist pseudonym und ohne Konto nicht mehr auflösbar), oder die Kopie im Community-Konto neu schreiben ohne authorDid und originUri. Neu schreiben ändert den CID, und Verweise darauf (Kommentare, Bewertungen, Gutachten) zeigen dann auf eine ältere Fassung.
  2. Gutachten und Einladungen. Die Records im Community-Konto (peerreview.response, peerreview.invitation) nennen die DID der Gutachterin. Sie sind öffentlich und nachzählbar (peerreview.result). Bleibt die DID drin, oder werden sie pseudonymisiert? Wenn ja, wie, ohne die Nachzählbarkeit zu verlieren?
  3. Nachträgliche Änderung von Ergebnissen. Fallen Bewertungen weg, ändert sich die errechnete Haltung (Art. 34) rückwirkend. Ist das gewollt, oder wird für abgeschlossene Vorlagen eingefroren?
  4. Kontingent-Ledger. Löschen (Datensparsamkeit) oder behalten (sonst setzt ein neues Konto die Kontingente zurück)? Das Ledger hängt an der DID, ein neues Konto hat ohnehin eine neue DID. Spricht also für Löschen.
  5. Antworten auf gelöschte Kommentare. Antworten anderer Personen bleiben. Wie zeigt die AppView den fehlenden Elternkommentar an („gelöscht“)?
  6. Backups. Wie lange bleiben gelöschte Daten in DB- und PDS-Backups? Das gehört in die Datenschutzerklärung.
  7. Bluesky. Crossposts laufen über das Community-Konto und bleiben bestehen. Cross-Likes im Repo der Person verschwinden mit dem Konto. Ist das konsistent mit Art. 16a?