For the curious. For the builders.
Inside the
experiment.
Voice entry is interesting because it can recognize a returning profile even after a name or browser changes. The question is whether that can make throwaway accounts less useful.
One entry flow
- Consent and speak. Read a fresh, server-issued phrase for 15–30 seconds. The verifier checks the recording and its content.
- Find or create a profile. Compare against the active voice directory, including banned profiles. A clear match returns to an existing identity. A clear non-match can create a profile. Uncertainty asks for more speech, up to three attempts.
- Choose what to share. Continue as a guest or share an optional name. This choice preserves your site identity and moderation history.
- Open a session. The relying application receives a signed authorization and creates its own session. Voice is not checked on every message.
What this could do for a site
Recognized returns keep the same site identity. That gives a moderator continuity when display names change. False non-matches, altered voices, synthetic speech and template deletion limit how much continuity the matcher can provide. This is a complement to message moderation, rate limits and abuse handling.
A shared reputation network is a separate, optional experiment. It is not required for login and is not a universal blacklist.
Evidence, with the small print in normal-sized type
What we know so far.
The operator registered, returned in a private browser as the same profile, used hidden and shared names, and completed one extra-phrase retry. This is a working example, not a measured accuracy rate.
An iPhone recording reached speech recognition but failed the phrase check. Successful second-person and mobile entry are not yet established.
A synthetic voice enrolled and returned successfully in four recorded fresh-browser trials. Some altered speech also created duplicate profiles. The current demo does not establish human presence or deepfake resistance.
The recording display shows frequency levels from your microphone. It helps you see that sound is reaching the browser. It is not a human detector and does not decide whether you may enter.
Historical observations: September 7, 2026. Interface refreshed September 11, 2026. No population accuracy, bot-reduction rate or high-assurance authentication claim.
Where the voice goes
The server processes your recording and keeps an encrypted biometric template. Profiles expire after 180 days, with the active-ban exception below. Playable audio is not saved by default; saving it requires both operator enablement and your separate consent, for up to seven days. The spectrum is not separately stored or sent.
In this demo, one operator runs both the verifier and chat. In the hosted integration, each site receives a site-specific identifier and any name you explicitly share. The verifier can link your visits. Hiding a name is a presentation choice, not anonymity from the operator.
After entry, profile settings offer export and deletion using a fresh voice check. These controls use a browser-stored locator; losing it can make self-service management unavailable. Deletion removes the normal recognition template, names and saved recording. Site ban records may remain until their expiry. If the operator enables ban-template retention, an encrypted template for an active ban can remain after deletion or expiry until the ban expires or is reversed, solely to flag possible ban candidates for operator review. Voice similarity is not proof of identity.
Try it as a developer
The reference implementation uses Python/FastAPI, SQLite, Vosk speech recognition, TitaNet speaker embeddings and a small web component. Inference runs on the server’s CPU. There is no runtime LLM API and no blockchain.
The supported experiment starts from a source checkout; a standalone Python wheel is not a supported installation route. This alpha needs operator-managed models, keys, storage and limits.
Repository and source setup ↗ Repository access is currently required.