Contacts backend

backend-contacts-http is a multi-instance CardDAV backend for Everlock.

Current state

• multi-instance and multi-vhost
• per-instance versioned-storage
• Everlock-user HTTP authentication and http/contacts/<instance> access control
• multiple address books per instance
• plain persisted .vcf contacts with server-side create, update, and delete
• CardDAV discovery, PROPFIND, GET, PUT, DELETE, MKCOL
• conditional requests with ETags
• initial REPORT sync-collection support using real store commit ids as sync tokens

Shape

Each contacts instance has:

• one instance name
• one dedicated store
• one or more vhosts
• one CardDAV namespace served through frontend-http

Example config:

enabled = true

[instances.default]
store = "everlock-contacts"
vhosts = ["contacts.example.com"]

Storage

Contacts are stored as plain .vcf files in versioned-storage.

The current store layout is:

default/
  config.toml
  alice-smith.vcf
  alice-smith-2.vcf
work/
  config.toml
  vendor-x.vcf

Create-time hrefs are human-readable and slug-based. Duplicate names get numeric suffixes. Existing hrefs stay stable on update.

If a client omits UID, Everlock injects one on write.

Access model

The access path is:

• http/contacts/<instance>

Role mapping:

• Reader for discovery, listing, fetch, PROPFIND, and REPORT
• Writer for PUT, DELETE, and MKCOL

The current model is instance-wide. There are no per-address-book ACLs yet.

CardDAV surface

Current URL shape:

/.well-known/carddav
/dav/
/dav/principals/me/
/dav/addressbooks/
/dav/addressbooks/<book>/
/dav/addressbooks/<book>/<contact>.vcf

Supported today:

• discovery and PROPFIND
• contact GET / HEAD
• REPORT addressbook-multiget
• REPORT addressbook-query
• REPORT sync-collection
• writable PUT, DELETE, and MKCOL

Sync

Address-book sync tokens use the real versioned-storage commit id.

That means incremental sync is derived directly from store history instead of a second sync database.

Intended role

• provide address-book style behavior over HTTP-facing protocols such as CardDAV
• remain a backend concern rather than a transport concern