Calendar privacy, management, and troubleshooting
Use this guide when a user asks what Domino can see, whether friends can see their calendar, how often calendar links update, or why a connection is not working.
Privacy by connection type
| Connection | What Domino receives | What Domino retains for ordinary use | What friends can see |
|---|---|---|---|
| Google availability-only | Google's free/busy result | Availability timing and connection state | Availability hints only |
| Google event-aware | Details from calendars the user selects | Private event snapshots and derived availability needed for the user's instructions | Availability hints only |
| Apple, Microsoft, or other ICS feed | The published feed while synchronizing | Derived availability blocks and a non-reversible event-source fingerprint, not raw titles, descriptions, or locations | Availability hints only |
Friends do not receive event titles, locations, notes, guests, provider names, connected-account identities, calendar names, or subscription URLs through ordinary availability features.
Secret calendar-link safety
Apple, Microsoft, and many other providers publish calendar feeds as bearer links. Anyone with the URL may be able to read whatever the provider included in the feed.
- Paste the URL only into Domino's Calendar link field.
- Never paste it into ChatGPT, Claude, an email, a support ticket, or public documentation.
- Select the least detailed publication option the provider offers.
- If a link leaks, revoke or unpublish it at the calendar provider, then replace or remove it in Domino.
- Removing a feed from Domino does not revoke the provider's published URL.
Domino encrypts the normalized feed URL at rest and does not show it back in the management interface.
Sync timing
Direct Google and calendar-link connections refresh periodically. Calendar-link feeds are scheduled about twice daily and may also refresh when availability is needed. They are not instant push connections.
If a newly added or changed event does not affect a suggestion immediately:
- Confirm the connection is active.
- Confirm the event is marked busy rather than free or transparent at the provider.
- Allow time for the next refresh.
- Check Your calendars for Needs attention, Reconnect, or another safe status message.
Do not promise an exact next-sync minute.
Availability depends on the exact dates and hours successfully checked for every participating calendar. A recent connection or token refresh alone does not prove that time is free. Missing, partial, failed or expired evidence stays unknown; a low-confidence busy classification is shown as “May be busy.”
Freshness and retention are separate. Last-seen timing can remain after freshness expires, but it cannot establish current free time. Expired timing becomes eligible for cleanup 14 days after its interval ends; Google event-aware private snapshots keep their existing end-plus-14-day retention. Removing a connection removes its stored evidence. Pausing a connection excludes it from availability checks without deleting it.
Manage connections
In Your calendars:
- use each row’s Use switch to turn display and availability on or off together;
- open the row’s Settings for Google access/calendar choices or a replacement feed link;
- choose Add calendar for another connection;
- Rename or Remove a source from its opened row;
- use each row’s Share busy times with friends switch for sharing.
For Google event-aware mode, the user can also choose Selected calendars and save Availability instructions. Calendar-link feeds can each have their own display name and availability instructions.
Diagnose a calendar-link failure
“Enter a valid webcal:// or https:// calendar feed link”
The user may have copied an HTML sharing page, a login page, an unsupported scheme, or a private-network URL. Ask them to return to the provider and copy the actual ICS/iCal subscription link.
“Calendar link needs attention”
The feed may be unpublished, temporarily unavailable, too large, invalid, or too slow to process. Confirm it still works at the provider. If the provider generated a new link, open that row’s Settings and paste a Replacement calendar link.
Google says “Reconnect needed”
Google access expired or was revoked. Choose Reconnect and authorize the same account. To use a different Google identity, remove the old connection first.
A work calendar has no publish option
The organization may prohibit public calendar feeds. Domino cannot bypass provider or administrator policy. Do not ask for credentials or suggest exposing a private corporate endpoint.
The user connected the wrong calendar
- Google event-aware: adjust Selected calendars.
- Apple, Microsoft, or another feed: remove or replace the incorrect feed and connect the intended calendar's subscription link.
- Calendar app with several accounts: identify the provider that owns the calendar; the app displaying it is not necessarily the provider.
Disconnect and revoke correctly
To stop Domino from using a calendar, remove it in Domino. For a published calendar link, also unpublish or disable public sharing at the original provider when the link should no longer exist.
For Google, removing the connection revokes the stored authorization. For feed connections, Domino deletes the connection's derived availability blocks; the provider remains responsible for revoking the source URL.
Availability versus adding a plan
Connecting a calendar lets Domino consider availability over time. Add to calendar adds one scheduled Domino plan through Google, Microsoft Outlook, or .ics. Adding one plan does not connect ongoing availability, and disconnecting availability does not remove calendar events the user previously added.
LLM answering guidance
- Answer “what can people see?” before giving setup detail.
- Never request a secret calendar URL, provider password, app password, OAuth token, or private event contents.
- Use the current connection status shown by Domino; do not infer that a feed is healthy from its provider name.
- Explain provider revocation separately from removal in Domino.
Private screenshot snapshots
Screenshots are an optional, owner-only intake path under Calendars → Add calendar. Domino sends the bounded image to OpenAI for extraction, with provider response storage disabled. Image text is treated as data; no web research, idea creation, calendar write or automatic model retry runs. Upload up to five screenshots and watch the pending row in Your calendars while they are read and added in the background; editing is optional. Existing previews still save in one action. Screenshot and agent imports keep readable event titles, locations and notes by default. These details are encrypted and remain owner-only, including the event detail panel. Optional busy-only snapshots discard them from the accepted content. Existing busy-only snapshots cannot recover discarded details without a fresh import.
Domino normally deletes its encrypted image copy on background-import finalization or commit/removal, and schedules abandoned uploads for pruning within 24 hours. See the public screenshot policy. Storage outages can delay deletion; failures are retained and retried, and the review reports pending deletion. Draft text expires after seven days; accepted revisions and private snapshots expire through their covered end plus 14 days. If no usable date is available, unplaced details are retained for 14 days from the original upload; a usable future date extends retention through that date plus 14 days. These application retention rules do not override the provider's separate data policies.
A screenshot proves only visible dates and hours. Uncertain details are retained as May be busy, with no claim that their times are confirmed. Missing placement dates and unclear coverage do not block saving. Readable entries without usable times stay encrypted in the owner’s Time unclear list, outside the grid and availability blocks; they can be edited or removed later. Confirmed busy items remain visible even when the source cannot prove free time. Snapshot freshness expires 24 hours after a supplied observation. When capture time is unknown, the original upload time is used for aging only; coverage remains partial and cannot prove free time. Busy-only snapshots also redact free-form uncertainty notes that might contain private names. Update on a screenshot row adds newer evidence. Pausing excludes a source from availability; hiding only removes its visual layer.