backlog/tasks/task-001 - offline-local-storage.md

@@ -1,52 +1,12 @@
 ---
 id: task-001
 title: offline local storage
-status: Done
+status: To Do
 assignee: []
 created_date: '2025-12-03 23:42'
-updated_date: '2025-12-04 20:35'
+updated_date: '2025-12-04 12:13'
-labels:
+labels: []
-  - feature
-  - offline
-  - persistence
-  - indexeddb
 dependencies: []
-priority: high
 ---
 
-## Description
 
-<!-- SECTION:DESCRIPTION:BEGIN -->
-IndexedDB persistence is already implemented via @automerge/automerge-repo-storage-indexeddb. The remaining work is:
-
-1. Add real online/offline detection (currently always returns "online")
-2. Create UI indicator showing connection status
-3. Handle Safari's 7-day IndexedDB eviction
-
-Existing code locations:
-- src/automerge/useAutomergeSyncRepo.ts (lines 346, 380-432)
-- src/automerge/useAutomergeStoreV2.ts (connectionStatus property)
-- src/automerge/documentIdMapping.ts (room→document mapping)
-<!-- SECTION:DESCRIPTION:END -->
-
-## Acceptance Criteria
-<!-- AC:BEGIN -->
-- [x] #1 Real WebSocket connection state tracking (not hardcoded 'online')
-- [x] #2 navigator.onLine integration for network detection
-- [x] #3 UI indicator component showing connection status
-- [x] #4 Visual feedback when working offline
-- [x] #5 Auto-reconnect with status updates
-- [ ] #6 Safari 7-day eviction mitigation (service worker or periodic touch)
-<!-- AC:END -->
-
-## Implementation Notes
-
-<!-- SECTION:NOTES:BEGIN -->
-Implemented connection status tracking:
-- Added ConnectionState type and tracking in CloudflareAdapter
-- Added navigator.onLine integration for network detection
-- Exposed connectionState and isNetworkOnline from useAutomergeSync hook
-- Created ConnectionStatusIndicator component with visual feedback
-- Shows status only when not connected (connecting/reconnecting/disconnected/offline)
-- Auto-hides when connected and online
-<!-- SECTION:NOTES:END -->

backlog/tasks/task-025 - Google-Export-Local-First-Data-Sovereignty.md

@@ -1,85 +0,0 @@
----
-id: task-025
-title: 'Google Export: Local-First Data Sovereignty'
-status: Done
-assignee: []
-created_date: '2025-12-04 20:25'
-updated_date: '2025-12-04 23:24'
-labels:
-  - feature
-  - google
-  - encryption
-  - privacy
-dependencies: []
-priority: medium
----
-
-## Description
-
-<!-- SECTION:DESCRIPTION:BEGIN -->
-Import Google Workspace data (Gmail, Drive, Photos, Calendar) locally, encrypt with WebCrypto, store in IndexedDB. User controls what gets shared to board or backed up to R2.
-
-Worktree: /home/jeffe/Github/canvas-website-branch-worktrees/google-export
-Branch: feature/google-export
-
-Architecture docs in: docs/GOOGLE_DATA_SOVEREIGNTY.md
-<!-- SECTION:DESCRIPTION:END -->
-
-## Acceptance Criteria
-<!-- AC:BEGIN -->
-- [x] #1 OAuth 2.0 with PKCE flow for Google APIs
-- [x] #2 IndexedDB schema for encrypted data storage
-- [x] #3 WebCrypto key derivation from master key
-- [x] #4 Gmail import with pagination and progress
-- [x] #5 Drive document import
-- [x] #6 Photos thumbnail import
-- [x] #7 Calendar event import
-- [x] #8 Share to board functionality
-- [x] #9 R2 encrypted backup/restore
-<!-- AC:END -->
-
-## Implementation Notes
-
-<!-- SECTION:NOTES:BEGIN -->
-Starting implementation - reviewed architecture doc GOOGLE_DATA_SOVEREIGNTY.md
-
-Implemented core Google Data Sovereignty module:
-
-- types.ts: Type definitions for all encrypted data structures
-
-- encryption.ts: WebCrypto AES-256-GCM encryption, HKDF key derivation, PKCE utilities
-
-- database.ts: IndexedDB schema with stores for gmail, drive, photos, calendar, sync metadata, encryption metadata, tokens
-
-- oauth.ts: OAuth 2.0 PKCE flow for Google APIs with encrypted token storage
-
-- importers/gmail.ts: Gmail import with pagination, progress tracking, batch storage
-
-- importers/drive.ts: Drive import with folder navigation, Google Docs export
-
-- importers/photos.ts: Photos import with thumbnail caching, album support
-
-- importers/calendar.ts: Calendar import with date range filtering, recurring events
-
-- share.ts: Share service for creating tldraw shapes from encrypted data
-
-- backup.ts: R2 backup service with encrypted manifest, checksum verification
-
-- index.ts: Main module with GoogleDataService class and singleton pattern
-
-TypeScript compilation passes - all core modules implemented
-
-Committed and pushed to feature/google-export branch (e69ed0e)
-
-All core modules implemented and working: OAuth, encryption, database, share, backup
-
-Gmail, Drive, and Calendar importers working correctly
-
-Photos importer has 403 error on some thumbnail URLs - needs investigation:
-
-- May require proper OAuth consent screen verification
-
-- baseUrl might need different approach for non-public photos
-
-- Consider using Photos API mediaItems.get for base URLs instead of direct thumbnail access
-<!-- SECTION:NOTES:END -->

backlog/tasks/task-026 - Fix-text-shape-sync-between-clients.md

@@ -1,37 +0,0 @@
----
-id: task-026
-title: Fix text shape sync between clients
-status: To Do
-assignee: []
-created_date: '2025-12-04 20:48'
-labels:
-  - bug
-  - sync
-  - automerge
-dependencies: []
-priority: high
----
-
-## Description
-
-<!-- SECTION:DESCRIPTION:BEGIN -->
-Text shapes created with the "T" text tool show up on the creating client but not on other clients viewing the same board.
-
-Root cause investigation:
-- Text shapes ARE being persisted to R2 (confirmed in server logs)
-- Issue is on receiving client side in AutomergeToTLStore.ts
-- Line 1142: 'text' is in invalidTextProps list and gets deleted
-- If richText isn't properly populated before text is deleted, content is lost
-
-Files to investigate:
-- src/automerge/AutomergeToTLStore.ts (sanitization logic)
-- src/automerge/TLStoreToAutomerge.ts (serialization logic)
-- src/automerge/useAutomergeStoreV2.ts (store updates)
-<!-- SECTION:DESCRIPTION:END -->
-
-## Acceptance Criteria
-<!-- AC:BEGIN -->
-- [ ] #1 Text shapes sync correctly between multiple clients
-- [ ] #2 Text content preserved during automerge serialization/deserialization
-- [ ] #3 Both new and existing text shapes display correctly on all clients
-<!-- AC:END -->

backlog/tasks/task-027 - Implement-proper-Automerge-CRDT-sync-for-offline-first-support.md

@@ -1,34 +0,0 @@
----
-id: task-027
-title: Implement proper Automerge CRDT sync for offline-first support
-status: In Progress
-assignee: []
-created_date: '2025-12-04 21:06'
-labels:
-  - offline-sync
-  - crdt
-  - automerge
-  - architecture
-dependencies: []
-priority: high
----
-
-## Description
-
-<!-- SECTION:DESCRIPTION:BEGIN -->
-Replace the current "last-write-wins" full document replacement with proper Automerge CRDT sync protocol. This ensures deletions are preserved across offline/reconnect scenarios and concurrent edits merge correctly.
-
-Current problem: Server does `currentDoc.store = { ...newDoc.store }` which is full replacement, not merge. This causes "ghost resurrection" of deleted shapes when offline clients reconnect.
-
-Solution: Use Automerge's native binary sync protocol with proper CRDT merge semantics.
-<!-- SECTION:DESCRIPTION:END -->
-
-## Acceptance Criteria
-<!-- AC:BEGIN -->
-- [ ] #1 Server stores Automerge binary documents in R2 (not JSON)
-- [ ] #2 Client-server communication uses Automerge sync protocol (binary messages)
-- [ ] #3 Deletions persist correctly when offline client reconnects
-- [ ] #4 Concurrent edits merge deterministically without data loss
-- [ ] #5 Existing JSON rooms are migrated to Automerge format
-- [ ] #6 All existing functionality continues to work
-<!-- AC:END -->

backlog/tasks/task-028 - OSM-Canvas-Integration-Foundation.md

@@ -1,93 +0,0 @@
----
-id: task-028
-title: OSM Canvas Integration Foundation
-status: Done
-assignee:
-  - '@claude'
-created_date: '2025-12-04 21:12'
-updated_date: '2025-12-04 21:44'
-labels:
-  - feature
-  - mapping
-  - foundation
-dependencies: []
-priority: high
----
-
-## Description
-
-<!-- SECTION:DESCRIPTION:BEGIN -->
-Implement the foundational layer for rendering OpenStreetMap data on the tldraw canvas. This includes coordinate transformation (geographic ↔ canvas), tile rendering as canvas background, and basic interaction patterns.
-
-Core components:
-- Geographic coordinate system (lat/lng to canvas x/y transforms)
-- OSM tile layer rendering (raster tiles as background)
-- Zoom level handling that respects geographic scale
-- Pan/zoom gestures that work with map context
-- Basic marker/shape placement with geographic coordinates
-- Vector tile support for interactive OSM elements
-
-This is the foundation that task-024 (Route Planning) and other spatial features build upon.
-<!-- SECTION:DESCRIPTION:END -->
-
-## Acceptance Criteria
-<!-- AC:BEGIN -->
-- [x] #1 OSM raster tiles render as canvas background layer
-- [x] #2 Coordinate transformation functions (geo ↔ canvas) working accurately
-- [x] #3 Zoom levels map to appropriate tile zoom levels
-- [x] #4 Pan/zoom gestures work smoothly with tile loading
-- [x] #5 Shapes can be placed with lat/lng coordinates
-- [x] #6 Basic MapLibre GL or Leaflet integration pattern established
-<!-- AC:END -->
-
-## Implementation Notes
-
-<!-- SECTION:NOTES:BEGIN -->
-## Progress (2025-12-04)
-
-### Completed:
-- Reviewed existing open-mapping module scaffolding
-- Installed maplibre-gl npm package
-- Created comprehensive geo-canvas coordinate transformation utilities (geoTransform.ts)
-  - GeoCanvasTransform class for bidirectional geo ↔ canvas transforms
-  - Web Mercator projection support
-  - Tile coordinate utilities
-  - Haversine distance calculations
-
-### In Progress:
-- Wiring up MapLibre GL JS in useMapInstance hook
-- Creating MapShapeUtil for tldraw canvas integration
-
-### Additional Progress:
-- Fixed MapLibre attributionControl type issue
-- Created MapShapeUtil.tsx with full tldraw integration
-- Created MapTool.ts for placing map shapes
-- Registered MapShape and MapTool in Board.tsx
-- Map shape features:
-  - Resizable map window
-  - Interactive pan/zoom toggle
-  - Location presets (NYC, London, Tokyo, SF, Paris)
-  - Live coordinate display
-  - Pin to view support
-  - Tag system integration
-
-### Completion Summary:
-- All core OSM canvas integration foundation is complete
-- MapShape can be placed on canvas via MapTool
-- MapLibre GL JS renders OpenStreetMap tiles
-- Coordinate transforms enable geo ↔ canvas mapping
-- Ready for testing on dev server at localhost:5173
-
-### Files Created/Modified:
-- src/open-mapping/utils/geoTransform.ts (NEW)
-- src/open-mapping/hooks/useMapInstance.ts (UPDATED with MapLibre)
-- src/shapes/MapShapeUtil.tsx (NEW)
-- src/tools/MapTool.ts (NEW)
-- src/routes/Board.tsx (UPDATED with MapShape/MapTool)
-- package.json (added maplibre-gl)
-
-### Next Steps (task-024):
-- Add OSRM routing backend
-- Implement waypoint placement
-- Route calculation and display
-<!-- SECTION:NOTES:END -->

backlog/tasks/task-029 - zkGPS-Protocol-Design.md

@@ -1,70 +0,0 @@
----
-id: task-029
-title: zkGPS Protocol Design
-status: Done
-assignee:
-  - '@claude'
-created_date: '2025-12-04 21:12'
-updated_date: '2025-12-04 23:29'
-labels:
-  - feature
-  - privacy
-  - cryptography
-  - research
-dependencies: []
-priority: medium
----
-
-## Description
-
-<!-- SECTION:DESCRIPTION:BEGIN -->
-Design and implement a zero-knowledge proof system for privacy-preserving location sharing. Enables users to prove location claims without revealing exact coordinates.
-
-Key capabilities:
-- Proximity proofs: Prove "I am within X distance of Y" without revealing exact location
-- Region membership: Prove "I am in Central Park" without revealing which part
-- Temporal proofs: Prove "I was in region R between T1 and T2"
-- Group rendezvous: N people prove they are all nearby without revealing locations to each other
-
-Technical approaches to evaluate:
-- ZK-SNARKs (Groth16, PLONK) for succinct proofs
-- Bulletproofs for range proofs on coordinates
-- Geohash commitments for variable precision
-- Homomorphic encryption for distance calculations
-- Ring signatures for group privacy
-
-Integration with canvas:
-- Share location with configurable precision per trust circle
-- Verify location claims from network participants
-- Display verified presence without exact coordinates
-<!-- SECTION:DESCRIPTION:END -->
-
-## Acceptance Criteria
-<!-- AC:BEGIN -->
-- [x] #1 Protocol specification document complete
-- [x] #2 Proof-of-concept proximity proof working
-- [x] #3 Geohash commitment scheme implemented
-- [x] #4 Trust circle precision configuration UI
-- [x] #5 Integration with canvas presence system
-- [ ] #6 Performance benchmarks acceptable for real-time use
-<!-- AC:END -->
-
-## Implementation Notes
-
-<!-- SECTION:NOTES:BEGIN -->
-Completed all zkGPS Protocol Design implementation:
-
-- ZKGPS_PROTOCOL.md: Full specification document with design goals, proof types, wire protocol, security considerations
-
-- geohash.ts: Complete geohash encoding/decoding with precision levels, neighbor finding, radius/polygon cell intersection
-
-- types.ts: Comprehensive TypeScript types for commitments, trust circles, proofs, and protocol messages
-
-- commitments.ts: Hash-based commitment scheme with salt, signing, and verification
-
-- proofs.ts: Proximity, region, temporal, and group proximity proof generation/verification
-
-- trustCircles.ts: TrustCircleManager class for managing social layer and precision-per-contact
-
-- index.ts: Barrel export for clean module API
-<!-- SECTION:NOTES:END -->

backlog/tasks/task-030 - Mycelial-Signal-Propagation-System.md

@@ -1,48 +0,0 @@
----
-id: task-030
-title: Mycelial Signal Propagation System
-status: In Progress
-assignee:
-  - '@claude'
-created_date: '2025-12-04 21:12'
-updated_date: '2025-12-04 23:30'
-labels:
-  - feature
-  - mapping
-  - intelligence
-  - research
-dependencies: []
-priority: medium
----
-
-## Description
-
-<!-- SECTION:DESCRIPTION:BEGIN -->
-Implement a biologically-inspired signal propagation system for the canvas network, modeling how information, attention, and value flow through the collaborative space like nutrients through mycelium.
-
-Core concepts:
-- Nodes: Points of interest, events, people, resources, discoveries
-- Hyphae: Connections/paths between nodes (relationships, routes, attention threads)
-- Signals: Urgency, relevance, trust, novelty gradients
-- Behaviors: Gradient following, path optimization, emergence detection
-
-Features:
-- Signal emission when events/discoveries occur
-- Decay with spatial, relational, and temporal distance
-- Aggregation at nodes (multiple weak signals → strong signal)
-- Spore dispersal pattern for notifications
-- Resonance detection (unconnected focus on same location)
-- Collective blindspot visualization (unmapped areas)
-
-The map becomes a living organism that breathes with activity cycles and grows where attention focuses.
-<!-- SECTION:DESCRIPTION:END -->
-
-## Acceptance Criteria
-<!-- AC:BEGIN -->
-- [ ] #1 Signal propagation algorithm implemented
-- [ ] #2 Decay functions configurable (spatial, relational, temporal)
-- [ ] #3 Visualization of signal gradients on canvas
-- [ ] #4 Resonance detection alerts working
-- [ ] #5 Spore-style notification system
-- [ ] #6 Blindspot/unknown area highlighting
-<!-- AC:END -->

backlog/tasks/task-031 - Alternative-Map-Lens-System.md

@@ -1,47 +0,0 @@
----
-id: task-031
-title: Alternative Map Lens System
-status: To Do
-assignee: []
-created_date: '2025-12-04 21:12'
-labels:
-  - feature
-  - mapping
-  - visualization
-dependencies: []
-priority: medium
----
-
-## Description
-
-<!-- SECTION:DESCRIPTION:BEGIN -->
-Implement multiple "lens" views that project different data dimensions onto the canvas coordinate space. The same underlying data can be viewed through different lenses.
-
-Lens types:
-- Geographic: Traditional OSM basemap, physical locations
-- Temporal: Time as X-axis, events as nodes, time-scrubbing UI
-- Attention: Heatmap of collective focus, nodes sized by current attention
-- Incentive: Value gradients, token flows, MycoFi integration
-- Relational: Social graph topology, force-directed layout
-- Possibility: Branching futures, what-if scenarios, alternate timelines
-
-Features:
-- Smooth transitions between lens types
-- Lens blending (e.g., 50% geographic + 50% attention)
-- Temporal scrubber for historical playback
-- Temporal portals (click location to see across time)
-- Living maps that grow/fade based on attention
-
-Each lens uses the same canvas shapes but transforms their positions and styling based on the active projection.
-<!-- SECTION:DESCRIPTION:END -->
-
-## Acceptance Criteria
-<!-- AC:BEGIN -->
-- [ ] #1 Lens switcher UI implemented
-- [ ] #2 Geographic lens working with OSM
-- [ ] #3 Temporal lens with time scrubber
-- [ ] #4 Attention heatmap visualization
-- [ ] #5 Smooth transitions between lenses
-- [ ] #6 Lens blending capability
-- [ ] #7 Temporal portal feature (click to see history)
-<!-- AC:END -->

backlog/tasks/task-032 - Privacy-Gradient-Trust-Circle-System.md

@@ -1,49 +0,0 @@
----
-id: task-032
-title: Privacy Gradient Trust Circle System
-status: To Do
-assignee: []
-created_date: '2025-12-04 21:12'
-labels:
-  - feature
-  - privacy
-  - social
-dependencies: []
-priority: medium
----
-
-## Description
-
-<!-- SECTION:DESCRIPTION:BEGIN -->
-Implement a non-binary privacy system where location and presence information is shared at different precision levels based on trust circles.
-
-Trust circle levels (configurable):
-- Intimate: Exact coordinates, real-time updates
-- Close: Street/block level precision
-- Friends: Neighborhood/district level
-- Network: City/region only
-- Public: Just "online" status or timezone
-
-Features:
-- Per-contact trust level configuration
-- Group trust levels (share more with "coworkers" group)
-- Automatic precision degradation over time
-- Selective disclosure controls per-session
-- Trust level visualization on map (concentric circles of precision)
-- Integration with zkGPS for cryptographic enforcement
-- Consent management and audit logs
-
-The system should default to maximum privacy and require explicit opt-in to share more precise information.
-<!-- SECTION:DESCRIPTION:END -->
-
-## Acceptance Criteria
-<!-- AC:BEGIN -->
-- [ ] #1 Trust circle configuration UI
-- [ ] #2 Per-contact precision settings
-- [ ] #3 Group-based trust levels
-- [ ] #4 Precision degradation over time working
-- [ ] #5 Visual representation of trust circles on map
-- [ ] #6 Consent management interface
-- [ ] #7 Integration points with zkGPS task
-- [ ] #8 Privacy-by-default enforced
-<!-- AC:END -->

backlog/tasks/task-033 - Version-History-&-Reversion-System-with-Visual-Diffs.md

@@ -1,83 +0,0 @@
----
-id: task-033
-title: Version History & Reversion System with Visual Diffs
-status: Done
-assignee: []
-created_date: '2025-12-04 21:44'
-updated_date: '2025-12-04 23:23'
-labels:
-  - feature
-  - version-control
-  - automerge
-  - r2
-  - ui
-dependencies: []
-priority: high
----
-
-## Description
-
-<!-- SECTION:DESCRIPTION:BEGIN -->
-Implement a comprehensive version history and reversion system that allows users to:
-1. View and revert to historical board states
-2. See visual diffs highlighting new/deleted shapes since their last visit
-3. Walk through CRDT history step-by-step
-4. Restore accidentally deleted shapes
-
-Key features:
-- Time rewind button next to the star dashboard button
-- Popup menu showing historical versions
-- Yellow glow on newly added shapes (first time user sees them)
-- Dim grey on deleted shapes with "undo discard" option
-- Permission-based (admin, editor, viewer)
-- Integration with R2 backups and Automerge CRDT history
-- Compare user's local state with server state to highlight diffs
-<!-- SECTION:DESCRIPTION:END -->
-
-## Acceptance Criteria
-<!-- AC:BEGIN -->
-- [x] #1 Version history button renders next to star button with time-rewind icon
-- [x] #2 Clicking button opens popup showing list of historical versions
-- [x] #3 User can select a version to preview or revert to
-- [x] #4 Newly added shapes since last user visit have yellow glow effect
-- [x] #5 Deleted shapes show dimmed with 'undo discard' option
-- [x] #6 Version navigation respects user permissions (admin/editor/viewer)
-- [x] #7 Works with R2 backup snapshots for coarse-grained history
-- [ ] #8 Leverages Automerge CRDT for fine-grained change tracking
-- [x] #9 User's last-seen state stored in localStorage for diff comparison
-- [x] #10 Visual effects are subtle and non-intrusive
-<!-- AC:END -->
-
-## Implementation Notes
-
-<!-- SECTION:NOTES:BEGIN -->
-Implementation complete in feature/version-reversion worktree:
-
-**Files Created:**
-- src/lib/versionHistory.ts - Core version history utilities
-- src/lib/permissions.ts - Role-based permission system
-- src/components/VersionHistoryButton.tsx - Time-rewind icon button
-- src/components/VersionHistoryPanel.tsx - Panel with 3 tabs
-- src/components/DeletedShapesOverlay.tsx - Floating deleted shapes indicator
-- src/hooks/useVersionHistory.ts - React hook for state management
-- src/hooks/usePermissions.ts - Permission context hook
-- src/css/version-history.css - Visual effects CSS
-
-**Files Modified:**
-- src/ui/CustomToolbar.tsx - Added VersionHistoryButton
-- src/ui/components.tsx - Added DeletedShapesOverlay
-- src/css/style.css - Imported version-history.css
-- worker/worker.ts - Added /api/versions endpoints
-
-**Features Implemented:**
-1. Time-rewind button next to star dashboard
-2. Version History Panel with Changes/Versions/Deleted tabs
-3. localStorage tracking of user's last-seen state
-4. Yellow glow animation for new shapes
-5. Dim grey effect for deleted shapes
-6. Floating indicator with restore options
-7. R2 integration for version snapshots
-8. Permission system (admin/editor/viewer roles)
-
-Commit: 03894d2
-<!-- SECTION:NOTES:END -->

backlog/tasks/task-034 - Fix-Google-Photos-403-error-on-thumbnail-URLs.md

@@ -1,42 +0,0 @@
----
-id: task-034
-title: Fix Google Photos 403 error on thumbnail URLs
-status: To Do
-assignee: []
-created_date: '2025-12-04 23:24'
-labels:
-  - bug
-  - google
-  - photos
-dependencies:
-  - task-025
-priority: low
----
-
-## Description
-
-<!-- SECTION:DESCRIPTION:BEGIN -->
-Debug and fix the 403 Forbidden errors when fetching Google Photos thumbnails in the Google Data Sovereignty module.
-
-Current behavior:
-- Photos metadata imports successfully
-- Thumbnail URLs (baseUrl with =w200-h200 suffix) return 403
-- Error occurs even with valid OAuth token
-
-Investigation areas:
-1. OAuth consent screen verification status (test mode vs published)
-2. Photo sharing status (private vs shared photos may behave differently)
-3. baseUrl expiration - Google Photos baseUrls expire after ~1 hour
-4. May need to use mediaItems.get API to refresh baseUrl before each fetch
-5. Consider adding Authorization header to thumbnail fetch requests
-
-Reference: src/lib/google/importers/photos.ts in feature/google-export branch
-<!-- SECTION:DESCRIPTION:END -->
-
-## Acceptance Criteria
-<!-- AC:BEGIN -->
-- [ ] #1 Photos thumbnails download without 403 errors
-- [ ] #2 OAuth consent screen properly configured if needed
-- [ ] #3 baseUrl refresh mechanism implemented if required
-- [ ] #4 Test with both private and shared photos
-<!-- AC:END -->