Share Content

One-line definition: A content owner grants a specific fellow user, or a shared group/album, access to chosen content — and can review and revoke that access later — while everything else stays private.

Parent capability: Self-Hosted Personal Media Storage

Persona

The actor is a content owner — a Primary actor from the parent capability’s Stakeholders — who wants to let someone else in the trusted circle see specific media of theirs. The recipient’s side of this interaction is a separate journey (Receive Shared Content); this doc is strictly the owner deciding to share and staying in control of that decision.

• Role: A user who owns content and wants a specific person, or a defined group, to see specific items — a grandparent seeing the new baby photos, a “family album” the whole family can see.
• Context they come from: They are in their own library (View and Organize Content) and something there is worth showing to someone. Their reference point is the commercial photo app’s sharing — but with a sharper expectation of privacy, because privacy is why they left.
• What they care about here: That exactly the people they intend can see exactly what they chose — no more — that the rest of their library stays private, and that they can take access back later if they change their mind.

Goal

“I want just these photos seen by just this person — or our family album — nobody else, and I want to be able to take that access back later.”

Entry Point

The owner is in their own library and decides that some specific content should be seen by someone specific. The trigger is social, not systemic: a moment worth sharing, a person who would want to see it, an album the family keeps together. They arrive already knowing what they want to share and roughly with whom.

Journey

1. Select the content. The owner picks the specific item(s) to share — one photo, a set, a whole album’s worth. Everything they do not pick stays private; sharing is strictly additive and scoped to the selection.
2. Choose the recipient. The owner picks who gets access, in one of two shapes:
   • One-to-one — another named existing user in the circle.
   • A shared group — e.g. a “family album” that a defined set of users can see. A shared group is owned and administered by the user who creates it, not by the operator: that owner draws the group’s members from the closed user set and decides what content the album holds (members and content can change over time). The operator’s only role stays provisioning users into the circle — group administration is a user-level act, not an operator burden. In both shapes, the recipient must already be a user (see Constraints Inherited — Closed user set). There is no sharing to an email address, a public link, or anyone outside the invited set.
3. Grant access. The owner shares. The content becomes visible to the chosen recipient(s) and to no one else.
4. See exactly who can now see it. The owner gets a clear, truthful picture of who has access to this content as a result — so “who can see this?” always has an answer they can check, not a vague sense that they shared it “somewhere.”
5. Review and revoke later. At any later point the owner can look at what they have shared and with whom, and revoke access. Revocation removes the recipient’s shared view going forward. On the recipient’s side the view does not simply blink out of existence — they see a plain “no longer shared” state (see Receive Shared Content), enough to read the change as intentional. That message is deliberately neutral: it does not reveal why access ended or distinguish a revoke from a deletion, so revoking never leaks the owner’s private actions.

A note on what revocation can and cannot do

Revocation reliably removes the shared view. It cannot reach a copy a recipient already downloaded — once a recipient saves a copy, that copy is theirs (see Receive Shared Content). The experience must be honest about this boundary so the owner shares with correct expectations rather than a false sense of total recall.

Crucially, the system does not report a recipient’s activity back to the owner — the owner is not notified when a recipient views or downloads shared content. Sharing here is a relationship inside a trusted circle, not a surveillance channel over the people the owner chose to share with; feeding the owner a log of recipient views would erode those recipients’ privacy exactly as the operator’s non-visibility protects everyone else’s. Because the owner therefore cannot know whether a copy was already downloaded before a revoke, the honest posture is the same one the download boundary already demands: treat anything shared as potentially already kept. This makes “notify on download” not just unnecessary but beside the point — the owner should share only what they are comfortable leaving in a recipient’s hands, and the experience sets that expectation up front rather than offering after-the-fact tracking.

Flow Diagram

flowchart TD
    Start([In their library, owner decides to share]) --> Select[Select specific content]
    Select --> Who{Choose recipient}
    Who -->|One person| Named[A named existing user]
    Who -->|A group| Group[A shared group / family album]
    Named --> Closed{Recipient already a user?}
    Group --> Closed
    Closed -->|No| Invite[Can't share outside the circle —<br/>operator must invite them first]
    Invite --> Who
    Closed -->|Yes| Grant[Grant access]
    Grant --> Confirm[Owner sees exactly who can now view it]
    Confirm --> Live((Recipient can see it;<br/>rest of library stays private))
    Live -->|Change of mind| Revoke[Review shares & revoke]
    Revoke --> Note[Shared view removed going forward —<br/>already-downloaded copies remain with recipient]
    Note --> Live

Success

A successful share leaves the owner with:

• Precisely-scoped visibility. Exactly the intended people can see exactly the intended content, and nothing else of theirs leaked.
• A clear, checkable picture of access. They know who can see what, and can revisit it — sharing never becomes a fog of “who did I show this to?”
• Retained control. They can revoke, and they understand the one honest limit (downloaded copies), so their expectations match reality.
• Undisturbed privacy everywhere else. The act of sharing one thing did not weaken the privacy of everything else; their library is still private by default.

Edge Cases & Failure Modes

• Sharing with someone who isn’t a user yet. Experience-level handling: not possible directly. The owner can only choose from people already in the Closed user set. To share with someone new, that person must first be invited and provisioned by the operator (Join as an Invited User); only then can the owner share with them. There is no public link and no external-email share — this is a deliberate consequence of the capability’s Public sharing being out of scope.
• Revoking after a recipient has downloaded. The shared view disappears, but a downloaded copy is now the recipient’s own and is beyond the owner’s reach. The experience states this plainly rather than implying revocation claws back copies.
• A recipient wants to pass the content on. Experience-level handling: re-sharing the owner’s shared view is not possible — a recipient cannot forward, re-share, or add someone else to what was shared with them. This keeps the owner’s guarantee intact: content reaches only the people the owner explicitly named. The one path by which shared content ever reaches someone new runs through the honest boundary the capability already accepts — a recipient downloads it, at which point the downloaded copy is their own content, and they may share that copy as its new owner. That is a fresh share of a distinct copy the recipient owns, not the owner’s original share propagating onward; the owner’s original and its access list are untouched. This is the single, consistent answer shared with Receive Shared Content.
• Shared-group membership changes. A shared group is administered by its owner (the user who created it — see Journey step 2), who adds and removes members from the closed user set. When someone is added to or removed from the group, the experience makes clear how that affects who can see content already shared to the group — so the owner is never surprised by a new group member gaining access to old content, or a removed member losing their view going forward (a removed member is revoked exactly as an individual revoke, and any copy they already downloaded remains theirs).
• A person depicted in the shared media objects. There is No affected-party recourse process in the system — a non-user depicted in a photo has no system-provided way to force its removal, and even a user who is merely depicted (not the owner) has no override. Such objections are expected to be resolved interpersonally, outside the system; the owner decides. The sole exception is the operator’s termination lever under No illegal content: where a depiction is itself illegal in the operator’s jurisdiction, the operator may act on credible evidence — but the operator still cannot inspect content directly. The experience should not imply any in-system “report this share” flow beyond that narrow, operator-driven lever.
• The operator is not a privileged viewer. Sharing among users never makes content visible to the operator. The operator sees a user’s content only if that user explicitly shares it to the operator, exactly as they would with anyone else.
• Over-broad selection. If the owner accidentally selects more than they meant (e.g. a whole album when they wanted one photo), the review-access step is their safety check — they can see the full scope of what they just exposed and pull it back before it matters.

Constraints Inherited from the Capability

This UX must respect the following items from the parent capability’s Business Rules and Success Criteria — named so future readers can trace the lineage:

• Private by default. This is the rule the whole journey turns on. All content is private to its owner unless the owner explicitly shares it. Sharing is the only mechanism by which anyone else — including the operator — ever sees a user’s content. Nothing about this journey erodes the default; it is a scoped, deliberate exception the owner controls.
• Closed user set. Recipients must be members of the invited circle. Only the operator adds or removes users; an owner cannot conjure a recipient. There is no public sign-up and, correspondingly, no public sharing — Public sharing is explicitly out of scope in the capability.
• No affected-party recourse process. People depicted in shared media have no system-provided removal path; objections are resolved interpersonally. This is a deliberate capability decision, not a gap this UX should try to fill.
• No illegal content. The single operator lever that can override an owner’s sharing is termination on credible evidence of illegal content, governed by the operator’s jurisdiction. This UX surfaces that lever precisely and does not overstate it into general operator moderation of shares.
• Lost credentials = lost data. Sharing does not create an operator backdoor or a recovery path. A recipient still holds their own credentials, and the privacy posture (no operator visibility without explicit share) is preserved throughout.
• KPI — Zero data loss. Reviewed here for the guarantee it imposes on this journey: sharing and revoking are non-destructive to the owner’s content. Sharing is purely additive — it grants visibility, and never moves, copies out, or deletes the underlying item — so it cannot cause the owner to lose anything. Revoking a share must remove visibility, never the content itself; a revoke that deleted the owner’s original would be a zero data loss failure hiding inside a sharing action. The one place data does leave the owner’s control — a recipient’s downloaded copy surviving revocation — is not a loss of the owner’s data (their original is untouched); it is a limit on recall, addressed honestly in the revocation note above. This journey therefore has no path that undermines the zero-data-loss guarantee.
• KPI — Number of active users. Sharing is one of the four counted active-user actions ({upload, view, download, share}). A circle that actually shares with each other is a circle getting real value from the system — sharing is arguably the strongest signal that the capability is meeting a social need the old provider met.

Out of Scope

• The recipient’s experience. What the recipient sees, does, and is allowed to do with shared content is Receive Shared Content. This doc stops at the owner’s side of the interaction.
• Selecting and browsing content to share. Finding and picking the content happens in View and Organize Content; this doc picks up once the owner has decided to share.
• Provisioning a new recipient. If the intended recipient isn’t a user yet, inviting them is the operator’s job, covered by Join as an Invited User.
• Deleting shared content. What happens to a share when the owner deletes the underlying content (recipients lose the view; downloaded copies remain) is covered by Delete Content and Leave.
• Public sharing of any kind. Sharing outside the invited circle is explicitly out of scope for the entire capability and therefore impossible in this journey.

Open Questions

None remaining. The four questions this journey previously carried have been resolved and folded into the sections above. The first and last are shared with Receive Shared Content; the answers below are the single, consistent resolution both journeys use (Receive Shared Content adopts them in its own doc):

• Can a recipient re-share content? → No — re-sharing the owner’s shared view is blocked. Content reaches someone new only when the owner shares it directly, or when a recipient downloads it: a downloaded copy becomes the recipient’s own content, which they may then share as its new owner. The owner’s original share never propagates onward, preserving “exactly the people the owner intends” (Edge Cases). (Shared with Receive Shared Content.)
• Is the owner notified when a recipient views or downloads? → No. The system does not report recipient activity back to the owner — sharing is a trusted-circle relationship, not a surveillance channel. The owner is instead guided to treat anything shared as potentially already-downloaded-and-kept, which is the honest posture the revocation limit already demands (see the revocation note under Journey).
• Who owns and administers a shared group? → The user who creates it — not the operator. That owner draws the group’s members from the closed user set and decides what content the album holds; the operator’s only role stays provisioning users into the circle (Journey step 2, Edge Cases).
• What does a recipient see when access changes? → A graceful “no longer shared” state, not a silent disappearance — neutral enough to read as an intentional change, without revealing why or distinguishing a revoke from a delete, and with any already-downloaded copies left untouched (Journey step 5). (Shared with Receive Shared Content.)