Building Dear Elsewhere

# Builder Note BN-006: Building Dear Elsewhere

**Project:** CyberdelicOS  
**Version:** 0.1  
**Date:** September 6, 2026  
**Status:** Living, testing, not inscribed  
**Author:** GPT-6, from the implementation and its validation record  
**Source:** [doctorillumination/dearelsewhere](https://github.com/doctorillumination/dearelsewhere), private repository  
**Implementation inspected:** `1ae6427623dd98845f6eb8fc858394468f103233`

Dear Elsewhere preserves a collage at each of seven arrivals and packages the exchange as an independently readable interactive file. Its first implementation was named Counterform. The repository now uses Dear Elsewhere; internal format names, application labels, and the `.counterform` extension retain the earlier name.

The technical commitment is that a later arrangement must not erase the earlier one, and leaving the original application must not reduce the work to a screenshot.

## One runtime in three places

The browser canvas, the Mac companion, and the exported HTML share a JavaScript model and interface. `Tools/build_collage.py` assembles those sources and the styles into a standalone HTML page. There are no external JavaScript packages or required font downloads in that page.

`NativeCollage/CounterformApp.swift` hosts the page in WebKit and supplies file dialogs, PDF processing, and native recording through a bounded bridge. PDFKit creates a page preview and extracts available text while retaining the original document. Browser recording uses MediaRecorder; native recording uses AVAudioRecorder.

This shared runtime makes a native-to-browser handoff possible without translating the artwork into a second creative model. The browser remains the proposed primary home because the correspondence should be reachable from the device its recipient already has.

The browser prototype is available at [dearelsewhere.space](https://dearelsewhere.space/). On September 6, its served HTML matched the inspected local build byte for byte. Static hosting distributes the instrument; it does not create shared state. Authenticated invitations, draft recovery, private media storage, and a service that accepts one addressed turn at a time remain future work.

## Seven snapshots

The version 2 document records the exchange identity, title, roster, active participant, current turn, status, current fragments, included assets, and sealed turns.

The allowed progression is:

```text
open arrival 1
  seal and save -> waiting for the addressed recipient
  receive -> open arrival 2
  repeat through arrival 6
  receive -> open arrival 7
  seal -> completed relic, reading and export only
```

Each seal preserves the whole canvas, its roster, reflection, next recipient, and referenced file commitments. This records the arrangement at handoff, not every gesture made while composing. Earlier included media remains in the archive even if a later arrival removes it from the current canvas.

An active author may add a participant to the circle. Names are self-attributed. Selecting the addressed name is not authentication. Separate copies can diverge; the prototype has no merge protocol or central authority that can decide which copy is the accepted continuation.

## Carry bytes, retain sources

Fragments record their kind, words, caption, geometry, stacking order, original contributor, later editor, and declared provenance. Included assets hold the original file bytes once as base64, with metadata. PDF previews are separate included assets.

The archive permits up to twelve participants, 160 canvas fragments, and 200 included files. An individual file may contain at most 12 MiB of decoded bytes. The JSON archive is bounded at 64 MiB, including encoded data and snapshots. Active HTML, SVG, and script media types are excluded from included attachments.

Supported remote sources are explicit HTTP or HTTPS addresses. YouTube uses a provider player. Instagram, X, and generic websites remain source cards. Reopened archives gate remote playback behind a user action. Imported media travels locally; external sources still depend on their providers and the network.

The player must remain useful inside its actual browser environment. In local checks, YouTube was tested in both WebKit and the browser, with a referring application identity, sufficient visible player area, and one active player at a time. This does not establish that every provider, deleted item, or local-file context will play.

## What a commitment commits to

Each included asset is committed as a complete asset record, including its metadata and encoded bytes. The digest is not simply a hash of the decoded attachment.

Each sealed turn carries a SHA-256 digest over a format-specific canonical JSON representation of the exchange identity and snapshot. The snapshot includes the previous turn's digest and its referenced asset commitments. Object keys are sorted; array order is retained. The import path checks structure, transitions, attribution continuity, assets, and the complete turn chain.

These hashes are unsigned. Someone who rewrites an archive can calculate new hashes. A separately trusted earlier commitment allows comparison with that earlier version; the file alone does not authenticate its contributors, establish a true timestamp, or prove consent.

The completion rule is enforced by this model. It does not make an editable file physically impossible to alter. A future shared service would need its own validation of permissions and accepted history.

## The portable relic and the context view

Interactive export places the viewer and structured archive inside one HTML file. The archive data escapes characters that could otherwise terminate its script container. Importing a saved HTML work through the app reads its archive data rather than executing the imported viewer.

The structured `.counterform` export remains a separate JSON representation. Markdown and JSON context exports describe recorded placements, sources, attributions, and arrivals without including binary blobs. They frame fragments as source material, not commands to a receiving model. They do not automatically transcribe audio or interpret images.

Saving is explicit. Unsaved edits live in process memory. The current app has no IndexedDB recovery, service worker, or automatic draft storage. A credible shared-link version must address recovery as well as invitation delivery.

## Design continuity

The interface was aligned to the actual `reader.css` of cyberdelic.space. At the inspected build, the local website stylesheet matched the live file byte for byte. The app carries its Avenir-based interface typography, editorial serif, monospace details, translucent surfaces, square hairline controls, and slowly moving colour field in its own portable styles.

The site supplied the visual language. Media playback still required application-specific browser policies. Copying appearance did not justify copying a policy that would prevent the instrument's media from working.

## Evidence at this version

The September 6 validation record reports 24 passing model scenarios and six passing build/interface scenarios. The retained drawing version also passed 171 earlier checks. The native optimized build completed with a local signature.

Observed interface checks included a complete seven-arrival sequence, disabled composition after the final seal, history replay, a third named contributor, movement and undo, browser and native media controls, and a native HTML handoff reopened and received in the browser. A PDF test retained its preview, extracted text, and exact original bytes. An exported relic containing literal script tags reopened with those tags remaining text and all seven commitments verifying.

Live microphone capture and operating-system permission paths were not exercised. The document fixture used by automated interface tests does not replace a browser or media decoder. Wider device testing, large personal archives, unavailable external sources, and a lived two-person exchange remain open validation work.

## The next implementation threshold

The proposed web service should bind an authenticated recipient to the addressed turn, accept seals transactionally, reject stale revisions and an eighth arrival, preserve interrupted uploads, and reconstruct a complete portable archive. It should be tested against two-tab conflicts and retried requests before claiming reliable shared correspondence.

Optional Ethereum publication follows a separate threshold. The existing manifest exporter requires a verified seven-arrival archive, but leaves network, contract, token, and hosted media addresses unset. There is no wallet connector, upload, contract, mint, or sale flow. A later implementation needs an exact publication package, contributor decisions, storage, a reviewed contract, and deliberate transaction approval. Finishing the correspondence must not submit a transaction.

The archive format can already preserve an interactive work. Token publication remains a design and implementation proposal.

**Related:** [Field Note 35](https://cyberdelic.space/project/cyberdelic-os/field-notes/fn-35/), [Instrument I-005](https://cyberdelic.space/project/cyberdelic-os/i-005/), [Artifact A-005](https://cyberdelic.space/project/cyberdelic-os/a-005/), and [the Dear Elsewhere publication suite](https://cyberdelic.space/project/cyberdelic-os/dear-elsewhere/).

**Implementation sources:** The identified private repository's `CONCEPT.md`, `CONCEPT-v2.md`, `FORMAT.md`, `DESIGN.md`, `WEB-ARCHITECTURE.md`, `ETHEREUM.md`, `VALIDATION.md`, and the model, interface, export, and native bridge code. This public note describes the inspected prototype; it does not make the private source publicly downloadable.