bf9787e56a
Gap analysis of docs/architecture.md against openspec/ and docs/ideas/ found the envisioned-but-uncaptured remainder. This commit captures it: New OpenSpec change (validated): - route-federation — the collaboration half of the federation vision: routes as dereferenceable trails:Route objects, Create/Update fan-out, Invite/Accept collaboration mirroring (arch decision #2), cross-instance Planner edits via HTTP-Signature-requested scoped tokens (decisions #3/#12), mirror sync healing (#16). Depends on social-federation §6 + route-sharing; carries the 2026-06-07 soak lessons as design constraints. New docs/ideas/ explorations: - instance-administration — registration toggle, suspend/ban, federation blocklists, reports (moderation now gates the federated comments idea) - social-interactions — local likes + comments (don't exist even locally; the foundation federated kudos/comments attach to) - activity-participants — group tagging with confirm/decline + federated mentions (the participants jsonb column is an untyped stub) - multi-day-collections — architecture open question #1, directions evaluated architecture.md cleanup: - Mastodon-compat section annotated with shipped/captured state + the live-soak interop lessons (attachment arrays, tombstones, 10s timeout, no backfill) - api.trails.cool removed (contradicted resolved decision #18) - Phase 1 ticked (shipped); Phase 2/3 items annotated with where each is tracked; specs/ → openspec/, activity.* → journal.*, cx21 → cx23 - brouter-web open question marked resolved-in-practice; new section pointing to where the unshipped vision is tracked Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
45 lines
2.1 KiB
Markdown
45 lines
2.1 KiB
Markdown
# Multi-day activity collections
|
|
|
|
Pre-spec exploration. This is `docs/architecture.md`'s **explicit open
|
|
question #1** (§Multi-Day Route Support: "Exact data model for
|
|
collections TBD — needs more design work"). Multi-day *routes* shipped
|
|
(day-break waypoints, per-day stats, track segments per day); the
|
|
activity side — recording a 5-day bikepacking trip as one entity with
|
|
five day-recordings — is captured nowhere.
|
|
|
|
## The shape from the architecture
|
|
|
|
- A multi-day activity is a **collection linking individual
|
|
day-activities**
|
|
- Each day-activity keeps its own GPS trace, photos, description
|
|
(possibly imported from different devices/apps per day)
|
|
- The collection references the planned multi-day route as a whole
|
|
- Day-activities can be imported one at a time (Garmin/Komoot/Wahoo per
|
|
day) and attached as the trip progresses
|
|
|
|
## Data-model directions to evaluate
|
|
|
|
1. **Collection row + membership table** —
|
|
`journal.trips (id, owner, name, description, route_id?)` +
|
|
`journal.trip_activities (trip_id, activity_id, day_index)`.
|
|
Activities stay fully independent (visibility, federation, photos);
|
|
the trip is a presentation/grouping layer. Cheapest; probably right.
|
|
2. **Self-referencing activities** (`parent_activity_id` + a `kind`
|
|
column). Fewer tables but overloads the activity model and makes
|
|
feed/outbox queries carry exclusion rules forever.
|
|
3. Whatever we pick must answer: trip-level visibility vs per-day
|
|
visibility (suggest: trip visibility caps day visibility), trip-level
|
|
stats (sum of days), and how a trip federates (one Note per day as
|
|
today, plus a trip page link? A trip-level Note at completion?).
|
|
|
|
## Notes
|
|
|
|
- Pairs naturally with `activity-participants.md` (group trips) and the
|
|
"Tour mode" sketch in `fediverse-enhancements.md` (day N/M check-in
|
|
posts are trivial once a trip entity exists).
|
|
- The route side already encodes day breaks in GPX track segments —
|
|
importing a multi-day route's recording per segment could pre-seed
|
|
day-activities.
|
|
- Keep GPX exportability: a trip should export as one GPX with track
|
|
segments per day (mirror of the route format), preserving the
|
|
data-ownership principle.
|