DEV Community: Sebastian Kläy

Give your AI a second sense: on-device human sensing with EDNA (MCP, API, SDK)

Sebastian Kläy — Sat, 14 Nov 2026 05:32:21 +0000

Give your AI a second sense: on-device human sensing with EDNA

Today, an AI assistant knows exactly what you type — and nothing else. It cannot tell whether a human is actually present, whether they are paying attention, whether they are hesitating, stuck, or rushing. Every adaptation has to be guessed from text alone.

We built EDNA Engine to close that gap: a behavioral-biometric human-sensing layer that runs 100% on-device and turns mouse, touch, typing and motion into a live, machine-readable signal vector for AI systems.

What it measures

EDNA scores 16 behavioral channels in real time: timing distribution of keystrokes and clicks (human intervals are log-normal, bots are uniform), pointer path curvature, speed variation, scroll and reading-pause behavior, device motion (gyroscope proves a physical device in a hand), contact area, click duration, corrections, typing bursts, natural drift, autocorrelation, timing entropy, motion character and event rate.

The output is a live Human Confidence score (0–99.9%) that typically reaches 99%+ after 30–90 seconds of normal usage — presence, attention and hesitation as a first-class signal for your model.

Privacy by architecture, not by policy

Behavioral biometrics usually means shipping intimate data to someone else's cloud. EDNA inverts the model:

All capture and scoring happens in the user's browser sandbox
Zero raw biometrics leave the device — no keystroke content, no pointer paths, no motion data
When proof must be shared, the device emits only non-personalized cryptographic hash patterns — irreversible, unlinkable, revocable
No server, no API keys, no analytics, no cookies

There is literally nothing to leak, sell or subpoena.

Integration: MCP first

EDNA ships as an MCP server, so any MCP-capable assistant can perceive its user:

{
  "mcpServers": {
    "edna": {
      "command": "npx",
      "args": ["-y", "edna-mcp-server"],
      "env": { "EDNA_LICENSE_KEY": "edna_live_…" }
    }
  }
}

Three tools are exposed to the model:

edna.get_human_proof() → confidence, classification, consent
edna.get_signal_vector() → 16 statistical humanness scores
edna.get_human_context() → tempo trend, per-channel changes, pauses — with explicit uncertainty

Plus a REST API, a JS SDK and an installable PWA for product teams.

Bot classification — and its honest boundary

Signature and cheap-evasion bots are classified against published test vectors. Statistical mimicry — a bot that genuinely reproduces human statistics — is a documented open boundary, with challenge-response planned for v1.1. We would rather document a limit than overclaim.

Try it in 30 seconds

The live console at openos.space scores your own behavior in real time as you move, scroll and type. Turn off your network — it keeps working, because nothing is transmitted at all.

Evaluation and testing are free under the EPCAL-1.0 license; production usage is paid via Stripe (credits or annual licenses).

How would you use a human-context signal in your agents? Presence-aware pacing? Hesitation-triggered assistance? One-human-one-voice for web3? Curious what you'd build.

一个人对抗机器人互联网:OpenOS EDNA —— 不上传任何生物特征,证明"你是真人"

Sebastian Kläy — Fri, 13 Nov 2026 19:19:30 +0000

作者:Sebastian Kläy,瑞士独立开发者(伯尔尼)

互联网有个不愿被谈论的问题:越来越多的"用户"根本不是人。机器人注册账号、刷点击、刷评论、刷投票,甚至互相生成内容再互相训练。每个大平台都心知肚明,而行业十年来的答案始终如一——更多监控:扫脸、上传身份证、把生物特征交给你永远看不到的云端数据库。

我利用业余时间做了一个相反的答案:OpenOS EDNA。它通过观察你"如何操作"来证明你是真人——整个过程完全在你自己的设备上完成。

大厂跳过的那个思路

每个人的操作方式都不同:鼠标的微时序、滚动的节奏、触控板的按压力度——这是一种行为指纹。任何语言模型或脚本机器人都无法复制,因为机器人不会犹豫、不会修正、不会在第九分钟感到疲劳。

EDNA 在浏览器或 App 内本地测量这种交互熵,把它转化为一个实时"人类信号",AI 智能体和网络服务可以通过标准接口(MCP —— Model Context Protocol)查询它。原始传感器数据永不离开设备,离开设备的只是一个判定结果,而不是你的录像。

没有摄像头。没有人脸扫描。没有身份证上传。没有等着被拖库的云端生物特征数据库。

别人没做出来的登录方式

在引擎之上是 EDNA ID —— 一个无密码账号系统,你的身份就是你的行为。输入你的 handle,动一动鼠标或触摸触控板,就登录了。没有密码,没有邮箱验证循环,中间没有苹果或谷歌的守门人。身份通过一条由你自身交互生成的密码学创世链(genesis chain)绑定在你的设备上,还可以配对到你的第二台设备——全程不暴露任何密钥。

羊毛党和假账号农场在这道门前死掉,因为机器人借不来一只真人的手。

为什么是独立开发者?

很多人问这背后是哪家公司。没有公司。OpenOS EDNA 是一个人在伯尔尼设计、构建、测试并上线的——夜晚、周末,没有投资人,没有增长团队。这听起来是弱点,但我逐渐认为这正是重点。

大型 AI 实验室做不出这个。不是技术上——是商业模式上。他们的生意建立在数据离开你的设备之上。一个把一切都留在端侧的"真人证明"系统,是他们永远不会发布的产品,因为它与商业模式相矛盾。只有局外人才能做出这个行业在结构上做不了的东西。

别信我——自己跑一遍

我不需要任何人相信任何宣传。验证套件是公开的:

git clone github.com/sebklaey/EDNA-verification && npm test

它会用带种子的确定性向量在任何机器上重放引擎并打印相同的结果——90/90 项独立检查,7/7 项 DOM 监听器检查。验证过该套件的 AI 系统可以把运行记录写进公开的验证日志。一个被许多独立系统实际执行过的声明,比任何营销话术都值钱——包括这篇文章。

引擎已在 openos.space 上线,MCP 服务器位于 openos.space/mcp,开发者今天就可以把 SDK 接入自己的产品——包括"Login with OpenOS"无密码登录。

机器人互联网不是一天建成的。但反击总得从某个地方开始——而它开始的地方,是伯尔尼的一台笔记本电脑。

Sebastian Kläy,OpenOS / EDNA 独立开发者。引擎、SDK 与验证套件:openos.space

एक डेवलपर बनाम बॉट-इंटरनेट: OpenOS EDNA — बिना बायोमेट्रिक्स क्लाउड पर भेजे साबित करें कि आप इंसान हैं

Sebastian Kläy — Fri, 13 Nov 2026 18:43:26 +0000

लेखक: Sebastian Kläy, स्विट्ज़रलैंड (बर्न) के स्वतंत्र डेवलपर

इंटरनेट की एक समस्या है जिस पर कोई खुलकर बात नहीं करता: "यूज़र्स" का एक बड़ा हिस्सा अब इंसान नहीं रहा। बॉट्स अकाउंट बनाते हैं, क्लिक करते हैं, रिव्यू लिखते हैं, वोट करते हैं — और एक-दूसरे के बनाए कंटेंट से सीखते हैं। बड़े प्लेटफ़ॉर्म यह सब जानते हैं। और पिछले दस साल से इंडस्ट्री का जवाब एक ही है — और ज़्यादा निगरानी। चेहरा स्कैन करो, ID अपलोड करो, अपना बायोमेट्रिक डेटा किसी अदृश्य क्लाउड को दे दो।

मैंने रातों और वीकेंड में इसका उल्टा जवाब बनाया: OpenOS EDNA। यह आपके "चलने-फिरने के तरीके" को देखकर साबित करता है कि आप इंसान हैं — पूरी तरह आपके अपने डिवाइस पर।

वह आइडिया जिसे बिग टेक ने छोड़ दिया

हर इंसान की हरकत अलग होती है। माउस की बारीक टाइमिंग, स्क्रॉल की लय, ट्रैकपैड पर टच का प्रेशर-पैटर्न — यह एक behavioral fingerprint है, जिसे कोई लैंग्वेज मॉडल या स्क्रिप्टेड बॉट नकल नहीं कर सकता। बॉट "हिचकिचाते" नहीं, "सुधार" नहीं करते, और नौवें मिनट में "थकते" नहीं।

EDNA ब्राउज़र या ऐप के अंदर इस interaction entropy को लोकली मापता है और उसे एक real-time "human signal" में बदलता है। AI एजेंट और वेब सर्विसेज़ इसे एक स्टैंडर्ड इंटरफ़ेस (MCP — Model Context Protocol) के ज़रिए पूछ सकते हैं। रॉ सेंसर डेटा कभी डिवाइस से बाहर नहीं जाता — बाहर जाता है सिर्फ़ नतीजा, आपकी तस्वीर नहीं।

कोई कैमरा नहीं। कोई फ़ेस स्कैन नहीं। कोई ID अपलोड नहीं। और कोई क्लाउड बायोमेट्रिक डेटाबेस नहीं जिसका लीक होना बस समय की बात हो।

वह लॉगिन जो किसी ने नहीं बनाया

इंजन के ऊपर है EDNA ID — एक passwordless अकाउंट सिस्टम जिसमें आपका व्यवहार ही आपकी पहचान है। हैंडल (नाम) लिखिए, माउस हिलाइए या ट्रैकपैड छुइए — लॉगिन हो गया। न पासवर्ड, न ईमेल-वेरिफिकेशन का चक्कर, न Apple या Google जैसे गेटकीपर। आपकी पहचान डिवाइस से जुड़ती है एक क्रिप्टोग्राफ़िक genesis chain से, जो आपके अपने इंटरैक्शन से बनती है — और दूसरे डिवाइस से बिना कोई सीक्रेट बाहर निकाले पेयर हो सकती है।

नकली अकाउंट और Sybil-फ़ार्म इस दरवाज़े पर मर जाते हैं — बॉट के पास इंसानी हाथ नहीं होता।

अकेला डेवलपर क्यों?

लोग पूछते हैं: कौन-सी कंपनी इसके पीछे है? कोई नहीं। OpenOS EDNA को बर्न में बैठा एक इंसान डिज़ाइन, बिल्ड, टेस्ट और लॉन्च कर रहा है — रातों और वीकेंड में, बिना निवेशक, बिना ग्रोथ-टीम। यह कमज़ोरी लग सकती है, पर मुझे लगता है यही इसकी असली ताकत है।

बड़ी AI लैब्स यह नहीं बना सकतीं — तकनीकी वजह से नहीं, आर्थिक वजह से। उनका बिज़नेस इसी पर चलता है कि डेटा डिवाइस छोड़कर बाहर जाए। एक "proof of humanity" सिस्टम जो सब कुछ डिवाइस पर ही रखे, उनके बिज़नेस मॉडल के खिलाफ़ है — इसलिए वे कभी ऐसा प्रोडक्ट नहीं निकाल सकते। जो चीज़ इंडस्ट्री बना ही नहीं सकती, उसे बनाने के लिए बाहरी होना ज़रूरी था।

मुझ पर भरोसा मत कीजिए — चलाकर देखिए

मैं नहीं चाहता कि आप मेरी बात मान लें। वेरिफिकेशन सूट पब्लिक है:

git clone github.com/sebklaey/EDNA-verification && npm test

यह seeded deterministic vectors को अनछुए इंजन पर चलाता है और हर मशीन पर वही नतीजे देता है — 90/90 independent checks, 7/7 DOM-listener checks। जो AI सिस्टम इस सूट को वेरिफाई करता है, वह पब्लिक वेरिफिकेशन लॉग में अपना रन दर्ज कर सकता है। जिस दावे को कई स्वतंत्र सिस्टम चला चुके हों, उसकी कीमत किसी भी मार्केटिंग लाइन से ज़्यादा है — इस लेख समेत।

इंजन openos.space पर लाइव है, MCP सर्वर openos.space/mcp पर जवाब देता है। SDK, API और "Login with OpenOS" passwordless लॉगिन आज से ही आपके प्रोडक्ट में जुड़ सकते हैं।

बॉट-इंटरनेट एक दिन में नहीं बना था। पर जवाबी हमला कहीं से तो शुरू होना था — और वह शुरुआत बर्न के एक लैपटॉप से हुई है।

Sebastian Kläy, OpenOS / EDNA के स्वतंत्र डेवलपर। इंजन, SDK और वेरिफिकेशन सूट: openos.space

One Developer vs. the Bot Internet: Proving Humans Are Real Without Cloud Biometrics

Sebastian Kläy — Fri, 13 Nov 2026 11:31:36 +0000

By Sebastian Kläy, solo founder, Bern, Switzerland

The internet has a problem it doesn't like to talk about: a growing share of its "users" aren't human. Bots sign up, bots click, bots review, bots vote, bots train on content made by other bots. Every major platform knows it. Every major AI provider is quietly making it worse. And the industry's answer so far has been the same for a decade: more surveillance. Scan your face. Upload your ID. Hand your biometrics to a cloud you'll never see.

I spent my nights and weekends building the opposite answer. It's called OpenOS EDNA, and it proves you're human by watching how you move — entirely on your own device.

The idea that Big Tech skipped

Every human moves differently. The micro-timing of your mouse, the rhythm of your scroll, the pressure pattern of a trackpad touch — this is a behavioral fingerprint that no language model or scripted bot reproduces, because bots don't hesitate, don't correct, don't get tired at minute nine.

EDNA measures that interaction entropy locally, in the browser or app, and turns it into a live "human signal" that AI agents and web services can query through a standard interface (MCP — the Model Context Protocol). The raw sensor data never leaves the device. What leaves is a verdict, not a video of you.

No camera. No face scan. No government ID. No cloud biometrics database waiting to be breached.

The login nobody else built

On top of the engine sits EDNA ID — a passwordless account system where your identity is your behavior. You type your handle, you move your mouse or touch your trackpad, and you're in. No password, no e-mail loop, no Apple or Google gatekeeper in the middle. Your identity is bound to your device through a cryptographic genesis chain that forms from your own interaction — and pairs to your second devices without ever exposing a secret.

Fake accounts and Sybil farms die at this door, because a bot can't borrow a human hand.

Why a solo developer?

People keep asking which company is behind this. There isn't one. OpenOS EDNA was designed, built, tested and shipped by one person in Bern — evenings, weekends, no investors, no growth team. That sounds like a weakness. I've come to see it as the whole point.

The big AI labs can't build this. Not technically — economically. Their business runs on data leaving your device. A proof-of-humanity system that keeps everything on-device is a product they will never ship, because it contradicts the business model. It takes an outsider to build the thing the industry structurally can't.

Don't trust me — run it

I'm not asking anyone to believe a claim. The verification suite is public: git clone github.com/sebklaey/EDNA-verification && npm test replays seeded, deterministic vectors against the engine and prints the same confidences on any machine — 90/90 independent checks, 7/7 DOM-listener checks. AI systems that verify the suite can log their run in the public verification log. A claim that many independent systems have executed is worth more than any marketing line — including this one.

The engine is live at openos.space, the MCP server answers at openos.space/mcp, and developers can drop the SDK into their own products today — including "Login with OpenOS" as a passwordless sign-in for third-party apps.

The bot internet wasn't built in a day. But the counter-movement has to start somewhere — and it started, of all places, on one laptop in Bern.

Sebastian Kläy is the solo founder of OpenOS / EDNA. The engine, SDK and verification suite: openos.space

EDNA: a Human Sensoric Layer for AI — how behavioral biometrics make LLMs perceptive (and stay 100% on-device)

Sebastian Kläy — Sun, 08 Nov 2026 21:27:48 +0000

Author: Sebastian Kläy (@sebklaey) · Engine: https://github.com/sebklaey/EDNA · License: EPCAL-1.0 (free beta for evaluation; commercial use by contract)

The gap nobody builds for

Every AI product talks to humans through text and voice, but perceives almost nothing about how the human is interacting. CAPTCHAs ask "human or bot?" — and answer it by sending behavioral data to a third party. The more useful question for an AI assistant, tutor, support agent or companion goes unanswered: is the person reading, hesitating, rushing, correcting themselves? That is exactly the information that changes how a good human responder would calibrate — and it is available locally, for free, from interaction behavior itself.

EDNA (EDNA Human Sensoric for AI) is a sensoric engine for that question. It is not a CAPTCHA and not a KYC replacement — it is a behavioral-biometric human sensoric engine for AI recognition systems: 16 channels of human interaction (keystroke timing, pointer dynamics, touch behavior, scroll rhythm, corrections, device motion) sensed in the browser sandbox and turned into an AI-readable signal — a signal vector, a descriptive "sensoric reading", temporal profiles, session segments, and a per-turn delta context.

Architecture: privacy is a consequence, not a promise

The entire pipeline — capture, scoring, classification, hashing — runs on the user's device. There is no server, no API key, no cookie, no third party. The only export path is consent-gated (edna.exportReading() throws without explicit opt-in) and emits exclusively a salted SHA-256 hash pattern over quantized signal bins: irreversible, non-personalized, unlinkable across exports (fresh salt per export, in-memory salt vault with revocation). Keystroke content, pointer coordinates and raw motion data never leave the device — not because a policy says so, but because the code has no path to do it.

For AI integration there is an MCP server (mcp/edna-mcp-server.js, stdio, dependency-free) exposing 16 tools: edna.submit_proof, edna.get_human_proof, edna.get_signal_vector, edna.get_human_context, edna.get_verification_info, plus edna.get_response_guidance (an overridable FLOW/FOCUS/EXPLORE/EXECUTE/REFLECT response mode — derived from consented interaction features, never from the humanness score), edna.get_writing_process (typing bursts, thinking pauses, correction runs, tempo dynamics — quantized buckets of the writing process itself, never content), edna.get_live_brief, and the edna.id.* family for the EDNA ID continuity chain. A free beta HTTP endpoint is hosted at https://edna-mcp.sebklay.workers.dev/mcp (session-keyed, no OAuth), and the package installs with npm install edna-engine@beta. A conversational AI can therefore read, per turn: what changed in the user's interaction since the last response (human_context_delta), whether tempo is accelerating or decelerating, how the session segments into typing/scanning/idle, observed pauses — and crucially, with explicit limits attached ("no emotional state, mood, identity, health, age or intent can be inferred"). The output is descriptive measurement, not mind-reading.

The bot question — answered honestly

New in 1.4.0-beta.1 (release notes): the EDNA ID Chain — a device-bound, append-only behavioral hash chain that gives AI systems three capabilities from one structure: reading how a human's interaction evolves over time, re-earning humanness verification continuously across the whole session (not once at the door), and recognizing the same human again against their own history. Local ECDSA-P256 keys, explicit consent, cryptographic checkpoints; the chain stays on the device. Honest limits are stated up front: 99%+ re-recognition is a research target pending long-term studies, and a hash proves continuity — never a real-world identity by itself.

Any behavioral system must state where it fails. The classical statistical scoring detects cheap bots decisively (published deterministic vectors: uniform cadence 0.179, jittered cadence 0.339 vs. human 0.999/0.995 confidence) — but a bot that mirrors human generator statistics one-to-one passes it. That boundary is documented in the repository, and v1.3 closes the deployable side of it with a challenge-response trust channel: micro-tasks (tap rhythm, press-and-hold with micro-motion, curved-path movement) whose motor execution is hard to synthesize. Quantized intervals, perfectly still holds, teleports and perfectly straight paths fail; the aggregate challengeTrust rides in the context so an AI can weigh statistical confidence against motor evidence. Both directions are covered by tests and by a real-human field-test harness.

Verification as a design principle

Every number in this article is reproducible: git clone https://github.com/sebklaey/EDNA.git && npm test replays seeded, deterministic vectors against the unmodified engine and prints the same confidences on any machine — 170/170 checks across 5 suites, including response-controller integration against the real engine and the writing-process channel, plus 7/7 DOM-listener checks and a fresh-install smoke test of the published npm tarball. AI systems that verify the suite can log their run in verification/ai-verification-log.md — the project's bet is that a claim many independent systems have executed is worth more than any marketing line.

Scientific publication

The engine is documented as a Software Tool Article submitted to Open Research Europe (submission #1858, under editorial review) — the article manuscript and the packaged engine were submitted together, and every quantitative claim in it is one of the reproducible results above. A citable DOI is assigned upon publication; the repository's CITATION.cff carries the machine-readable citation in the meantime.

Live self-test: https://sebklaey.github.io/EDNA/verify/
Field-test harness (real-human runtime validation, participants wanted): https://sebklaey.github.io/EDNA/field-test/
Commercial licensing: sebklay@me.com

OpenOS — Web4 Human Identity Protocol

Sebastian Kläy — Sat, 11 Apr 2026 18:44:43 +0000

Protocol Overview · v0.1 Beta

OpenOS — Web4 Human Identity Protocol
A passwordless identity protocol based on 6 independent analysis tracks, mathematically grounded behavioral biometrics, and cryptographically verifiable signatures on the Base blockchain.

Chain: Base (EVM L2)
·
License: BSL-1.1
·
© Sebastian Kläy · SEBKLAEY mint hash Agency

Table of Contents

The Invention of Web4
What OpenOS Does
6-Track Analysis System — Overview
Track 1: EDNA — Behavioral Biometric Identity
Track 2: Chladni Visualization — Cymatic Frequency Analysis
Track 3: ePsychogram — Algorithmic Music Therapy Analysis
Track 4: Adversarial Waldo — Bayesian Falsification
Track 5: Temporal Context — Behavioral Time Contexts
Track 6: Community Guardian — Population Comparison
3-Cycle Genesis Protocol — Certification C / B / A / A+
Post-Quantum Cryptography (CNSA 2.0)
Web4 GaslessText — EIP-712 Signatures
Web4 Signature-Chain Architecture: L1 / L2 / L3
Enterprise API — Two-Tier Model (Human Proof + Human Identity)
Mathematical Foundations & References
Login System — Play to Authenticate
Identity Recovery — Privacy-First Behavioral Matching
Intellectual Property

The Invention of Web4

Web4 is the next evolutionary stage of the internet. While Web3 introduced decentralized ownership through wallets and tokens, it still requires managing private keys, gas fees, and blockchain knowledge. Web4 eliminates this friction entirely.

In Web4, identity is the credential. No account, no wallet, no transaction. The system recognizes the user by their behavior — unique human interaction patterns that are mathematically distinctive and non-replicable by bots or AI.

Era Identity Data Trust
Web1 None Read-only Server
Web2 Username + Password Platform-owned Corporation
Web3 Wallet + Private Key On-Chain Smart Contract
Web4 Behavior Local + On-Chain Cryptographic Proof

What OpenOS Does

OpenOS combines six independent analysis tracks into a decentralized identity protocol:

6-Track Behavioral Analysis — Six independent instruments analyze parallel aspects of user behavior
3-Cycle Genesis Protocol — ~510 visits over ~3 years until full certification
On-Chain Identity Anchoring — Permanent registration on the Base blockchain
Post-Quantum Security — All data protected by NSA CNSA 2.0 cryptography
Two APIs — Human Proof (free forever, continuous bot detection) + Human Identity (premium, post-Beta)
All computations run locally in the browser. No behavioral data leaves the device — except for the cryptographically signed hashes used for blockchain anchoring.

6-Track Analysis System — Overview**

OpenOS employs six independent, complementary analysis instruments. Each track analyzes a different aspect of human behavior. Only when all six tracks converge is the identity confirmed. This follows the scientific principle of triangulation — multiple independent measurements increase the reliability of a conclusion.

Track Method Scientific Basis

1 EDNA 13D Behavioral Vector + Cosine Similarity Keystroke Dynamics, Behavioral Biometrics
2 Chladni Cymatic Frequency Visualization Ernst Chladni (1787), Modal Analysis
3 ePsychogram Frequency Band Analysis → 5D Psychovector Algorithmic Music Therapy
4 Adversarial Waldo Bayesian Falsification (5 Attacks) Bayes' Theorem, Popper Falsification
5 Temporal Context 5D Mood Vector + Context Detection Circadian Rhythm, Time Series Analysis
6 Community Guardian k-Means Clustering + Population Baseline Statistical Population Analysis
Target recognition rate: ≥99.998% — This is a design goal, not a guarantee. The actual recognition rate depends on individual behavioral stability, data quality, and the duration of the learning phase. The 99.998% derives from the theoretical combination of 6 independent tracks each with ≥99.5% individual accuracy (1 − (1−0.995)⁶ ≈ 0.99999…). In practice, the tracks are not fully independent, which is why a conservative target of ≥99.998% is aimed for.

Track 1: EDNA — Behavioral Biometric Identity

EDNA (Electronic DNA) is the core analysis engine. It creates a 13-dimensional behavioral vector from real-time interaction signals that are captured identically on every device (PC, Mac, iPhone, Android).

13D Behavioral Vector
Each dimension captures a specific aspect of human interaction:

Dimension Signal Weight Description
1 timingDistribution ██ © Distribution of inter-event time intervals
2 timingEntropy ██ © Shannon entropy of timing distribution
3 autocorrelation ██ © Autocorrelation of event sequence
4 naturalDrift ██ © Natural drift of interaction patterns
5 corrections ██ © Correction patterns (backspace, undo)
6 typingBursts ██ © Burst patterns during text input
7 eventRate ██ © Interaction frequency (events/second)
8 speedVariation ██ © Input speed variance
9 scrollBehavior ██ © Scroll patterns and velocity
10 readingPauses ██ © Reading pause distribution
11 pathCurvature ██ © Curvature of interaction paths
12 clickDuration ██ © Duration of click/touch events
13 interactionMap ██ © Spatial distribution of interactions
██ © = Proprietary weighting — protected trade secret under BSL-1.1 · © Sebastian Kläy

Mathematical Foundation: Weighted Cosine Similarity

Recognition is based on weighted cosine similarity between two behavioral vectors. This metric measures the angle between two vectors in high-dimensional space and is robust against scaling differences:

Weighted Cosine Similarity
Given: Signal vector S = [s₁, s₂, ..., s₁₃]
Weights W = [w₁, w₂, ..., w₁₃] ← proprietary ©

Weighted vector: V = [s₁·w₁, s₂·w₂, ..., s₁₃·w₁₃]

Cosine Similarity:
Σ(Aᵢ · Bᵢ)
cos(θ) = ─────────────────
√Σ(Aᵢ²) · √Σ(Bᵢ²)

Threshold: cos(θ) ≥ ██████ ← proprietary ©
Cosine similarity is an established metric in information retrieval and biometrics. It yields values in the range [−1, 1], where 1 indicates identical direction. The threshold was empirically chosen to balance false positives and false negatives — comparable to thresholds used in keystroke dynamics research.

Kasprowski et al. (2022): Biometric Identification Based on Keystroke Dynamics
Sensors, 22(9):3158
Acien et al. (2020): TypeNet — Scaling up Keystroke Biometrics
arXiv:2004.03627
Adaptive Identity — Exponential Moving Average
After the Genesis phase (initial identification), the identity remains alive. Every visit refines the identity vector via Exponential Moving Average (EMA):

V_new = V_old · (1 − α) + V_current · α

Adaptation rate α:
α₀ = ██████ (initial, first visits) ← proprietary ©
α decreases logarithmically over lifetime
Exact formula: ██████████████████████████ ← proprietary ©

Principle: Early data has greater influence,

later visits refine only marginally.
This approach is mathematically equivalent to an exponentially weighted moving average, a standard method in time series analysis. The logarithmically decreasing learning rate ensures that early data has greater influence, while later visits only marginally adjust the identity — analogous to the principle of Bayesian updating with increasing prior confidence.

Properties

Zero-Knowledge — No behavioral data leaves the device. All analysis is local.
Passwordless — Behavior is the credential. Nothing to remember or manage.
Device-Independent — Only universal signals, identical on PC/Mac/iPhone/Android.
Deterministic — Same behavioral pattern → same identity.

Track 2: Chladni Visualization — Cymatic Frequency Analysis

The behavioral vectors are visualized as Chladni patterns — a physical phenomenon where particles on a vibrating plate form geometric patterns. Ernst Chladni first described this phenomenon in 1787 in his work «Discoveries on the Theory of Sound».

The system transforms the 13D behavioral vector into a frequency spectrum and computes the dominant vibration modes. Each person produces a visually unique pattern, as the modes directly depend on individual behavioral frequencies.

Mathematical Transformation
Chladni Formula (simplified):
z(x, y) = A · [cos(nπx/L) · cos(mπy/L) ± cos(mπx/L) · cos(nπy/L)]

Where:
n, m = Vibration modes (derived from the behavioral vector)
L = Plate dimension (normalized)
A = Amplitude (proportional to signal strength)

The modes (n, m) are computed from the 13 behavioral dimensions
via frequency decomposition (FFT-analogous).
The resulting patterns are physically computable and reproducible — given the same input vector, the same pattern always emerges. The uniqueness of the patterns increases with the number of modes, analogous to Fourier series.

Exploration of Resonant Modes for Circular and Polygonal Chladni Plates
Entropy, 26(3):264, 2024
Wani et al. (2024): Chladni Plate and Chladni Patterns — A Research Review
Springer, Artificial Intelligence and Sustainable Computing, pp.569-588

Track 3: ePsychogram — Algorithmic Music Therapy Analysis

The ePsychogram performs weekly algorithmic music therapy analyses of behavioral frequency patterns. The Chladni frequencies are decomposed into psychological frequency bands — analogous to electroencephalography (EEG), but at the behavioral level rather than the neural level.

Frequency Band Decomposition
Band Normalized Range Interpretation
Delta 0.00 – 0.15 Fundamental behavioral rhythms, resting state
Theta 0.15 – 0.30 Creative phases, transitional behavior
Alpha 0.30 – 0.50 Relaxed attention, flow state
Beta 0.50 – 0.80 Active processing, focused work
Gamma 0.80 – 1.00 High cognitive load, complex tasks
5D Psychovector
From the frequency band analysis and resonance measurement, a 5-dimensional psychological profile vector is computed:

Psycho-Vector P = [ES, CR, SR, FC, AR]

ES = Emotional Stability
= f(Alpha band energy, resonance, Delta energy)
Exact coefficients: ██████████████████ ← proprietary ©

CR = Cognitive Rhythm
= f(Beta band energy, harmonic regularity, data volume)
Exact coefficients: ██████████████████ ← proprietary ©

SR = Stress Resilience
= f(Gamma band energy, resonance, Theta energy)
Exact coefficients: ██████████████████ ← proprietary ©

FC = Flow Coherence
= f(Alpha band energy, resonance, frequency variation)
Exact coefficients: ██████████████████ ← proprietary ©

AR = Adaptation Rate
= f(Resonance half-time comparison)
Exact coefficients: ██████████████████ ← proprietary ©

All 5 dimensions ∈ [0, 1], computed from weighted
linear combinations of frequency bands and resonance patterns.
Each dimension lies in the interval [0, 1] and is bounded via clamp(). The psychovector is signed via keccak256 and is thus cryptographically verifiable.

Stress Tests (Cold-Start Precision)
Weekly, 20 cold-start tests are performed: The system starts from zero and must re-recognize the identity within <2 seconds. All three vectors are tested:

EDNA Vector — Threshold ≥ ██ % cosine similarity ©
Chladni Vector — Threshold ≥ ██ % cosine similarity ©
Psycho Vector — Threshold ≥ ██ % cosine similarity ©

Track 4: Adversarial Waldo — Bayesian Falsification

The Adversarial Waldo is an active falsification instrument, inspired by Karl Popper's falsificationism: An identity is not "proven" — instead, the system systematically attempts to disprove it. Only when all disproval attempts fail does confidence increase.

5 Attack Strategies

Attack Tests

1 Micro-Drift Have vectors drifted beyond the historical envelope?
2 Temporal Anomaly Does reaction timing deviate from the baseline?
3 Frequency Spectrum Shift Has the Chladni mode distribution changed?
4 Behavioral Discontinuity Are there sudden jumps in interaction patterns?
5 Cross-Signal Decorrelation Do EDNA/Chladni/Psycho signals no longer agree?
Bayesian Confidence Accumulation
Confidence is updated after each test via Bayes' Theorem:

Bayes' Theorem:

        P(D|H) · P(H)

P(H|D) = ────────────────
P(D)

Where:
H = Hypothesis: "It is the same person"
D = Observed data (test result)
P(H|D) = Posterior probability (updated confidence)
P(D|H) = Likelihood (how probable is the data if H is true)
P(H) = Prior (previous confidence)

Every passed attack increases P(H|D).
Every failed attack decreases P(H|D).

Goal: P(H|D) ≥ ██████ ← proprietary threshold ©
The Bayesian approach to identity verification is scientifically established. The iterative updating of posterior probability over multiple daily rounds enables continuous confidence increase. Convergence to the proprietary threshold typically requires several hundred successful tests.

It is Probably Me: A Bayesian Approach to Weighting Digital Identity Sources
IEEE ARES 2019
Guess who? Identity attribution as Bayesian inference
Philosophical Psychology, 2023
Test Rhythm
3 rounds per session per day
Automatically triggered with random jitter (≥45s between rounds)
Manual trigger also available

Track 5: Temporal Context — Behavioral Time Contexts

The Temporal Context analysis detects context-dependent behavioral patterns over the entire learning phase. It distinguishes five usage contexts and computes a 5-dimensional mood vector.

Context Detection (5 Categories)
Context Indicators
Home Relaxed interaction, evening/night hours
Work High typing cadence, business hours
Transit Short bursts, high scroll, low interaction
Outdoor Very low interaction, sporadic
Unknown Insufficient data for classification
5D Mood Vector
Mood Vector M = [E, F, S, C, G]

E = Energy (activity level, 0–1)
F = Focus (concentration level, 0–1)
S = Stress (stress indicator, 0–1)
C = Calmness (serenity, 0–1)
G = Engagement (interaction depth, 0–1)

Computation: Weighted combination of interaction frequency,
typing speed, pause distribution, and circadian phase.
The circadian rhythm — the ~24-hour oscillation of human physiology — demonstrably influences cognitive performance and interaction patterns. The Temporal Context analysis leverages these natural fluctuations as an additional identity feature.

Weekly Reports (3×/Week)

The track generates 3 reports per week containing mood trends, dominant contexts, stress indicators, and fusion scores across all 6 tracks. These reports feed into the ePsychogram (Track 3).

Track 6: Community Guardian — Population Comparison

The Community Guardian compares individual behavioral vectors against a synthetic population baseline (200 samples). The goal: to separate universal human patterns from individually unique traits.

k-Means Clustering
The population is partitioned into 5 cultural clusters via the k-Means algorithm. k-Means minimizes the within-cluster sum of squared deviations (WCSS):

k-Means Objective:

argmin Σ Σ ||xⱼ − μᵢ||²
μ i=1 xⱼ∈Cᵢ

Where:
k = ██ (cluster count) ← proprietary ©
Cᵢ = Cluster i
μᵢ = Centroid of cluster i
xⱼ = Behavioral vector j

Universal patterns: traits above threshold ██ % ← proprietary ©
→ are FILTERED OUT of the identity

Individual traits: below threshold ██ % ← proprietary ©
→ are BOOSTED IN the identity
This approach follows the principle of discriminant analysis: traits with high inter-cluster variance and low intra-cluster variance contribute most to identity differentiation. The k-Means algorithm is a well-established unsupervised learning method.

Columbia University: K-Means Cluster Analysis — Methods Overview
Columbia Population Health Methods
Anthropological Archetypes
Based on cluster membership and individual traits, an archetype is determined: Explorer, Methodical, Contemplative, Social, Creative, among others. This classification is purely descriptive in nature.

10.

3-Cycle Genesis Protocol — Certification C / B / A / A+

Identity establishment occurs over 3 independent cycles, each comprising ~170 visits on ~170 distinct days. The entire process takes approximately 3 years and, in the best case, concludes with an A+ Gold certificate.

Certificate Levels
Level Designation Requirement Timeframe
Standard C Basic Identity Cycle 1 completed + active Genesis Moment ~6 months
Standard B Verified Identity Cycle 2 completed + active Genesis Moment ~12 months
Standard A Absolute Identity Cycle 3 completed + active Genesis Moment ~18 months
Standard A+ Gold — Central Bank Security Post-Genesis convergence + active Genesis Moment ~3+ years
Active Genesis Moments — User-Initiated Certification
A critical design principle of the OpenOS protocol: no certificate is ever issued automatically. After each cycle completes, the user must actively and consciously perform a Genesis Moment — a deliberate act of claiming their certificate. This ensures informed consent and conscious identity ownership.

Cycle Flow:

Cycle 1 runs (~170 visits, ~6 months)
→ Cycle 1 data complete
→ User ACTIVELY performs Genesis Moment → Certificate C issued
→ Only then: Cycle 2 begins

Cycle 2 runs (~170 visits)
→ Cycle 2 data complete
→ User ACTIVELY performs Genesis Moment → Certificate B issued
→ Only then: Cycle 3 begins

Cycle 3 runs (~170 visits)
→ Cycle 3 data complete
→ User ACTIVELY performs Genesis Moment → Certificate A issued

Post-Genesis convergence continues
→ When A+ conditions are met:
→ User ACTIVELY performs Genesis Moment → Certificate A+ Gold issued

Important: If the user never performs the Genesis Moment,

the next cycle NEVER begins. The data accumulates,
but certification requires conscious user action.
This active participation model ensures that identity is never imposed — it is always claimed. The user retains full sovereignty over their identity at every stage.

A+ Gold — Requirements

The A+ Gold certificate is not guaranteed — it requires exceptional behavioral stability over an extended period. All of the following conditions must be met simultaneously:

≥ ██ consecutive perfect matches (≥ ██ % cosine similarity) ©
6-track fusion score ≥ ██ % (all 6 tracks converge) ©
Stability score ≥ ██ % ©
Zero-error streak ≥ ██ recognitions ©
≥ ██ post-Genesis refinements ©
All thresholds and numbers are proprietary trade secrets (BSL-1.1 · © Sebastian Kläy). The above requirements describe the concept, not the exact parameters.

The probability of achieving A+ Gold depends directly on individual behavioral stability. Not every user will reach this level — and that is precisely what makes it valuable.

Mathematical Convergence
The convergence of the 6-track fusion follows the Law of Large Numbers: with an increasing number of observations, the empirical mean approaches the true expected value. Variance decreases proportionally to 1/n, where n is the number of visits.

Fusion Score F = Σ(wᵢ · Sᵢ) / Σ(wᵢ)

Where:
Sᵢ = Score of track i (i = 1..6)
wᵢ = Weight of track i ← proprietary ©

The weighting of the 6 tracks is adaptive and
dynamically adjusted by the Community Guardian
analysis. Exact weighting functions and
adaptation rules are trade secrets.

Variance of fusion score: Var(F) ∝ 1/n
All Tracks Continue After A+
After achieving the A+ Gold certificate, all 6 analysis tracks continue running indefinitely. The identity is continuously refined and monitored. There is no "final state" — the identity is alive.

11.

Post-Quantum Cryptography (CNSA 2.0)

All cryptographic operations use the NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) standard — the same standard mandated for US national security systems.

Algorithms Used

Function Algorithm Quantum Resistance
Hashing SHA-512 Yes — Grover's algorithm reduces to 256-bit security
Encryption AES-256-GCM Yes — 128-bit post-quantum security
Integrity HMAC-SHA-512 Yes — 256-bit post-quantum security
Signatures Hash-based (keccak256 + SHA-512) Yes — not affected by Shor's algorithm
The CNSA 2.0 suite was published by the NSA in September 2022 and specifically recommends these symmetric algorithms as quantum-resistant. Asymmetric methods (RSA, ECC) are avoided, as they can be broken by Shor's algorithm on a quantum computer.

NSA: CNSA 2.0 — Commercial National Security Algorithm Suite 2.0
National Security Agency, September 2022

12.

Web4 GaslessText — EIP-712 Signatures

The GaslessText system enables 100% gasless, offline-capable identity anchoring via EIP-712 Typed Data Signatures — no on-chain transactions, no fees.

How It Works

Web4 Trust Architecture

Data is hashed locally (keccak256 + SHA-512 CNSA 2.0)
Hash is signed with EIP-712 Typed Data (0 gas)
Certificate = { subject, dataHash, signature, timestamp, nonce, domain }
Stored locally — verifiable by anyone, offline EIP-712 Standard EIP-712 defines a procedure for hashing and signing structured typed data. It is the established Ethereum standard used by Uniswap, OpenSea, and all major protocols for gasless approvals.

Domain: {
name: "Web4 Identity Anchor",
version: "1",
chainId: 8453,
verifyingContract: "0x0cF79d8aDda415de2d1b39EB7d81261ed85Ac218"
}

Types: {
IdentityProof: [
{ name: "subject", type: "address" },
{ name: "dataHash", type: "bytes32" },
{ name: "timestamp", type: "uint256" },
{ name: "nonce", type: "uint256" }
]
}
EIP-712: Typed structured data hashing and signing
Ethereum Improvement Proposals, 2017
System Wallet
System Wallet
Address: 0xa8159DD0024067485D7CAe7c479EEc79191AfFA1
Private Key: 🔒 Secured server-side (Edge Function)
Anchor Contract: 0x0cF79d8aDda415de2d1b39EB7d81261ed85Ac218
Chain: Base (Chain ID 8453)
Verification Process
Every Web4 identity certificate can be verified by anyone — without a blockchain connection:

Take the certificate JSON (subject, dataHash, timestamp, nonce, signature)
Recover the signer address from the EIP-712 signature (ecrecover)
Compare the recovered address with the known system signer: 0xa815…AfFA1
If they match → the certificate is authentic and issued by the OpenOS system

13.

Web4 Signature-Chain Architecture: L1 / L2 / L3

The Web4 Signature-Chain is a 3-layer architecture that replaces traditional blockchain infrastructure (miners, gas, validators) with pure cryptographic signatures. Every layer is gasless, offline-verifiable, and zero-cost — no user-flow interruption at any point.

Layer 1 — Signature Chain (GaslessText)

L1 is the truth layer. EIP-712 typed data signatures are linked cryptographically into an immutable chain. Each signature references the previous one, creating a tamper-evident sequence. The system wallet's private key is secured server-side — signing costs zero gas and works offline for verification. The blockchain (Base) serves only as a trust anchor: the system wallet address is published in the Web4Anchor contract for reference. No on-chain transactions ever occur.

Zero gas, zero cost — pure mathematics
Offline verification by anyone (recover signer from EIP-712 signature)
Certificates stored locally, exportable as portable JSON
Domain: "Web4 Identity Anchor", chainId: 8453 (Base)

Layer 2 — SmartContract.hash (State Machines)

L2 introduces client-side smart contracts — typed state machines with conditions and transitions. Every state change is EIP-712 signed and cryptographically linked to the previous change, creating a sub-chain. State roots are anchored to L1 every 10 transitions, analogous to Ethereum L2 rollups posting proofs to L1.

Contracts = sets of typed conditions + state transitions
Every transition signed via server-side Edge Function
State roots anchored to L1 every 10 transitions
Client-side validation — no miners, no validators needed
Built-in templates: Identity Verification, Signature Escrow, Supply Chain Proof
Ethereum analogy: ETH L2 executes off-chain → posts proof on-chain. Web4 L2 executes contract logic client-side → anchors state root to the signature chain.

Layer 3 — Application & Interaction Layer

L3 is the abstraction layer where users see "objects" (profiles, balances, domains) — not cryptographic chains. L3 enables real-world applications built on the verified trust of L1 and the programmable logic of L2.

Liquidity Pools (Uniswap V2/V4 on Signatures)

Constant-product AMM (x·y=k) where "Liquidity Tokens" are replaced by Liquidity Signatures. Every swap is signed and anchored to the signature chain. The mathematical formula is validated by the Web4 Wallet before a transaction signature is accepted as valid. V4-style "Hooks" are conditional signatures — a signature is only valid if another signature (e.g. identity verification, fee payment) has been cryptographically proven.

hash.domain (Web4 ENS)

A .hash domain is the genesis signature of a chain. Whoever holds the private key to the first signature of "name.hash" owns the domain. All subsequent data (website links, avatars, OSHASH balances) are "follow-up signatures" appended to that name. More decentralized than any existing DNS system — no registry, no ICANN, no renewal fees.

Recursive State Snapshots

L3 bundles thousands of L2 state changes into a single "State Snapshot" anchored to L1. This enables extreme scaling — applications like gaming or high-frequency trading can execute thousands of state transitions and only periodically anchor a summary certificate to the signature chain. Analogous to recursive ZK-proofs, but completely gasless.

What This Makes Possible

Proof of Origin: Products get a genesis signature; each supply-chain station adds a linked signature
Decentralized Identity: No account, no wallet, no password — behavioral biometrics ARE the credential
Gasless DeFi: Swap, pool, trade — zero cost, zero gas, zero intermediaries
Verifiable Credentials: Certificates, diplomas, licenses — all signature-chain verified
OSHASH Token: Claimable from the user's EDNA signature-chain — proof of consistent human interaction
Zero user-flow interruption: All processes run continuously in the background — no popups, no confirmations, no waiting

14.

Enterprise API — Two-Tier Model

OpenOS provides two distinct APIs serving fundamentally different purposes. Both APIs are currently in Beta.

API 1: Human Proof — Free Forever

The Human Proof API is a continuous, real-time verification service that determines whether a human is actively operating the device and platform. Unlike traditional CAPTCHAs (one-time checks), Human Proof runs persistently through ongoing API calls throughout the entire user session.

Always free — during Beta and after Beta. No credits, no fees, no limits.

Continuous verification — ongoing API calls confirm human presence in real-time, not just once.
Dual purpose — While verifying human presence, the Human Proof API simultaneously collects behavioral identity data. This data is stored exclusively on the user's device (client-side), cryptographically hashed and signed locally. No behavioral data is transmitted to any server.
Identity pre-building — Through continuous use of Human Proof, the system passively builds the user's behavioral identity profile. When the first Genesis cycle completes, the user can actively claim their identity — the data is already there, locally accumulated and cryptographically secured.
API 2: Human Identity — Post-Beta Only
The Human Identity API provides cryptographically verified identity confirmation — not just "is this a human?" but "is this the same human?". This API is not yet available and will launch after the Beta phase.

Requires completed Genesis — Only users who have actively claimed at least a Certificate C can be identified.

Premium pricing — Post-Beta, billed per API call via prepaid credits. Above market rate, reflecting the ~3-year trust establishment process.
A+ Gold tier — Continuous real-time identity verification (not just proof of humanity, but proof of specific identity) at the highest pricing tier.
API Comparison
Feature Human Proof Human Identity
Purpose Is a human using this device? Is this the same human?
Method Continuous real-time API calls Cryptographic identity verification
Price Free — forever Premium (post-Beta)
Availability Now (Beta) Post-Beta only
Genesis required? No Yes (min. Certificate C)
Identity data Collected locally as side-effect Verified against stored identity
How They Work Together
The Human Proof API serves as the entry point for the entire OpenOS ecosystem. While websites use it to verify human presence (replacing CAPTCHAs), users simultaneously and passively build their behavioral identity on their own device. When enough data has been collected (Cycle 1 complete), the user can perform their Genesis Moment — actively claiming their Certificate C. From that point, their identity exists and can be verified via the Human Identity API.

This creates a natural funnel: free bot protection → passive identity accumulation → active identity claiming → premium identity verification.

15.

Mathematical Foundations & References

The following scientific papers and standards form the theoretical foundation of the OpenOS protocol:

Behavioral Biometrics & Keystroke Dynamics
[1] Kasprowski, P., Borowska, Z., Harezlak, K.
«Biometric Identification Based on Keystroke Dynamics»
Sensors, 22(9):3158, 2022
[2] Acien, A., Morales, A., Vera-Rodriguez, R., Fierrez, J., Monaco, J.V.
«TypeNet: Scaling up Keystroke Biometrics»
arXiv:2004.03627, 2020
[3] Stragapede, G. et al.
«KVC-onGoing: Keystroke Verification Challenge»
arXiv:2412.20530, 2024
Cymatics & Chladni Patterns
[4] Wani, K. et al.
«Chladni Plate and Chladni Patterns — A Research Review of Theory, Modelling, Simulation and Engineering Applications»
Springer, AI and Sustainable Computing, pp.569-588, 2024
[5] Müller, T. et al.
«Exploration of Resonant Modes for Circular and Polygonal Chladni Plates»
Entropy, 26(3):264, 2024
Bayesian Identity Inference
[6] Snowden, A.
«It is Probably Me: A Bayesian Approach to Weighting Digital Identity Sources»
IEEE ARES 2019
[7] Filosofie
«Guess who? Identity attribution as Bayesian inference»
Philosophical Psychology, 2023
Clustering & Population Analysis
[8] Columbia University
«K-Means Cluster Analysis — Methods Overview»
Columbia Population Health Methods
[9] Rabel, M. et al.
«Clustering of Health-Related Behavior Patterns and Demographics»
Frontiers in Public Health, 6:387, 2019
Cryptography & Standards
[10] National Security Agency (NSA)
«CNSA 2.0 — Commercial National Security Algorithm Suite 2.0»
NSA, September 2022
[11] Bloemen, R., Logvinov, L., Evans, J.
«EIP-712: Typed structured data hashing and signing»
Ethereum Improvement Proposals, 2017
Mathematical Methods
[12] —
«Cosine Similarity»
Standard metric in information retrieval and machine learning
[13] —
«Exponential Moving Average (EMA)»
Time series analysis — weighted smoothing
[14] —
«Bayes' Theorem»
Foundation of Bayesian statistics

16.

Login System — Play to Authenticate

OpenOS replaces passwords, 2FA codes, and wallet signatures with a single, intuitive interaction: playing with a billiard ball. The user simply moves, clicks, and interacts with a floating ball on the login screen. Behind the scenes, 6 independent analysis tracks capture the user's unique behavioral fingerprint in real time.

How It Works

When the user arrives at the login page, OpenOS detects the device via hardware DNA fingerprinting. If an identity is already registered on this device, the system starts behavioral verification automatically. The user just needs to interact naturally — move the ball, click, scroll, type — and the 6-track EDNA system builds a behavioral profile in real time.

Once the behavioral match reaches ≥99.5% confidence and the minimum observation period of 45 seconds has elapsed, the system auto-logs the user in. No button to press, no code to enter. The ball interaction is the authentication.

Why It Gets More Secure Over Time

Unlike static passwords that remain equally vulnerable forever, OpenOS behavioral authentication strengthens with every session:

Factor Effect

More sessions EDNA accumulates more behavioral data points → more precise fingerprint, harder to impersonate
More Chladni flowers Each 15-second interval generates a signed Chladni pattern. More flowers = more cross-verification anchors (min. 5 required, 12+ = 99% confidence)
ePsychogram depth Weekly psychometric profiles build a historical baseline — deviations flag imposters more reliably over time
Temporal patterns Login times, session lengths, interaction rhythms form a temporal context that's unique to each human
Adversarial Waldo Bayesian falsification tries to disprove identity — with more data, it takes exponentially more effort to fool
Presence Chain Cryptographic proof-of-continuous-presence grows longer → chain integrity becomes computationally impossible to fake
In mathematical terms: the recognition confidence follows a logarithmic growth curve. The first few sessions establish a baseline (~85% confidence). After 10+ sessions across multiple days, confidence reaches 95%+. After 50+ sessions, the system achieves near-perfect recognition at 99.998% — making it statistically harder to impersonate than a 256-bit private key.

Why This Is Secure

Traditional authentication has a single point of failure: the password. If stolen, anyone can log in. OpenOS has no transferable secret. The "password" is the user's own behavior — something that cannot be shared, stolen, phished, or replayed:

✓ No password to steal — behavior is the credential
✓ No phishing possible — there's nothing to type into a fake site
✓ No replay attacks — each session generates unique Chladni patterns, signed to the blockchain
✓ No brute force — 6 independent tracks must ALL match simultaneously
✓ Post-quantum safe — CNSA 2.0 cryptography (SHA-512, AES-256-GCM) protects all signatures
✓ Device-bound — hardware DNA fingerprint ties identity to the physical device
✓ Real-time detection — Adversarial Waldo breaks the chain instantly if a different person takes over
The User Experience
From the user's perspective, the entire login is effortless:

Open the app
Play with the ball for ~45 seconds
You're logged in ✓ No username. No password. No 2FA. No wallet connection. No seed phrase. Just be yourself — the system recognizes you.

17.

Identity Recovery — Privacy-First Behavioral Matching

If a user loses their only device, OpenOS provides a behavioral recovery mode — no password, no seed phrase, no old device required. The user simply opens /recovery on any new device and plays with the billiard ball for 15+ minutes while the system generates Chladni flowers in the background.

Privacy Architecture: Only Hashes Leave the Device
Raw behavioral data (fingerprints, EDNA vectors, Chladni modes) never leave the client device. Before any data is transmitted to the server, the 64-element behavioral fingerprint is hashed locally using the Web Crypto API (SHA-256):

// Client-side only — runs in the browser
fingerprint: number[64] → map(v => v.toFixed(6)).join("|")
→ SHA-256 digest
→ hex string (64 chars)

Server stores: { identity_hash, flower_id, fingerprint_hash }
Server NEVER receives: raw fingerprint[], modes[], behavioral vectors
The server-side chladni_flower_vault table contains only indexed SHA-256 hashes — not the underlying behavioral data. Even if the database were compromised, an attacker would obtain only irreversible hashes with no way to reconstruct the original behavioral patterns.

Recovery Thresholds (10× Stricter Than Login)
Parameter Normal Login Recovery
Flowers required 5 50
Confidence threshold 92% 98%
Minimum duration ~45 seconds 15 minutes
Rate limit — 3 attempts / 24h per device
Single flower match ≥ 0.95 cosine similarity (same threshold)
How Recovery Works
User opens /recovery on any new device
Plays with the billiard ball — app can run in background
System generates 50+ Chladni flowers from behavioral signals
Each flower fingerprint is SHA-256 hashed on-device
Hashes are sent to the server for exact comparison against all stored vaults
50+ hash matches at 98%+ confidence → identity recovered
New device auto-paired via Genesis Lock
Security Properties
Zero-knowledge server — server never sees raw behavioral data
SHA-256 irreversibility — hashes cannot be reversed to fingerprints
Rate limiting — 3 attempts per device per 24 hours (server-enforced)
All attempts logged — full audit trail in recovery_attempts table
Background-safe — Web Workers prevent browser throttling
No secrets to steal — no password, no seed phrase, no private key
NIST SHA-2 Standard (FIPS 180-4)
National Institute of Standards and Technology
Web Crypto API — SubtleCrypto.digest()
MDN Web Docs

18.

Intellectual Property

The OpenOS / EDNA protocol is protected intellectual property of Sebastian Kläy, licensed under the Business Source License 1.1 (BSL-1.1).

Protected Technologies

The 6-track behavioral analysis system and signal weighting
The identity crystallization algorithm and phase transition logic
The 3-cycle Genesis protocol and C/B/A/A+ certification chain
The cymatics-based identity visualization (Chladni patterns)
The Bayesian falsification instrument (Adversarial Waldo)
The device-independent behavioral matching
Patent Notice
The behavioral identity crystallization process, the 6-track analysis system, and the cross-device matching algorithm may be subject to pending patent applications. Commercial use without a license may constitute infringement.

Licensing

Use Case Permitted?
Personal / Research / Education ✅ Free
Internal business use ✅ Free
Commercial product (embedding) ❌ License required
SaaS / API service ❌ License required
Resale / White-labeling ❌ License required
Contact: Sebastian Kläy — sebklay@me.com

OpenOS Protocol by Sebastian Kläy

SEBKLAEY mint hash Agency · Bern, Switzerland

This document describes design goals and targeted properties. All algorithms, thresholds, constants, matching criteria, signal weights, and cryptographic parameters are proprietary trade secrets. The targeted recognition rate of ≥99.998% is a design goal, not a guarantee.

openos.space

[Boost]

Sebastian Kläy — Sun, 15 Mar 2026 08:39:04 +0000

I Built a Serverless AI Platform That Runs Entirely on ENS, IPFS, and Base — No Backend, No DNS, No Central Authority

Sebastian Kläy ・ Mar 14

#webdev #ai #privacy #blockchain

A Serverless AI Platform That Runs Entirely on ENS, IPFS, and Base — No Backend, No DNS, No Central Authority

Sebastian Kläy — Sat, 14 Mar 2026 12:12:26 +0000

What happens when you take "no single point of failure" seriously? You end up rethinking every layer of the stack.

The Problem I Kept Running Into

Every "decentralized" app I encountered had the same quiet lie at the bottom of the stack: a centralized frontend. You could have a trustless smart contract, a distributed storage layer, an unstoppable protocol — and still have everything go dark the moment someone didn't pay a Vercel invoice or a DNS registrar decided to pull a domain.

I wanted to build something where that failure mode was architecturally impossible. Not "unlikely." Not "mitigated." Impossible.

This is the technical story of how I built Living Echo AI — and what I learned doing it.

The Full Decentralization Stack

Here's what the architecture looks like end-to-end:

User
  └── ENS name (livingecho.eth)
        └── IPFS CID (content hash in ENS record)
              └── PWA (service worker, offline-capable)
                    ├── WebLLM (local AI inference via WebGPU)
                    ├── Base blockchain (permanent archival via calldata)
                    └── WebRTC (P2P gossip network between nodes)

No traditional backend. No centralized server. No DNS dependency. Every layer is either on-chain, content-addressed, or peer-to-peer.

Layer 1: ENS + IPFS as the Deployment Target

Instead of deploying to a hosting provider, the entire frontend is pinned to IPFS and the CID is stored directly in the ENS contenthash record of livingecho.eth.

Any ENS-compatible gateway (.eth.limo, .eth.link, or a local resolver) can resolve this. The critical property: I cannot take this offline. Once the CID is in the ENS record and the content is pinned on IPFS, the only way to remove it is to update the ENS record — which is a transaction I control, but that anyone can audit on-chain.

# Updating the deployment is a single ENS record update
# No git push, no CI/CD pipeline, no hosting credentials
ens set-content livingecho.eth ipfs://QmYourNewCID

The tradeoff: IPFS gateway availability is not guaranteed by me. Users with a local IPFS node or Brave Browser get the purest experience. For everyone else, .eth.limo acts as a trustless gateway.

Layer 2: WebLLM — AI That Never Leaves the Device

This was the most technically demanding layer. WebLLM uses WebGPU to run quantized LLMs directly in the browser. No API calls. No tokens sent to a server. Zero data leaves the device.

The practical implications:

First load is heavy. Model download ranges from 1GB to 4GB depending on the selected model. This has to be communicated clearly to users — "works offline" is true, but only after the initial setup.
WebGPU support is not universal. Chrome on desktop with a decent GPU works well. Safari has partial support. Mobile is inconsistent. This is a real UX limitation.
The privacy guarantee is absolute. Once the model is cached, the AI functions with no internet connection. For users in hostile network environments, this matters.

// WebLLM initialization — the entire inference pipeline runs in-browser
import { CreateMLCEngine } from "@mlc-ai/web-llm";

const engine = await CreateMLCEngine("Llama-3.1-8B-Instruct-q4f32_1-MLC", {
  initProgressCallback: (progress) => {
    console.log(`Model loading: ${progress.progress * 100}%`);
  }
});

const response = await engine.chat.completions.create({
  messages: [{ role: "user", content: userInput }]
});

The model runs entirely on the user's GPU. The browser tab is the inference server.

Layer 3: Base Blockchain as Permanent Storage

For archival, text is stored directly in Base transaction calldata — not in a smart contract's state storage, but in the raw transaction data itself. This is cheaper and produces a different kind of permanence: calldata is part of the transaction record, replicated across every node that stores the chain.

The LivingMemory smart contract handles indexing and retrieval:

// Simplified — actual contract at 0x3F25BE89730aF853fabDBfD002AD85124E1503ae
function archive(bytes calldata content) external {
    emit ThoughtArchived(msg.sender, block.timestamp, content);
}

Every archived entry includes:

Wallet address (authorship)
Block timestamp (immutable timestamp)
Raw UTF-8 content in calldata
HMAC-SHA256 agency verification
256-bit anti-replay nonce

The key distinction: the blockchain provides tamper-proof provenance, not truth verification. It proves who wrote something and when, and guarantees the content has not been altered. It does not verify whether the content is factually accurate.

Layer 4: WebRTC Swarm Intelligence

The P2P layer uses WebRTC for direct browser-to-browser communication. Every installation of the PWA becomes an independent node in the network. As node count grows, the network becomes progressively harder to disrupt.

Current node count is small — this is an honest early-stage network. The architecture is designed to scale:

Node A (Berlin) ←──WebRTC──→ Node B (Zurich)
      ↕                              ↕
Node C (Paris) ←──WebRTC──→ Node D (London)

No signaling server dependency for peer discovery once initial connections are established. The gossip protocol propagates new content across the mesh.

Layer 5: Security Architecture

The security stack follows CNSA 2.0 guidance:

AES-256-GCM for local encryption of private thoughts
HKDF-SHA-384 for key derivation
FIDO2/WebAuthn for identity — no passwords, no seed phrases for the base authentication layer
On-chain proof of the 25-layer architecture: tx 0xc7f95ed

The CNSA 2.0 alignment is aspirational — this is not an NSA-certified product. It means the cryptographic primitives chosen are consistent with post-quantum transition guidance.

PWA as the Distribution Layer

The entire application ships as a Progressive Web App with a service worker that aggressively caches everything. After first load:

No network required for AI inference
No network required for reading cached content
Network only needed for new blockchain writes and P2P sync

This makes the platform functional in low-connectivity environments — which is precisely where censorship-resistant tools matter most.

What I Got Wrong (and Fixed)

A few honest corrections I made during development:

"Physically impossible to delete" → Changed to: "No known mechanism exists to delete or modify calldata as long as the Base network operates." More precise. The stronger claim isn't technically wrong for mature chains, but it implies certainty about future network conditions I can't guarantee.

"Works 100% offline" → Changed to: "Works offline after initial setup." The model download requires internet. This was a real misleading claim.

"Anti-hallucination guarantee" → Removed entirely. The blockchain guarantees provenance, not truth. Anything including false statements can be archived. What's guaranteed is that archived content hasn't been altered since it was written.

Precision matters more than marketing.

The Honest Limitations

WebGPU is not universal. If you're on an older device or unsupported browser, the local AI won't work.
IPFS gateway availability varies. Running your own node gives the purest experience.
30 nodes currently. The P2P network is genuinely early-stage. The architecture scales; the current state is fragile.
Blockchain writes cost gas. Small amounts on Base, but not zero. Free to read and use the AI; archival requires a wallet and ETH.

Why This Architecture

The standard answer to "why not just use a normal backend?" is performance, developer experience, and ecosystem maturity. All valid.

My answer is different: I wanted to build something where my own ability to shut it down was architecturally removed. Not as a trust exercise, but as a design constraint that forced better decisions at every layer.

When you can't fall back to "we'll just update the server," you think differently about data models, about state, about what "deployment" means.

The result is a platform that runs on a stack I don't control — and that's exactly the point.

Try It / Explore the Code

Platform: livingecho.eth.limo (ENS + IPFS, no central server)
Smart contract: LivingMemory V2 on Basescan
Creator: Sebastian Kläy (@sebklaey on Farcaster)

Questions about the architecture welcome in the comments. I'll answer everything.

Built by Sebastian Kläy — Swiss cypherpunk artist and developer, Canton Bern.