Feature request - Add Suport for Contacts (CardDAV)

[r3df0chs]

This is a wide stretch but i would like to see a tool which can sync contacts between 2 different CardDav Servers.

For example i want to sync my contacts between my Gmail Account and an Nextcloud CardDAV Server.

Would be really neat, this way we could use both services with all our contacts.

If a active:active synchronization would be hard to achieve or risky about duplicates, an Active:Passive sync would be already great, so you have one Source of Truth and can sync it to other places.

[abhinav-bhateja]

Analysis: CardDAV Contact Sync Support

Thanks for the suggestion! I took a deep look at the current architecture to assess what it would take to add
contact (CardDAV) sync support. Here's a summary of the findings.

Current architecture is calendar-specific

The codebase is purpose-built for calendar event synchronization. While it's modular and extensible for adding
new calendar providers, it isn't currently extensible for adding a new domain (contacts) without
substantial changes:

• Domain model — Core abstractions (CalendarProvider, SyncableEvent) are tied to calendar events with
  fields like startTime, endTime, summary. Contacts have entirely different fields (name, phone, email,
  address, photo, etc.) and no time dimension.
• Database schema — Tables like event_states, event_mappings, calendar_sources, and
  calendar_destinations are all calendar-specific. Contacts would need parallel tables.
• Sync engine — The sync logic filters by time windows, uses chronological ordering, and deduplicates by
  time slot overlap. Contact sync requires different logic: matching by name/email, merging fields, and handling
  vCard format instead of iCal.
• UI — The web app presents calendars, sources, and destinations — all calendar concepts.
• Provider registry — ProviderDefinition is calendar-specific; contacts would need a parallel registry or
  a significant refactor.

What would be required

Area	Changes needed
New domain abstractions	ContactProvider base class, SyncableContact type, contact-specific sync
logic
New database tables	Contact states, contact mappings, contact sources/destinations
New sync engine	vCard parsing, contact matching/merging (by name, email, etc.), conflict resolution
CardDAV client	vCard fetch/push over CardDAV (different protocol from CalDAV)
Google Contacts	Google People API integration (separate from Calendar API)
UI	New pages/flows for contact sources and destinations
Cron jobs	Separate contact sync scheduling

Summary

The architecture is well-designed and modular — but modular for calendar providers, not for arbitrary data
types. Adding contacts would essentially be a parallel feature track that shares infrastructure (auth,
encryption, Redis, PostgreSQL) but requires new domain logic at every layer.

This is a significant undertaking — effectively building a second product alongside the calendar sync. It's not
off the table, but it's important to set expectations that this wouldn't be a small addition.

[ridafkih]

@abhinav-bhateja is not affiliated with Keeper. Looks like their comment is low-quality, low-effort and unwelcome AI slop. Unsure if it is meant to confuse people who have created issues, but @abhinav-bhateja I highly suggest you change your approach on how you leverage AI.

This feature is still something I'll be looking into and this issue will be the source of truth.