Skip to main content

​
Sharing & Access Control

Every artifact and folder lives in exactly one of two homes, and each home has one access rule. Content is never in both homes. Adopting standalone content into a workspace removes its team shares; from then on only workspace membership decides access.

​
Workspace content

Team shares never apply to workspace content. Members get in through workspace membership with an audience that covers the item:
  • Internal members (the owner and the owning team’s members) see internal and shared items.
  • Guests (everyone added or invited to the workspace) see shared items only.
To share workspace content with people who work on it, invite them by email as guests and share the items they need, or add them to the owning team, where each member is billed, to give them everything. Attempts to team-share workspace content are refused with WORKSPACE_AUTHORITY. See Workspaces.

​
Public access to one file

To send one file to someone with no account, an internal editor makes it public:
A workspace file’s visibility is private (members only, the default for every new, adopted or forked file) or link. It is never public (400 INVALID_VISIBILITY). Set it with PATCH /v0/artifacts/:id { visibility }, the MCP tools artifact_patch and artifact_share_policy, or the Public choice on the dashboard’s audience chip. Publish first, then patch: workspace creation still omits visibility. Public access sits one step past the members:
  • link on an internal file also makes it shared.
  • --audience internal turns public access off. Asking for internal and link together is refused with 400 INVALID_VISIBILITY.
  • A change of visibility alone needs no why; a why you send is recorded. The workspace history reads “Gave public access to” or “Removed public access to”.
Anyone with the URL reads the file through direct reads only: its metadata, content, the /s/ page (HTML, markdown and JSON), its versions, diffs, table rows, and the MCP reads. Earlier versions are readable too, so prune them first (rip artifact prune-versions <id>) if they shouldn’t be. Outsiders never find the file through listings, search, sitemaps or the public listing, and never see its workspace, folder or audience. A file in the trash, or in a deleted folder or workspace, answers them 403. An outsider who forks a public file gets a standalone copy in their own account; the workspace is untouched.

​
Standalone content

​
Team shares

Share an existing artifact with a team you belong to:
Or set the team at publish time with rip artifact publish --team <slug>, or file the artifact into a team folder. Every member of a team it is shared to can read it and gets collaborator rights: new versions, metadata edits, moves, visibility changes, fork, and sharing to other teams they belong to. Deleting the artifact and deleting a version stay owner-only.

​
Visibility

Every standalone artifact carries a visibility field that controls anonymous read access: Set visibility at publish time (--visibility on rip artifact publish, visibility on POST /v0/artifacts) or change it later (rip artifact patch <id> --visibility private, PATCH /v0/artifacts/:id, or the MCP tool artifact_share_policy). Visibility grants read access only. Publishing a new version always needs an authenticated caller who can change the artifact: the owner or a member of a team it is shared to.

​
Reading artifacts

Read endpoints accept optional authentication:
  • GET /v0/artifacts/:id — Metadata
  • GET /v0/artifacts/:id/content — Raw content
  • GET /v0/artifacts/:id/versions — Version history
  • GET /v0/versions/:vid/content — Specific version content

​
Access model summary