Practice
Contact sync
Contact sync keeps one address book consistent across devices and services — detecting changes, resolving edit conflicts, and propagating deletions.
Contact sync sounds like copying and is actually distributed-systems engineering in miniature. Each device holds a replica of the address book; sync must detect what changed on each replica since they last spoke, decide what to do when both changed the same record, and make deletions stick. Get any of the three wrong and users see the classic symptoms — duplicated contacts, lost edits, or deleted people who rise from the dead.
Change detection typically uses version markers: ETags per record and a sync token per collection in CardDAV, change feeds in proprietary APIs. Conflict resolution is where designs diverge. Last-write-wins is simplest — the most recent edit clobbers the other — but it loses data whenever two devices edit different fields of the same person offline. Field-level merging keeps both edits and only conflicts when the same field changed on both sides; CRDT-based designs make even that case deterministic.
Deletions are the subtle part: if a device simply removes a record, the next sync can't distinguish "deleted here" from "never received," so well-built systems keep tombstones — markers saying this UID was deleted at time T — for long enough that every replica hears the news.
Last-write-wins vs. field-level merge
Picture editing Maria's record on your phone (new mobile number) while your laptop, offline on a flight, fixes her misspelled street. Under record-level last-write-wins, whichever device syncs second wins entirely — one of the two corrections silently vanishes, and you won't notice until you need it. Field-level merge compares per attribute: the phone's number edit and the laptop's address edit both survive, and only a same-field collision needs a tiebreak. The trade-off is engineering cost — field merging needs per-field timestamps or version vectors, which is why cheap sync implementations and naive CSV-roundtrip integrations still ship LWW and quietly eat data at the edges.
Resurrected contacts and other sync pathologies
Three pathologies account for most sync grief. Resurrection: you delete a contact, but a replica that never received the tombstone (an old tablet, a stale account) re-uploads it as "new" — the fix is durable tombstones and removing dead replicas from the account. Duplicate storms: two services are bridged twice (say, a phone syncing a provider both natively and through an integration), each path imports the other's records, and the address book doubles; always ensure exactly one sync path per source. And field mangling: round-trips through systems with smaller schemas — CSV exports, limited APIs — drop labels, custom fields, or second phone numbers, so the data degrades a little with every loop even though nothing "failed."
Syncing without a server that reads your data
Mainstream contact sync has a structural property worth naming: the provider's server stores your address book in a form it can read, because the server performs the merging. The local-first movement argues for inverting this — devices hold the primary copies, and the network is just transport. Endearist follows that architecture: your relationship data lives on your device and works fully offline, and the optional multi-device sync is end-to-end encrypted, so the sync infrastructure shuttles ciphertext it cannot inspect, with an EU-hosted cloud option for those who want a hosted relay. The conflict-resolution burden moves to the clients, which is precisely the engineering price of a system where notes about your closest people are readable by exactly one party: you.
Frequently asked questions
- Why do deleted contacts keep coming back?
- Some replica never learned about the deletion. A forgotten device, a disabled-then-re-enabled account, or an integration holding an old snapshot re-uploads the contact, and the server treats it as new. Hunt down every place the address book syncs — old phones, tablets, backup tools, third-party apps with contacts access — delete the record everywhere or disconnect stale replicas, and the resurrection stops.
- What causes duplicates to appear after enabling sync?
- Usually two sync paths covering the same source, or an import that ran where a link was expected. If your phone already had local copies of contacts that also exist in the newly connected account, and the records share no common identifier, the system can't prove they're the same person and keeps both. Prevent it by syncing each source exactly once and running a deduplication pass right after connecting anything new.
- Is end-to-end encrypted sync slower or worse than normal sync?
- Not noticeably for address-book-sized data — encrypting a few thousand small records is computationally trivial on modern hardware. The real differences are architectural: the server can't deduplicate or merge for you (clients must do it), server-side search of your data is impossible, and losing your keys means losing access. In exchange, a breach or subpoena at the provider exposes only ciphertext. For intimate relationship notes, that trade usually favors E2E.
Last updated: 2026-06-10
Tend relationships, not records.
Endearist is a local-first personal CRM. Free up to 25 contacts.
Start free