C.W.K.
Stream
Lesson 04 of 05 · published

Reference the Moment, Don't Ship It

~12 min · sidekick, reference, handoff, recall

Level 0Reel Novice
0 XP0/39 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"Ask Pippa About This Moment resolves the current release, copies a moment reference line, calls Recall's pippa-handoff, and opens the returned canonical conversation URL. No conversation state lives in this app."

The Same Discipline, One Layer Up

Track 3 taught the handoff into the player: a URL names a video by identity, never by path. The Pippa lane is the mirror image — the handoff out to a conversation — and it obeys the exact same discipline. When you click "Ask Pippa About This Moment," Ashen Reel does not ship a copy of the transcript, a slice of the video, or a bundle of state. It ships a compact moment reference: which video, which release, which millisecond. A pointer, not a payload.

The reference is durable by preference: when the media came from Recall, the anchor is its release identity plus a timestamp, so it survives corrections and re-resolves cleanly. Only when the media isn't Recall-sourced does it fall back to a path. Either way, what travels is a small, resolvable handle — the receiver looks up the real thing, exactly as the strict parser did in reverse.

Ship a reference the receiver can resolve, not a copy of the thing itself. A reference stays small, stays fresh (the receiver resolves the current truth), and keeps ownership where it belongs. Copying the payload duplicates data, ages instantly, and drags a second owner into existence. Point, don't photocopy.

The whole flow is orchestration with no local state — resolve, copy a human-readable pointer, hand off, open:

The transcript rail is the read side of the same idea. Beside the video, the rail projects the current release's segments into session memory, highlights the spoken line at the playback position, and lets a click seek exactly to it — with auto-follow pausing while your pointer hovers so you can read ahead. It's read-only, session-scoped, and owns nothing. Display is a projection; the handoff is a reference. Neither one copies Recall's truth.

Why 'Pointer, Not Payload' Keeps You Honest

The tell that you've drifted from client to owner is always the same: you start copying the payload 'to be safe' or 'for speed.' The moment Ashen Reel copied the transcript into the handoff, or stashed the conversation locally, it would have quietly become a second owner of Recall's and cwkPippa's truth — the exact drift the whole architecture is built to prevent. Keeping the handoff a reference and the rail a projection is what lets a video player host a rich Pippa moment without ever holding a byte it shouldn't. The restraint is the feature.

Code

'Ask Pippa About This Moment' ships a reference, holds no conversation state·swift
/// Ask about the current moment. Ships a REFERENCE, not a payload; the app
/// keeps no conversation state -- it orchestrates and opens.
func askAboutThisMoment() async throws {
    let ref = MomentReference(
        // Recall-sourced -> durable identity. Otherwise -> path fallback.
        anchor: current.isRecallSourced
            ? .release(current.releaseID, atMs: engine.observedTimeMs)
            : .file(current.path, atMs: engine.observedTimeMs)
    )

    clipboard.copy(ref.humanLine)                  // a durable, readable pointer
    let convo = try await recall.pippaHandoff(ref) // Recall returns the canonical convo
    open(convo.url)                                // the WebUI/conversation, not us

    // Nowhere did we copy the transcript, store the conversation, or persist
    // a marker. We pointed; the owners resolved. No second owner was born.
}

External links

Exercise

Find a spot where your system hands data to another component or service by copying the whole payload into the message. Ask: could you send a reference the receiver resolves instead — an id, a URI, a versioned handle? For one case, redesign the message to carry a durable reference rather than a copy. What goes stale less, and which 'second owner' of the data disappears when you stop copying?
Hint
The pattern to flip is 'embed the full data in the message.' Its costs are staleness (the copy ages) and a new owner (someone now holds a second version). A reference the receiver resolves stays small and fresh and leaves ownership put. Reserve embedding for when the receiver genuinely can't resolve the reference itself.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.