Access Model
Deep dive into Uhpenry's access model for Projects how access is chosen, enforced, and audited. Covers decision points, flows, security, and developer patterns.
This document explains how access works for Uhpenry Projects (repository-backed products). It focuses on the access model the conceptual choices, decisions, and programmatic patterns that guarantee correct entitlement, auditability, and owner control.
Short summary: Projects expose one of two high-level access categories Showcase (public view-only) or Standard (gated access). Standard includes two delivery modes: Download (artifact delivery / clone) and Invite (collaborator access with read-only permissions). Every access event is gated by a Snapgate and recorded by a Snapcharge; a Snapshot aggregates history.
Goals of the Access Model
- Principle of least privilege: purchasers receive only the minimal rights required (read-only collaborator or download artifact).
- Auditability: every change in access, payment, or enforcement is recorded as a verifiable event.
- Reproducibility: a user can reconstruct exactly what they received at the time of purchase.
- Owner control: owners can revoke, suspend, or limit access and see evidence of attempts.
- Robustness: payments and grants are atomic no access if the platform fails to record entitlement.
High-level Access Types
-
Showcase (Display-only)
- Purpose: public, discoverable display of a repository or project without granting download or collaboration rights.
- Characteristics: view-only UI, metadata, screenshots, readme rendering, no access to code artifacts.
- Use cases: portfolios, marketing, documentation.
-
Standard (Gated Access)
- Purpose: grant controlled access to repository content, either as a downloadable artifact or as a collaborator invite.
- Delivery modes (sub-types):
- Download Access Default. User receives a frozen, downloadable artifact (zip/tar or pre-built bundle) or an authenticated clone endpoint for the selected version.
- Invite Access User is added as a repository collaborator with read-only permission on the owner's git provider (e.g., GitHub).
Note: The access model is a property of the Project resource and is chosen by the owner during publish/setup.
Download Access (behavior & constraints)
This section is a focused explanation of the download delivery mode (high level). Details for implementation examples are in the implementation guide.
-
What user receives: a frozen artifact that represents the project state at the selected commit/tag this artifact is what Snapcharge records in
structure
andcommit
. -
Versioning rule: Each purchase is bound to the chosen version. Future updates by owner do not change the previously delivered artifact users may need to purchase or claim an update (recorded as a new Snapcharge).
-
Delivery options:
- Pre-built snapshot archive (server-generated zip/tar) stored in an object store with content hash.
- On-demand archive generated at purchase time and stored with
contentHash
for replayability. - Authenticated git clone with short-lived credentials (less common; careful with provider throttling).
-
Access revocation: owner can revoke future access (disable Snapshots or new downloads) and suspend Snapgate; for artifacts already downloaded, revocation is retrospective and prevents further remote downloads but cannot delete copies already retrieved by users.
Invite Access (behavior & constraints)
-
What user receives: a collaborator invite to the repository with read permission.
-
Permission level: limited to
read
(no push, no destructive rights). Owner can elevate permissions on Git provider portal manually. -
Invite mechanics:
- Platform calls provider API (e.g., GitHub) using owner's OAuth/installation token to create invite.
Snapcharge.gitUsername
or user email may be used to route the invite.- Snapcharge records the invite state (invited, accepted, expired).
-
Revoke: owner can remove the collaborator on provider; Snapgate records revocation and Snapshot captures it.
-
Edge cases: if user already has permissions (previous collaborator), platform detects and issues a Snapcharge marking
isSuccess
true without creating a new provider invite.
Uhpenry's access model is designed to balance owner control, user entitlement, and verifiable auditability. By structuring access into clear categories Showcase for public visibility and Standard for gated, transactional delivery owners can decide exactly how their projects are consumed.
Every access event flows through a Snapgate and is sealed in a Snapcharge, ensuring that entitlements are atomic, reproducible, and independently verifiable. This not only protects owners from misuse but also guarantees that users know precisely what they received, when, and under what terms.
In practice, the model delivers:
- Transparency for users (what was purchased and delivered is frozen in history),
- Security & enforceability for owners (control over revocations and scope), and
- Consistency across delivery modes (Download vs Invite) through the same verification backbone.
In short, the Access Model is the contract of trust between owners and users codified, verifiable, and enforceable at scale.
Note: This guide is living documentation. We welcome contributions and corrections via GitHub or support@uhpenry.com.