tracker: post-Google-sync feature backlog and open sync questions #451

New issue

Open

opened 2026-05-13 18:44:06 +00:00 by barrettruth · 0 comments

barrettruth commented

2026-05-13 18:44:06 +00:00

Owner

Parent: #123
After: #444, #445, #446, #447, #448, #449, #450

Purpose

This is a holding issue for features and design questions intentionally left out of the first Google Tasks/Google Calendar read-only pull stack. These are not accepted implementation requirements yet. They should be split into focused issues after the Google read-only sync stack is working and real usage clarifies the right shape.

Explicitly undecided / unexplored

Merge/conflict policies if Delta ever allows edits to imported provider rows or adds writes back to Google.
Recurring UI sync semantics: how recurrence editing UI should interact with provider-backed recurring masters/exceptions if write sync or richer provider state lands later.
Auto-sync/scheduled sync behavior.
Whether sync timing should be configurable at all, and if so whether it is per provider, per source, global, cron-like, or a small fixed option set.
Whether background sync should be polling-only, push-triggered incremental sync, or both.

Candidate follow-up features

Scheduled/background sync for Google Tasks and Google Calendar.
Native free/busy rendering for transparent/free events and limited-detail private events.
Final source-indicator and icon polish across dense task surfaces; this should be visual/manual iteration, not guessed in advance.
Attachment UI for imported calendar event metadata.
Attendee/organizer/creator UI for imported calendar events.
Reminder UI or a renewed Delta reminder/notification model from preserved Google reminder metadata.
Raw provider metadata/JSON view with safe editing or diagnostic tools.
Link-sharing/event-sharing behavior that integrates provider source links, Delta invite/share links, and external calendar URLs.
Conference/Meet management beyond read-only link mapping, if write sync ever exists.
Richer recurrence/provider-sync UI after the read-only Calendar model proves stable.
CalDAV/Apple-style calendar providers using the same source-state/read-only guard model.

Constraints inherited from the first Google sync stack

Do not compromise the v1 pull-only/read-only guarantee while exploring these.
Do not turn every preserved metadata field into UI by default.
Keep knobs minimal; add configuration only when real usage proves a fixed behavior is wrong.
Keep provider-specific API routes explicit, but preserve modular internal sync primitives.

Next step

After #123's read-only Google sync stack lands, split this issue into focused implementation or research issues. Do not implement all of this as one PR.

Parent: #123 After: #444, #445, #446, #447, #448, #449, #450 ## Purpose This is a holding issue for features and design questions intentionally left out of the first Google Tasks/Google Calendar read-only pull stack. These are not accepted implementation requirements yet. They should be split into focused issues after the Google read-only sync stack is working and real usage clarifies the right shape. ## Explicitly undecided / unexplored - Merge/conflict policies if Delta ever allows edits to imported provider rows or adds writes back to Google. - Recurring UI sync semantics: how recurrence editing UI should interact with provider-backed recurring masters/exceptions if write sync or richer provider state lands later. - Auto-sync/scheduled sync behavior. - Whether sync timing should be configurable at all, and if so whether it is per provider, per source, global, cron-like, or a small fixed option set. - Whether background sync should be polling-only, push-triggered incremental sync, or both. ## Candidate follow-up features - Scheduled/background sync for Google Tasks and Google Calendar. - Native free/busy rendering for transparent/free events and limited-detail private events. - Final source-indicator and icon polish across dense task surfaces; this should be visual/manual iteration, not guessed in advance. - Attachment UI for imported calendar event metadata. - Attendee/organizer/creator UI for imported calendar events. - Reminder UI or a renewed Delta reminder/notification model from preserved Google reminder metadata. - Raw provider metadata/JSON view with safe editing or diagnostic tools. - Link-sharing/event-sharing behavior that integrates provider source links, Delta invite/share links, and external calendar URLs. - Conference/Meet management beyond read-only link mapping, if write sync ever exists. - Richer recurrence/provider-sync UI after the read-only Calendar model proves stable. - CalDAV/Apple-style calendar providers using the same source-state/read-only guard model. ## Constraints inherited from the first Google sync stack - Do not compromise the v1 pull-only/read-only guarantee while exploring these. - Do not turn every preserved metadata field into UI by default. - Keep knobs minimal; add configuration only when real usage proves a fixed behavior is wrong. - Keep provider-specific API routes explicit, but preserve modular internal sync primitives. ## Next step After #123's read-only Google sync stack lands, split this issue into focused implementation or research issues. Do not implement all of this as one PR.

barrettruth added the

labels

2026-05-13 18:44:06 +00:00

barrettruth referenced this issue

2026-05-13 18:44:30 +00:00

feat: Google Calendar sync for single-user self-hosting #123

barrettruth referenced this issue

2026-05-14 04:13:16 +00:00