Settings page: connect Google account(s) and manage shared calendars

[zhiganov]

Context

This is the natural follow-up to #79 (auto-create Google Calendar event on schedule, v1). v1 keeps everything ephemeral and per-browser — the OAuth access token lives in memory, the chosen calendar lives in localStorage. That's fine for "occasional event organizer" usage but breaks down for people who:

• Schedule from multiple devices (phone, laptop, desktop) and don't want to re-OAuth + re-pick each time.
• Organize events for multiple communities, each with its own shared calendar (Sensemaking Scenius, gov/acc, CIBC, etc.) and want to set defaults per-context, not pick from a flat dropdown every time.
• Have multiple Google accounts (personal + work) and want to manage shared calendars across both — today the implicit GIS flow only authenticates one account at a time.

Rough shape (to refine in brainstorming)

A new Settings surface where the creator can:

1. Connect one or more Google accounts (incremental — first account at minimum, multi-account is a stretch goal).
2. See all writable calendars across connected accounts.
3. Pick favorites / set a default for the schedule-time dropdown.
4. Disconnect / revoke an account.
5. (Stretch) Per-community defaults — overlaps with Citizen-Infra/community-admin#12.

Open design questions (for brainstorming)

• OAuth model. v1 uses GIS implicit token client (browser-only, short-lived access tokens). For settings-managed connections we likely need server-side OAuth with refresh tokens to survive across sessions and devices. That's a Google Cloud project change (web-app credentials with client_secret), a server callback route, and encrypted refresh-token storage somewhere. Where? Options:
  • On the user's PDS via a new lexicon record (token sealed to the user's account; cross-device by definition; ATProto-native).
  • On the Avails server volume (existing pattern for sessions; less ATProto-pure).
  • Hybrid: PDS as source of truth, server volume for cache.
• Settings page scaffolding. Avails has no settings page today (client/src/pages/ = Landing, PollView, About, Privacy, Terms). First slice of this work is scaffolding /settings and a route guard.
• Multi-account scope. Big stretch. v1.5 of this issue could just be "one connected Google account, persisted across devices"; multi-account is a separate slice.
• Permission boundary. When the user disconnects an account from Settings, do already-scheduled polls keep their existing Google events? (Yes — events live on Google's side, we never own them.) Does the disconnect revoke the refresh token? (Yes — call Google's revoke endpoint.)
• Migration from v1. When a user who's been using v1 (localStorage default) opens Settings for the first time, surface their existing localStorage choice as a one-click "make this my default" prompt.

Scope discipline

Keep an eye on Avails' charter: "time-finding, not event management" (CLAUDE.md). A Settings page focused on calendar connection management still falls inside that — it's about which calendar gets the event, not about managing the events themselves. Rule out: event listing, event editing, event search.

Dependencies / related

• Depends on / extends: Auto-create Google Calendar event after scheduling a poll #79 (v1 schedule-time picker)
• Cross-reference: Citizen-Infra/community-admin#12 (per-community calendar defaults — different surface, similar intent)

Definition of done (high level — refine in brainstorming)

• Logged-in creator can connect a Google account from Settings with one click.
• Connection survives logout/re-login and works across devices (refresh token).
• Writable-calendar list visible in Settings; user picks default.
• Schedule-time dropdown respects the Settings default.
• Disconnect works and revokes upstream.