Magic-link family contributions (needs a product decision) #122

New issue

Open

opened 2026-07-28 06:06:09 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-07-28 06:06:09 +00:00

Severity: MEDIUM - needs a product decision first

The idea

Generate a scoped, expiring link for a handful of photos and send it to a relative who will never
log into a review tool. They see a large photo (front and back) and two or three plain questions —
"When do you think this was? Who is in it? What was the occasion?" Their answers land as comments
and manual evidence, attributed to them.

Why it could matter more than anything else on the roadmap

The best evidence source for this collection is the memory of people in their seventies to
nineties, and that source is time-limited in the most literal way. The OAuth-plus-roles path
(#22, #36) is right for core reviewers but is a wall for exactly the people who know the most.

This is the idea most likely to change what the finished archive contains, not merely how
accurately it is dated.

The decision needed

It punches a deliberate hole in the application's "every route authenticated" posture — right after
a security milestone spent closing exactly that class of hole. That is not automatically wrong, but
it must be a conscious choice with the design done carefully:

Signed, single-purpose tokens scoped to specific photo ids, granting comment and evidence-create
only
Short expiry and a revocation list
No enumeration, no navigation into the rest of the app
Mobile-first, deliberately tiny page
Answers flagged in the workspace as "via shared link — Aunt Ruth"

Lower-risk fallback: a "print or email this photo set as a question sheet" export captures some
of the value with zero new attack surface. Worth considering first.

Done when

A decision is recorded on whether to build this at all
If yes: scoped tokens, expiry, revocation, and a security review of the endpoint
Contributions appear attributed in the review workspace
If no: the question-sheet export alternative is filed instead

References

docs/circa-spec.md §4 (auth posture)

Related: #22, #24, #51.

## Severity: MEDIUM - needs a product decision first ## The idea Generate a scoped, expiring link for a handful of photos and send it to a relative who will never log into a review tool. They see a large photo (front and back) and two or three plain questions — "When do you think this was? Who is in it? What was the occasion?" Their answers land as comments and manual evidence, attributed to them. ## Why it could matter more than anything else on the roadmap The best evidence source for this collection is the memory of people in their seventies to nineties, and that source is time-limited in the most literal way. The OAuth-plus-roles path (#22, #36) is right for core reviewers but is a wall for exactly the people who know the most. This is the idea most likely to change what the finished archive *contains*, not merely how accurately it is dated. ## The decision needed It punches a deliberate hole in the application's "every route authenticated" posture — right after a security milestone spent closing exactly that class of hole. That is not automatically wrong, but it must be a conscious choice with the design done carefully: - Signed, single-purpose tokens scoped to specific photo ids, granting comment and evidence-create only - Short expiry and a revocation list - No enumeration, no navigation into the rest of the app - Mobile-first, deliberately tiny page - Answers flagged in the workspace as "via shared link — Aunt Ruth" **Lower-risk fallback:** a "print or email this photo set as a question sheet" export captures some of the value with zero new attack surface. Worth considering first. ## Done when - [ ] A decision is recorded on whether to build this at all - [ ] If yes: scoped tokens, expiry, revocation, and a security review of the endpoint - [ ] Contributions appear attributed in the review workspace - [ ] If no: the question-sheet export alternative is filed instead ## References - `docs/circa-spec.md` §4 (auth posture) Related: #22, #24, #51.

claude-bot added this to the v0.6.0 milestone

2026-07-28 06:06:09 +00:00

claude-bot added the

security

frontend

backend

labels

2026-07-28 06:06:09 +00:00