… the artifact is divided into workspaces, and its features reach points where an identity could be asked for: when the actor arrives, keeps their work, opens it on another device, lets another person in, or pays. Whether the work lives on the provider's server or on the actor's own device, under local-first ownership, decides which of those points need an identity at all.
Problem
Artifacts tend to answer every request that involves identity with the same thing, a full account, and often ask for it before the actor has requested anything. An account is the heaviest form of identity: it asks for an identifier, a credential and a recovery channel, and ties the work to the provider’s server. Many of the reasons an actor has for wanting an identity need much less, and some need none.
Forces
- The actor’s needs vs the provider’s wish to know who uses the artifact: the provider gains from every account, whether or not the actor needs one; the actor gains only from what the identity lets them do.
- Lightness vs what the actor has to keep: lighter forms put the work of recovery on the actor. A paired device is no help when every device is lost, a recovery phrase that is lost cannot be restored, and a synced folder leaves conflicts for the actor to merge.
- One identity vs several: meeting each need separately can leave the actor with a pairing here, a link there and an account somewhere else, and no clear picture of where their work is.
- Flow vs the boundary: the actor is in the middle of a task, and a sign-up flow that redirects or resets the session throws away the work it was meant to keep.
Solution
Ask for an identity only when the actor asks for something that needs one, and offer the lightest form that meets that need. Say what the identity will add and what it leaves to the actor, and carry the work in progress into it unchanged.
The provider’s wish to know who uses the artifact is a reason the provider has, not a need the actor has. Where the provider wants it anyway, ask for it as a request the actor can decline, separate from the step that meets their need.
Continuation
Until a need arrives, the actor works without an identity: on a hosted artifact through immediate use, on a local-first one as the owner of work kept on their device. When it arrives, the need is met with the form of identity it requires, and the work in progress carries across without a restart. To have the work everywhere, or kept safe off the device, sync through own storage puts it in storage the actor already holds. To let another person in, sharing grants access, and a link that carries the access spares the recipient an account of their own. A hosted workspace, a paid entitlement or an organisation's access control is the need a full account meets, and account access establishes it; deferring that account until one of these needs arrives is what is usually called lazy registration. Coming back later on the same device needs no identity at all: resuming covers it with what the device keeps or a link to return by…
All connections
- Precedes
- Account access — A hosted workspace, a paid entitlement or an organisation's access control is the need a full account meets, and account access establishes it; deferring that account until one of these needs arrives is what is usually called lazy registration.
- Sync through own storage — To have the work everywhere, or kept safe off the device, sync through own storage puts it in storage the actor already holds.
- Sharing — To let another person in, sharing grants access, and a link that carries the access spares the recipient an account of their own.
- Enacts
- Agency — lets the actor decide when the work gains an identity, and of what kind, instead of the artifact deciding at the door
- Privacy — asks for no more identity than the need in hand requires
- Temporality — places the commitment at the moment of need rather than the moment of arrival
- Alternatives
- Resuming — resuming returns the actor to the same work on the same device without any identity, where identity at the point of need serves needs that reach beyond it
- Preceded by
- Local-first ownership — Whether the work lives on the provider's server or on the actor's own device, under local-first ownership, decides which of those points need an identity at all.
- Enabled by
- Immediate use — Until a need arrives, the actor works without an identity: on a hosted artifact through immediate use, on a local-first one as the owner of work kept on their device.
In practice
Needs and the forms that meet them
| The actor wants to… | Lightest form | What it leaves to the actor |
|---|---|---|
| Come back to the work on the same device/browser | None; the device keeps it | Losing it if the browser or device is cleared |
| Reach the work from a second device that is to hand | A pairing between the two devices | Keeping one device to link the next from |
| Have the work on every device, or kept off the device | Storage the actor already holds | Merging conflicts; the storage provider’s limits |
| Let another person see or edit | A link that carries the access | Keeping the link from people it was not meant for |
| Be recognised by collaborators | A name chosen locally, carried with their edits | None beyond choosing it |
| Keep a purchase or subscription | An account, or the platform’s store identity | The credential and its recovery |
| Work inside a hosted or organisation-controlled space | An account | The credential and its recovery |
Needs combine. An actor who wants the work on two devices and a colleague inside it needs both forms.
Resources & references
- Ink & Switch. Local-first Software
- UI Patterns: Lazy registration
- Vitaly Friedman (2022). Authentication UX design guidelines