# 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:

1. Confirm the connection is active.
2. Confirm the event is marked busy rather than free or transparent at the provider.
3. Allow time for the next refresh.
4. Check **Profile → Availability** 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 **Profile → Availability**:

- expand **Google Calendar** or **Calendar link** with **Manage**;
- **Pause** a connection without deleting it;
- **Resume** a paused connection;
- **Replace** a feed URL after the provider issues a new one;
- **Add another calendar** for another feed;
- **Remove** a connection and its stored availability data;
- use **Group suggestions** to control whether Domino considers the user's calendar in group timing suggestions.

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, use **Replace** in Domino.

### 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 return to Calendar 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's encrypted image copy is deleted after commit/removal or by scheduled pruning within 24 hours of upload. 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 screenshot** adds newer evidence. Pausing excludes a source from availability; hiding only removes its visual layer.