The basic things.

Write a bead

A bead is one moment: a gallery afternoon, an album, a book finished at breakfast, a film, an encounter. It carries a kind, a time, a note, tags, a place, photos, links, and refs — what it is about. Provenance is fixed at the moment you save it and never changes afterwards; the content stays editable, and a correction is recorded as an edit.

In Loom

Open settings, point Loom at your String, check, then import — that pulls what is already there. Press + New bead and fill the one form: kind, when it happened, the note, tags, place, photos, links and refs. Save writes it to this browser; send takes it to the String.

On a phone

Open Pocket, choose a mask, press the button. Beads queue locally and flush to your String, or publish straight to your own repository if you signed in. If you scanned a venue’s QR on the way in, that night’s event is already attached.

From a totem

Press the button on the device; plug it in later. Loom holds the serial port, reads the dump, and resolves the totem’s elapsed-time counters into real instants — the device has no clock and no network by design.

On the command line

Kinds: bloc, visit, dwell, encounter, read, listen, watch, screening, performance, note. The list is advisory in the schema, so it can grow without breaking old records.

Tell a strand

A strand is the story of a day or an evening, and the unit you publish. It has a title, a day, a narrative of up to 10,000 characters, a place, links, refs — and the beads it strings together. The beads do not change when you add them; the strand points at them.

In Loom

Press + New strand. While it is open, every bead in the String column carries a tick box: ticking one puts it in the strand, in order. Ticking a proposal keeps it at the same time. Write the narrative beside the column, save, and send.

In the timeline

Load a day at :8101, select the beads you want and choose group into strands. The strand gets its own title, place and event link.

Refs are the part worth the effort. Naming the film, the book or the venue as a ref — subject for what the entry is about, mention for what it reaches for — is what lets two people writing about the same night ever find each other. The text itself is never rewritten: no wikilinks, no markup, just a small array beside it. See the shared defs.

Keep or release a proposal

Machines may suggest; only a person decides. The scrobbler clusters Last.fm plays into listening sessions and proposes one listen bead per session; those arrive with state: proposal and sit on a dotted rail. A proposal may be revised by a later run — a set that turned out to have more tracks in it — and a re-run will not erase edits you have made to it. The moment you keep one, it becomes a mint fact and no worker can touch it again. Release discards it.

Both buttons are in the String column in Loom, and on the dotted rail in the timeline. This is the whole contract: proposals are not facts.

Claim a work

A work claim tags a piece of work as yours. It lives in your own repository, and that is the claim. What it proves is narrow and honest — this claim was made on this date by the holder of this repository — not authorship, not ownership. That narrowness is the feature. Unattested is the normal state, not a deficient one: there are no verification badges and no completeness scores.

In Easel

Open Easel, sign in with your handle, fill in your profile once, then + New work: title, date, description, credits, links, external identifiers and images with alt text. Publish it to your repository. Easel tracks drift, so a work you have edited since publishing says so, and republishing updates the same record rather than making a second one.

On the command line

Layers reference; they never grow the core. Industry metadata, scene vocabularies and licensing terms belong in other namespaces pointing at a work’s URI, which is why the work record stays tiny. Registration with ISNI, ISWC and the rest is somebody else’s business — externalIds is the hook such a bridge writes back into.

Publish an event

A night is published as a shared record we do not own: community.lexicon.calendar.event, stewarded by Lexicon Community, so your programme reaches every calendar app that speaks it rather than only ours. Our venue.lineup is a thin layer over that event carrying what it does not — who is on, works shown — pinned to it by strongRef.

In Doors

Fill one form and it writes both records, publishes them under the venue’s own identity, and prints a QR code for the door and the poster. The QR opens Pocket with the event attached, so a bead about tonight is one tap for anyone who came.

On the command line

Then the audience half happens on its own: people who came publish beads referencing the event, and the venue counts public references. It collects nothing and stores nothing about a person — the evidence is published by the people who chose to publish it. An RSVP says I’m going; a bead pointing at the same event says I was here. Public references are countable; identities are not the venue’s to collect. Early on this is a handful of beads a night, which is a lovely record of an evening and useless as analytics — say so rather than dressing three references as a dashboard.

Publish a strand

Publishing is a deliberate act, per strand, never a default. The String holds your identities — use app passwords, never account passwords — and multiple identities are the point: personal strands publish as you, organisational strands as the org. Same desk, different letterhead.

The timeline has publish, republish and unpublish buttons per strand, with a confirm showing which identity will speak. What publishes: place names, notes, tags, links, kinds, times, and refs. What never leaves: geo coordinates, provenance, device identifiers, mint ids, local media, and any person named only by a name.

That strip is one rule with two implementations — Python in the String, JavaScript in the browser — held together by shared fixtures, so the two cannot quietly disagree about what leaves your machine. It fails closed: a field or a ref type it does not recognise is dropped rather than guessed at.

Put published records on a site

Everything published is readable by anything that speaks ATProto, including three readers of ours that need no hosting behind them.

The strand embed

A dependency-free web component. Point it at a handle and it reads that repository live; point it at a baked export and the markup is identical.

The wall and the catalogue

The wall is one person’s published cultureblocs, newest first, with a URL per strand: /wall/<handle>/ and /wall/<handle>/<rkey>. The catalogue is an artist’s published works — /catalogue/?actor=<handle>&template=grid, with index and feature as the other templates, or your own same-origin stylesheet via &css=. Both read the actor’s own PDS in the browser, so nothing of ours sits between a reader and the record.

A static export, with photos

Same privacy strip, plus media copied content-addressed.

Bring a born-public record home

A bead minted on a phone and published straight to your repository has no private original — it was born public. Bring it home to annotate it, attach photos and put it in a strand:

Imported records keep their public identity, so re-running imports nothing twice, and they remember their published twin: because the String reuses the original record key, re-publishing updates the public record in place rather than leaving an orphaned duplicate beside it.

Two things follow from being born public. There is no richer private version to fall back on — what you minted is what the world saw. And every later edit is a public amendment, visible in your repository’s history. That is honest, and worth knowing before you edit a note someone has already read.