FUTURE: link related files together (without relying only on tags) #241

Open
opened 2026-09-27 15:44:53 +00:00 by kayg · 0 comments
Owner

Status: OPEN, future. Owner idea (2026-09-27), filed to explore later. Do not build until the owner grill settles the questions below (DESIGN "OPEN" rule).

Idea

Link files to each other directly: a simple way to associate related files (e.g. a contract PDF ↔ its signed scan ↔ the invoice; a RAW ↔ its edited JPEG ↔ the video from the same shoot) without relying only on tags.

What exists

  • Tags (frontmatter tags:, XMP dc:subject), linked notes with backlinks (DESIGN §9): today files can only be associated through a note that embeds them, or a shared tag.
  • Collection metadata lives in <home>/.calternal/ as JSON with "schema": "calternal.<kind>/<n>"; sidecars only for single-file metadata (XMP for photos). Stable identities: calternal-id / file ID (DESIGN §33), so links must survive rename/move.
  • Info panel / inspector popover (Cmd+I) is where "Related" would show.

Sketch to validate in the grill

  • "Link to…" action on any file (context menu, ⋯, inspector): pick files via the search palette; creates a bidirectional link by file ID.
  • Inspector shows Related files (and notes via backlinks) with thumbnails; Copy link per item; drag a file onto another to link.
  • Storage: one JSON per link set in .calternal/links/ (or per-file sidecar?) keyed by file IDs; survives rename/move; removed from both sides on delete (trash keeps it until purge).
  • Search: related:<file> filter; sync/WebDAV clients ignore it (server-side metadata).

Questions for the owner grill

  1. Pairwise links or named groups ("bundles")? Directional (e.g. "derived from") or plain "related"?
  2. Should linking also work across users when files are shared?
  3. Should notes, events, tasks and photos join the same link graph (one "related" concept for every object) or files only?
  4. Automatic suggestions (same capture time, same name stem like IMG_1234.CR3/.JPG, same folder upload batch) or manual only?
  5. Storage location trade-off: JSON in .calternal/ (portable, visible to export) vs database only.
**Status: OPEN, future.** Owner idea (2026-09-27), filed to explore later. Do not build until the owner grill settles the questions below (DESIGN "OPEN" rule). ## Idea Link files to each other directly: a simple way to associate related files (e.g. a contract PDF ↔ its signed scan ↔ the invoice; a RAW ↔ its edited JPEG ↔ the video from the same shoot) **without relying only on tags**. ## What exists - Tags (frontmatter `tags:`, XMP `dc:subject`), linked notes with backlinks (DESIGN §9): today files can only be associated through a note that embeds them, or a shared tag. - Collection metadata lives in `<home>/.calternal/` as JSON with `"schema": "calternal.<kind>/<n>"`; sidecars only for single-file metadata (XMP for photos). Stable identities: calternal-id / file ID (DESIGN §33), so links must survive rename/move. - Info panel / inspector popover (Cmd+I) is where "Related" would show. ## Sketch to validate in the grill - "Link to…" action on any file (context menu, ⋯, inspector): pick files via the search palette; creates a bidirectional link by file ID. - Inspector shows **Related files** (and notes via backlinks) with thumbnails; Copy link per item; drag a file onto another to link. - Storage: one JSON per link set in `.calternal/links/` (or per-file sidecar?) keyed by file IDs; survives rename/move; removed from both sides on delete (trash keeps it until purge). - Search: `related:<file>` filter; sync/WebDAV clients ignore it (server-side metadata). ## Questions for the owner grill 1. Pairwise links or named groups ("bundles")? Directional (e.g. "derived from") or plain "related"? 2. Should linking also work across users when files are shared? 3. Should notes, events, tasks and photos join the same link graph (one "related" concept for every object) or files only? 4. Automatic suggestions (same capture time, same name stem like IMG_1234.CR3/.JPG, same folder upload batch) or manual only? 5. Storage location trade-off: JSON in `.calternal/` (portable, visible to export) vs database only.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
kayg/calternal#241
No description provided.