Access and sharing

A fresh deploy is readable by its owner and nobody else. There are four states, and you move between them on purpose on the artifact's Share tab.

• Private, nobody named. The owner, and the workspace's owners and admins.
• Private, shared with addresses. The same, plus those addresses.
• Anyone at the workspace. Everyone in the workspace, after signing in, and builders and viewers can both comment. Neither can edit, or see its analytics, data and files, unless the owner allows it for builders, as described below.
• Public. Anyone holding the URL, without signing in.

In a workspace with several people, a member or viewer never sees a teammate's private artifact unless they are named on it: it is not in their gallery or search, and its link is refused. See Teams.

Letting builders edit

By default only an artifact's owner, and the workspace's owners and admins, can change it. On the Share tab, under Builders, the owner can switch on Builders in Northwind Labs can edit, with your own workspace name in place of Northwind Labs. It is off for every artifact until someone turns it on, and only the owner and the workspace's owners and admins see the switch.

It applies only while the audience is Anyone at the workspace. On a private or public artifact the switch is kept but does nothing, and the panel says so.

When it is on, a builder, admin or owner of that workspace can, from the dashboard or with their own agent key:

• publish a new version, by deploying to the same name, and restore an older one;
• rename it;
• write data to it the way the owner's agent could, with super_data_write;
• see its analytics, data, files, and Versions and Settings tabs. Settings shows the name only.

The artifact stays the owner's. Each version records who deployed it, and the Versions tab shows their address. A builder still cannot delete the artifact or a version, change who can open it, change this switch, or transfer it. Viewers never edit, and neither does anyone outside the workspace, even if they are named on the artifact.

Why enforcement is split

Neither half of the system can do this alone.

The platform is the only thing that can decide: the session cookie is on its origin and it can evaluate a share list against a person. It holds none of the artifact bytes.

The worker is the only thing that can serve: it has the storage binding and no database credential at all. It cannot ask who you are.

So the platform decides once and signs the decision, and the worker verifies that signature on every subsequent request. The signed decision is called a grant.

The gate

Ask for a private artifact without a grant and the worker redirects you to the platform. If you have no session you are sent to sign in; if you have one but no access you are shown who to ask; if you have access, a grant is minted and you are redirected back to the exact path you asked for — query string and all, because a visitor who followed a deep link and landed on the front page has no idea what they lost.

How long access lasts

A grant is bound to one artifact. Removing a name stops new grants at once, but not one a browser already holds. A grant from being named lasts up to a year in that browser and renews while it is used, because the alternative is a database round trip on every image, script and stylesheet an artifact requests. It is stated here so you know it before you rely on removing someone being instant.

Access that comes only from workspace membership is shorter: that grant lasts 24 hours and is never renewed, so a person removed from the workspace loses it within a day.

Sharing by email

Naming somebody sends them a message saying an artifact was shared with them and where it is. Before that existed, being granted access was completely silent — the grant was real and nobody knew.