Praxis
Kontakt-Synchronisation
Kontakt-Synchronisation hält ein Adressbuch über Geräte und Dienste hinweg konsistent – sie erkennt Änderungen, löst Konflikte und überträgt Löschungen.
Kontakt-Synchronisation klingt nach Kopieren und ist in Wahrheit verteilte Systeme im Miniaturformat. Jedes Gerät hält eine Replik des Adressbuchs; der Sync muss erkennen, was sich auf jeder Replik seit dem letzten Abgleich geändert hat, entscheiden, was bei gleichzeitigen Änderungen am selben Datensatz passiert, und Löschungen dauerhaft machen. Geht eines der drei schief, sehen Nutzer die klassischen Symptome: doppelte Kontakte, verlorene Bearbeitungen oder Gelöschte, die von den Toten auferstehen.
Die Änderungserkennung nutzt meist Versionsmarker: ETags pro Datensatz und ein Sync-Token pro Sammlung bei CardDAV, Change-Feeds bei proprietären APIs. Bei der Konfliktauflösung trennen sich die Designs. Last-Write-Wins ist am einfachsten – die jüngste Bearbeitung überschreibt die andere –, verliert aber Daten, sobald zwei Geräte offline verschiedene Felder derselben Person bearbeiten. Feldweises Merging behält beide Änderungen und konfligiert nur, wenn dasselbe Feld beidseitig geändert wurde; CRDT-basierte Designs machen selbst diesen Fall deterministisch.
Löschungen sind der subtile Teil: Entfernt ein Gerät einen Datensatz einfach, kann der nächste Sync "hier gelöscht" nicht von "nie erhalten" unterscheiden. Gut gebaute Systeme führen deshalb Tombstones – Marker, dass diese UID zum Zeitpunkt T gelöscht wurde – so lange, bis jede Replik die Nachricht gehört hat.
Last-Write-Wins vs. feldweises Merging
Stell dir vor: Du änderst Marias Datensatz am Handy (neue Mobilnummer), während dein Laptop – offline im Flugzeug – ihren falsch geschriebenen Straßennamen korrigiert. Bei Last-Write-Wins auf Datensatzebene gewinnt das Gerät, das als zweites synchronisiert, komplett: Eine der beiden Korrekturen verschwindet lautlos, und du merkst es erst, wenn du sie brauchst. Feldweises Merging vergleicht pro Attribut – die Nummernänderung des Handys und die Adresskorrektur des Laptops überleben beide, nur eine Kollision im selben Feld braucht einen Tiebreak. Der Preis ist Engineering-Aufwand: Feld-Merging braucht Zeitstempel oder Versionsvektoren pro Feld. Genau deshalb liefern billige Sync-Implementierungen und naive CSV-Roundtrips weiterhin LWW aus – und fressen an den Rändern leise Daten.
Auferstandene Kontakte und andere Sync-Pathologien
Drei Pathologien verursachen den Großteil des Sync-Kummers. Auferstehung: Du löschst einen Kontakt, aber eine Replik, die den Tombstone nie erhielt (ein altes Tablet, ein vergessenes Konto), lädt ihn als "neu" wieder hoch – die Abhilfe sind langlebige Tombstones und das Entfernen toter Repliken aus dem Konto. Dubletten-Stürme: Zwei Dienste sind doppelt verbrückt (etwa ein Handy, das einen Anbieter nativ und zusätzlich über eine Integration synchronisiert), jeder Pfad importiert die Datensätze des anderen, und das Adressbuch verdoppelt sich; stelle sicher, dass es pro Quelle genau einen Sync-Pfad gibt. Und Feld-Verstümmelung: Roundtrips durch Systeme mit kleinerem Schema – CSV-Exporte, eingeschränkte APIs – verlieren Labels, eigene Felder oder die zweite Telefonnummer. Die Daten verschleißen mit jeder Runde ein wenig, obwohl nichts "fehlgeschlagen" ist.
Synchronisieren, ohne dass ein Server mitliest
Gewöhnliche Kontakt-Synchronisation hat eine strukturelle Eigenschaft, die man benennen sollte: Der Server des Anbieters speichert dein Adressbuch in lesbarer Form, weil der Server das Merging übernimmt. Die Local-First-Bewegung plädiert für die Umkehrung – die Geräte halten die Primärkopien, das Netz ist nur Transport. Endearist folgt dieser Architektur: Deine Beziehungsdaten liegen auf deinem Gerät und funktionieren komplett offline, und der optionale Multi-Device-Sync ist Ende-zu-Ende-verschlüsselt – die Sync-Infrastruktur transportiert Chiffretext, den sie nicht einsehen kann, mit einer EU-gehosteten Cloud-Option für alle, die ein gehostetes Relay wollen. Die Last der Konfliktauflösung wandert dabei zu den Clients. Genau das ist der Engineering-Preis eines Systems, in dem Notizen über deine engsten Menschen für exakt eine Partei lesbar sind: dich.
Häufige Fragen
- Warum kommen gelöschte Kontakte immer wieder zurück?
- Irgendeine Replik hat von der Löschung nie erfahren. Ein vergessenes Gerät, ein deaktiviertes und wieder aktiviertes Konto oder eine Integration mit altem Snapshot lädt den Kontakt erneut hoch, und der Server hält ihn für neu. Spüre jeden Ort auf, an dem das Adressbuch synchronisiert – alte Handys, Tablets, Backup-Tools, Dritt-Apps mit Kontaktzugriff –, lösche den Datensatz überall oder trenne verwaiste Repliken, und die Auferstehung hört auf.
- Warum entstehen nach dem Aktivieren von Sync plötzlich Dubletten?
- Meist zwei Sync-Pfade über dieselbe Quelle – oder ein Import, wo eine Verknüpfung erwartet wurde. Hatte dein Handy bereits lokale Kopien von Kontakten, die auch im neu verbundenen Konto existieren, und teilen die Datensätze keine gemeinsame Kennung, kann das System nicht beweisen, dass es dieselbe Person ist, und behält beide. Vorbeugen: jede Quelle genau einmal synchronisieren und nach jeder neuen Verbindung einen Dedup-Lauf starten.
- Ist Ende-zu-Ende-verschlüsselter Sync langsamer oder schlechter?
- Bei Datenmengen eines Adressbuchs nicht spürbar – ein paar tausend kleine Datensätze zu verschlüsseln ist für moderne Hardware trivial. Die echten Unterschiede sind architektonisch: Der Server kann nicht für dich deduplizieren oder mergen (das müssen die Clients tun), serverseitige Suche in deinen Daten ist unmöglich, und wer seine Schlüssel verliert, verliert den Zugriff. Dafür legt ein Einbruch oder eine Anordnung beim Anbieter nur Chiffretext offen. Für intime Beziehungsnotizen spricht dieser Tausch meist für E2E.
Zuletzt aktualisiert: 2026-06-10
Beziehungen pflegen, nicht verwalten.
Endearist ist ein local-first Personal CRM. Kostenlos bis 25 Kontakte.
Kostenlos starten