How to share one thing without giving away everything

The person you need one answer from should not have to join your tool. What it takes to make a shared link safe enough to send — and why the grant widens access rather than filtering it.

You are waiting on one thing from one person. A subcontractor's certificate, a candidate's confirmation, one number from a client's finance team.

To chase that inside almost any collaboration tool, they have to join it. Create an account, accept an invite, occupy a seat, learn an interface, for one field. They will not, and they are right not to — so you go back to mail, and the tracking goes back into your memory, which is where this whole problem started.

The industry's answer to this is the guest seat, and a guest seat is still a seat. It has a licence cost, an offboarding task, and an access surface: the person you invited to see one certificate is now a member of something, and what they can see is whatever your permission model says rather than whatever you meant.

Sharing an item, not a workspace

We took the opposite approach. Zephyr is single-tenant and nobody joins your workspace, because there is no mechanism to join a workspace. Collaboration happens on one item: a share names exactly one action, exactly one email address, and one role.

The distinction that does the real work here is subtle and worth stating plainly. The share does not filter a broad permission down to one row. It widens a permission of nothing by exactly one row.

Those two produce identical behaviour when the code is correct, and wildly different behaviour when it is not. A filter that fails open shows somebody everything. A grant that fails open shows them nothing extra, because there is nothing else in the grant. Data minimisation as a property of the schema rather than a property of the code being careful — and there is no "share my workspace" grant in the database to write even by accident.

A link in an email is a credential in the post

Any share flow of this shape sends a credential over mail, which is the least trustworthy channel available. Four consequences follow, and each one of them is a decision we would have got wrong by default.

The link is hashed before it is stored. The token is generated on the device and only a digest of it is ever written down. A database dump is therefore not a set of working links — the same reasoning as storing password hashes, applied to something people rarely think of as a password.

A forwarded link is inert. Access is checked against the email address on the session the recipient actually signed in with, verified by the identity provider rather than claimed by the browser. Forwarding the mail to a colleague gives that colleague nothing at all, which is what "shared with one address" has to mean if it is to mean anything.

Every refusal says the same sentence. Helpful, specific errors — "this invite has expired", "this invite is for someone else" — are an oracle. They let a stranger with a guessed link learn whether it corresponds to something real. So all of them answer identically, and the cost is a slightly worse experience for the rare legitimate person who hits one.

A forgotten share closes itself. Access carries a 90-day expiry evaluated at the moment the data is read, not by a nightly job. A share you set up and forgot lapses on its own; a share you revoke stops working on the next query rather than at the next scheduled sweep. Both matter, and the second one matters most on the worst day.

Read-only, and why that is not a limitation

Today the person you share with can see the one action they were sent, and cannot edit it, complete it, comment on it or delete it — because there is deliberately no database policy that would let them. That is not a feature we have not got to. It is the same rule the AI follows, applied to people.

"Mark my side done" is obviously the next step, and when it arrives it will be a proposal that the owner confirms rather than a write. An outsider suggests; the owner decides. Zephyr proposes and you approve; a grantee proposes and you approve. It would be strange to hold a language model to that standard and not a stranger with a link.

The person you are chasing never becomes a user, never appears on an invoice, and never has anything to offboard. They get sent one thing, they answer it, and the access expires on its own. That is the entire feature, and most of the work in it was deciding what not to build.