VISIBLE BY DESIGN
Your browser can have a name without becoming a dossier.
A pseudonymous signing identity is generated in this browser. Its profile, traces and linked site identities remain local until you choose a concrete transfer.
Identity, profile and traces remain inside the browser storage boundary.
01 / WEBCRYPTO IDENTITY
A local key pair becomes the pseudonym.
The browser creates an ECDSA P-256 signing key. The private key is stored as a non-extractable CryptoKey in IndexedDB. The visible pseudonym is derived from a SHA-256 fingerprint of the public key.
That gives the local identity a useful property: it can later prove continuity by signing a challenge while keeping the private key inside browser storage. Web Crypto supports local key generation, signing and serializable CryptoKey storage in IndexedDB. Source: MDN Web Crypto API and structured-clone documentation.
02 / TRACE LEDGER
Your experience can leave useful traces that you can inspect.
Trace events describe interactions such as first engagement, opening the identity panel and using explanatory applets. Each event carries its own site origin and path. The ledger shown here is read directly from local browser storage.
Use the controls to add a demonstration trace, inspect the field, export a signed bundle or clear the local ledger.
03 / LOCAL PROFILE
Identity can accumulate meaning under your control.
The profile is an editable local object. A display name, languages, interests and contribution notes can enrich the experience across Transductive tools when you choose to carry or link that information.
Browser storage is origin-scoped. This page keeps its own local identity wallet, while other Transductive sites can present signed local identities for explicit linking. Web Storage and IndexedDB remain separate per origin, which makes the linking event visible rather than ambient. Source: MDN client-side storage documentation.
04 / EXPLICIT TRANSFER
Sharing becomes a visible transformation.
Page delivery passes through Cloudflare, which receives ordinary connection metadata needed to deliver the page. The application identity described here is generated locally. Application code stores profile and traces in browser storage and performs no application cookie operations.
The current v0.1 surface also carries a `connect-src 'none'` content policy, so its JavaScript can prepare and download signed bundles while network submission remains outside this release. A later network join action can name the endpoint, selected fields and resulting network role before transfer.
05 / LINKED SITE IDENTITIES
One person can carry several local pseudonyms and join them deliberately.
When this page is opened from a Transductive identity overlay, the source page can answer a fresh cryptographic challenge. Verification links that origin-local pseudonym into this local identity wallet. The link records the public key fingerprint and source origin.
06A / RESEARCH CONTRIBUTIONS
Your local pseudonym can sign a manual compute donation.
Transductive research projects can publish task-specific master guides and prompts. You run the task with your own frontier model, local model, archive access or simulation hardware, preserve the raw result, and submit the evidence packet for project review.
The first live project is the Transistor Origin Audit. Its task board treats archival finds, failed replications, model runs, corrections and anomaly dissolution as first-class research entities.
- Use the local ID shown at the top of this page.
- Choose a task and copy its master guide + run prompt.
- Run it unchanged first; preserve sources, artifacts and negative results.
- Paste your local ID into the submission so later contributions can share a pseudonymous author line.
Open the Transistor compute-donation task board →
06 / STORAGE CONTROL
Persistence is inspectable.
The Storage API can report whether this origin has persistent storage and can request persistence in secure contexts. The browser decides the result according to its own storage rules. Source: MDN StorageManager documentation.