Self-Hosted Personal Media Storage

One-line definition: Provide a self-operated place where the operator, family, and friends can store and share their personal media (photos, videos, files) under their own control instead of paying a third-party cloud provider.

Purpose & Business Outcome

What business outcome does this capability deliver? Why does it exist?

This capability exists so that a small, trusted circle of people (the operator, their family, and their friends) can keep their personal media without surrendering it to a commercial cloud provider. The outcomes it delivers, in order of importance:

1. Privacy — Users’ content is not visible to, mined by, or monetized by any third party. The operator’s circle decides what happens to their data.
2. Longevity — Content remains accessible and intact over long time horizons, not subject to a vendor’s pricing changes, product sunsets, or account terminations.
3. Control — The operator decides how the system runs, who is on it, and how content is governed; users decide who sees their own content.
4. Cost avoidance — Avoiding ongoing per-GB subscription fees to a commercial cloud storage provider is a real but secondary benefit.

When these outcomes conflict, the order above is the tiebreaker. Privacy beats convenience; longevity beats operator convenience; control beats cost.

Stakeholders

• Owner / Accountable party: The operator (Carson). Sole accountable party for the system existing, running, and continuing to run.
• Primary actors (initiators): Any authorized user — the operator, family members, or friends — uploading, viewing, sharing, or deleting their own content.
• Secondary actors / consumers: Other authorized users who have been explicitly granted access to a piece of content (individually or via a shared group/album).
• Affected parties (impacted but not directly involved): Subjects depicted in shared media (e.g. a family member who appears in a photo someone else uploaded) — they are affected by the privacy posture even if they are not the user who uploaded the content.

Triggers & Inputs

What initiates the capability, and what information must be available?

• Triggers:
  • A user uploads a file (single, manual upload).
  • A user’s device performs an automated backup (e.g. phone camera roll sync).
  • A user performs a bulk import from an existing provider (e.g. a Google Photos takeout archive).
  • A user views, downloads, or organizes their own content.
  • A content owner shares content with another user or a shared group.
  • A user deletes their own content.
• Required inputs:
  • An authenticated identity for the acting user.
  • The content itself (file bytes + whatever metadata the source provides, e.g. capture timestamps).
  • For sharing actions: the identity of the recipient user or shared group.
• Preconditions:
  • The user has been explicitly invited and provisioned by the operator (the user set is closed; no self-signup).
  • The user holds their own credentials. Lost credentials cannot be recovered (see Business Rules).

Outputs & Deliverables

What does the capability produce? What changes in the world after it runs?

• Direct outputs:
  • The user’s content is durably stored and retrievable by them.
  • Shared content becomes retrievable by the explicitly named recipients.
  • Content the user deleted is removed from their view immediately and purged from the system after the retention window (see Business Rules).
• Downstream effects / state changes:
  • The user (and the people they share with) can rely on this system as their primary store and stop paying a commercial provider for the same content.
  • The operator’s circle accumulates a long-lived, private archive of personal media that is not dependent on any external vendor.

Business Rules & Constraints

• Closed user set. Only the operator can add or remove users. There is no public sign-up. Users may be the operator, family members, or friends — chosen by the operator.
• Private by default. All content is private to its owner unless the owner explicitly shares it. Sharing may be one-to-one or via a shared group (e.g. a “family album”). No content is visible to other users — including the operator — without an explicit share.
• Lost credentials = lost data. If a user loses access to their credentials, their data is unrecoverable. The operator cannot reset access in a way that exposes the user’s content. This is a deliberate Signal-style trade-off in service of the privacy outcome.
• No storage quotas. Users are not subject to per-user storage limits. Capacity planning is the operator’s problem, not the users'.
• No illegal content. Users may not store content that is illegal in the operator’s jurisdiction. When a user lives in a different jurisdiction than the operator, the operator’s jurisdiction is the single governing law the system enforces — the operator runs the system and carries the legal exposure, so the operator’s local law sets the enforceable floor. Users remain independently responsible for complying with their own local laws, but the rule the operator acts on is the operator’s jurisdiction. The operator reserves the right to terminate a user’s access on credible evidence of a violation, even though the operator cannot inspect user content directly.
• No affected-party recourse process. There is no system-provided process for a non-user depicted in shared media (an affected party) to request its removal. This is a deliberate decision, not an omission: content is private within a closed, trusted circle, is shared only to explicitly named recipients, and the operator cannot inspect it or compel a content owner to remove it. Objections between people in the circle are expected to be resolved interpersonally, outside the system. The one exception is the No illegal content rule — where a depiction is itself illegal in the operator’s jurisdiction (e.g. non-consensual intimate imagery), the operator may act via the termination lever above on credible evidence.
• Off-site backup is allowed. Content may be replicated to an off-site location for durability, provided the off-site copy preserves the same privacy properties (no third party can read user content).
• 30-day retention after deletion / departure. When a user deletes content, or when a user leaves the system entirely, their data is retained for 30 days and then purged. The window exists for accident recovery; after it elapses, the data is gone.
• Operator succession. Longevity is preserved through two complementary mechanisms: (a) every user can pull a complete on-demand archive of their own content, without operator involvement, while the system is healthy — users are expected to pull these proactively (and may schedule periodic pulls), since on-demand export is only available when the system is up; and (b) a designated successor operator holds the credentials and runbook needed to keep the system running if the primary operator becomes unavailable. Successor credentials are sealed/escrowed (e.g. via a password-manager handoff or physical envelope) and not used for routine operation; takeover is a discrete event triggered by operator unavailability, not ongoing shared administration. Exports preserve user data even if no successor takes over; the successor preserves continuity of the system itself. If the system is down and no successor takes over, only previously-pulled exports survive — this is the accepted trade-off behind “lost credentials = lost data.” The successor’s access is to operate the system, not to read user content — the privacy properties (private by default, lost credentials = lost data) continue to hold.

Success Criteria & KPIs

• Number of active users. People in the operator’s circle who actually use the system as a place to put their content (not just provisioned accounts that sit idle). A user counts as active if they performed at least one of {upload, view, download, share} within the trailing 30 days; a provisioned user with no such activity in that window is dormant. Growth — or at minimum non-attrition — in the active count over time indicates the capability is meeting a real need versus their previous cloud provider.
• Zero data loss. No user ever loses content that they did not themselves delete. This is a hard binary: any incident of unintended data loss is a failure of the capability, regardless of cause.

Out of Scope

• General-purpose self-hosted application hosting (e.g. running a Minecraft server, hosting other apps for the operator’s circle). This is a separate capability and will be defined in its own document.
• Public sharing. Sharing content with anyone outside the operator’s invited user set is not supported.
• Collaborative editing of files. This capability stores and shares media; it does not provide document editing, comments, or other collaboration features.
• Monetization or commercial use. The capability serves a private circle; it is not a product offered to the public.
• Account/credential recovery. Explicitly excluded by the privacy posture above.

Open Questions

None at this time.