Connecting to Omnical

Every connection to this server is one of four shapes, and picking the wrong one is the usual confusion — "subscribe" and "CalDAV account" look the same in a calendar app and behave completely differently.

The server: https://0115d8cf.duckdns.org:8443 — everything lives on it, in one database. The password is always an app token (minted on your profile page), never an email password.

Which one do you need?

You want…UseDirectionWho can do it
your calendar in your phone/desktop app, edits both waysCalDAV clienttwo-wayHawkBook/DAVx5, Thunderbird, Apple, khal, vdirsyncer
your calendar visible in Google/Outlook web, no edits backICS subscribeone-way (in)Google Calendar web, Outlook web, Apple
your calendar pushed into an account on another server (aphy, Google)push mirrorone-way (out)the server itself (operator configures)
two servers reconciled, edits on either side winsync hubtwo-waya machine running vdirsyncer

Read-only beats read-write: if read-only is enough (someone who only needs to see your schedule), subscribe — a leaked subscription link cannot change anything.

The whole picture

Diagram: devices talk both ways to Omnical over CalDAV; Google and Outlook web only pull the read-only export file; Omnical pushes mirrors out to the aphy and Google servers; the phone consumes aphy's feed calendar.

The arrows' directions are the contract: clients talk both ways, subscribers only pull, mirrors only push. Nobody can write into this server except CalDAV clients (and guests — below).

1. Connect a CalDAV client — full, two-way

The everyday path: your calendar lives in the app, edits travel back.

Sequence diagram: you mint an app token on the profile page, add the account in the app, the app discovers your calendars, then PUT and DELETE carry your edits; WebDAV Push pings waiting clients.
FieldValue
Server / base URLhttps://0115d8cf.duckdns.org:8443/caldav
Usernameyour principal id (the email-shaped one you log in with)
Passwordan app token from the profile page — not your login or email password
  • HawkBook/DAVx5 can use the Nextcloud login flow and generates its own token — no copy-paste.
  • Apple skips typing entirely with the profile page's generated configuration profile.
  • Sync is near-instant for apps that speak WebDAV Push; everything else polls on its own schedule.

1.1 A guest, on someone else's calendar

Sharing to a person uses the same client path with different credentials: the owner mints a guest share (or per-calendar credentials) on the share page, and hands over exactly one pair:

Diagram: the owner mints a guest username plus one app token; the guest types it into their app like any CalDAV account; the server enforces exactly the privilege that was minted.

The privilege minted is the whole permission: view, edit, or admin. Revoke on the owner's share page and the pair stops working at the next request — nothing to recall from the guest.

2. Subscribe — read-only, one-way

For apps that cannot add a CalDAV account at all (Google Calendar web/app, Outlook web) or where read-only is the point. The profile page mints a subscription link; anyone holding it can see, never change:

Sequence diagram: the app is given the export link; the provider's own servers fetch the file about once a day, no credentials are sent, and the whole calendar comes back as one file. Edits never travel back.
  • URL shape: the token is the credential — no username, no password.
  • Direction: in, only. Edits made in the app never travel back.
  • Fetch: the provider's own servers fetch it — your device never sends anything.
  • Refresh: roughly once a day — "it hasn't updated yet" is usually just patience.
  • Revocation: revoke on the profile page and the link stops working.

3. Push a calendar out — mirrors

The reverse direction: the server itself copies a local calendar into a collection on someone else's server (aphy, Google). Nothing is installed on the target; the server authenticates like a client would.

Diagram: the source calendar on Omnical is read by the sync job on a schedule, which PROPFINDs each target and PUTs new or changed events and DELETEs vanished ones; the aphy target logs in with username and password, the Google target with OAuth2.

One run of the engine, step by step:

Flowchart: the run reads the source, authenticates (HTTP Basic or a refreshed OAuth2 bearer token), lists the target collection, diffs against the last run, PUTs changed events, DELETEs vanished ones, and records the run.

The rules that matter:

  • One-way. The source calendar is the truth. An edit made on the remote side (in the aphy web, in Google) is silently overwritten by the next push — the mirror is a copy, not a negotiation.
  • Ownership. The mirror only ever touches objects it wrote itself. The remote account's native events — invitations it accepted, events its owner made — are never read, changed, or deleted by a sync.
  • The target calendar must already exist (Google has no calendar creation over CalDAV — create it in the web UI; a 404 from the target means exactly this).
  • Google is OAuth2, not a password: the target carries a client id, client secret and refresh token, exchanged for a bearer token once per run. Both spellings live only in the server's config file.

3.1 The aphy two-calendar layout (why the phone gets its own)

Diagram: the Omnical calendar is mirrored twice into one aphy account — canonical masters with organizer stamps for the web calendar, and a flattened phone feed with suffixed UIDs for the phone, which never expands recurrence.

The two calendars answer two clients that cannot share one: the web needs the real masters (or series operations break), the phone needs flat one-shots (or the master lands on the wrong day).

4. Server-to-server, two-way — the sync hub

When both sides must accept edits, a push mirror is the wrong tool. The pattern that reconciles is a sync client both servers talk to — vdirsyncer on a desktop, pairing Google and Omnical through a local folder of .ics files:

Diagram: Google Calendar and Omnical each pair with the same local folder of ics files through vdirsyncer; khal reads the same files offline.
  • Each pair is independent; the shared folder is the meeting point.
  • Conflicts are resolved by the config's rule (the router wins), so an edit on either side converges instead of duplicating.
  • This is also the migration tool: it is how Google calendars were originally imported into Omnical.

Mirror vs hub, in one line: a mirror is configured where the truth lives (the server) and copies out; a hub is configured on a third machine and reconciles two truths.

5. What each app can actually do

AppCalDAV account (full)Subscribe (read-only)Notes
HawkBook / DAVx5 (Android)yes—the Android path; Nextcloud login flow
Thunderbirdyesyeseither works
Apple Calendar (iOS/macOS)yesyesprofile page generates a config profile
khal / vdirsynceryes—CLI; vdirsyncer is the hub engine (§4)
Google Calendar (web/app)no — cannot add an external CalDAV serveryes ("From URL", ~daily)the reason mirrors exist (§3)
Outlook (web/new)noyes ("Subscribe from web")classic Windows Outlook: subscribe only

Anything in the "CalDAV" column connects via §1; anything not, and you wanted it inside a Google/Outlook account anyway, is §3's reason to exist — push the calendar to them, then their app is just reading its own account.