webË · specification
webË: a new network, alongside the internet
- 6: Layers, from transport to clients66
- 5: Mix network hops for every message55
- 2 s: Stealth tick: one steady burst, sent or not22s
- 0: DNS lookups or certificate authorities for names00
An open protocol for names, sites, feeds, forums and live media over a post-quantum stealth network.
Nodes only relay, cache and count; encoding, encryption, ranking, moderation and rendering happen on devices. khėnsu.ñü is the first webË app. Anyone can build another.
specification
| Layer | What it does |
|---|---|
| Transport | Outfox mix network with ML-KEM-1024, constant stealth ticks, two-relay MOQ paths over padded trunks, all carried as ordinary HTTPS |
| Names | name.khensu.nu, any NFC string, resolved from the key transparency log through private lookups, never from DNS or certificate authorities. Æ and æ are different names. Character rules |
| Objects | Content-addressed chunks, signed site manifests and roots, erasure-coded across operators |
| Fetch and publish | Two-relay stealth fetch; publishing through the ticks or the owner’s node, never as a visible burst |
| Applications | Sites, feeds, forums, labels and live tracks |
| Clients | The khėnsu.ñü app’s viewer for webe://, a Chromium extension, then a Chromium patch |
The full documents, in khensu-specs:
| Document | Covers | Status |
|---|---|---|
WEBE.md | Names, objects, fetch, publish, sites, feeds, forums, labels, clients | Draft 0.1 |
PROTOCOL.md | Wire formats, MLS suite, mix packets, stealth ticks, calls | Draft |
THREAT-MODEL.md | Who we defend against and what remains | Draft |
design/nu-media.md | Images, video and HDR in minimal wire bits | Design |
Five Internet-Drafts are planned from these: Outfox with ML-KEM-1024, a stealth profile for MOQ, naming from a transparency log, signed content-addressed sites and feeds over MOQ, and two-relay stealth fetch. Each document above is public; select its name to read it here.
how webË replaces a VPN
A VPN hides your traffic from your internet provider by handing all of it to one company instead. webË splits that trust so no single party ever holds it.
| Typical VPN | webË | |
|---|---|---|
| Who sees your IP and what you open | The VPN company sees both | Nobody: the entry relay knows who, the exit relay or cache knows what, run by different operators, networks and jurisdictions |
| Messages | One tunnel; the VPN sees when you talk to which service | Mix network: five hops with cover traffic, so no relay or outside observer can link sender and receiver |
| Recognisable on the wire | WireGuard, OpenVPN and IPsec are easy to fingerprint and block | Ordinary HTTPS (WebTransport over QUIC, falling back to TCP) |
| Timing and volume | Visible: bursts show when you’re active | Constant bursts every 2 s while the app is open, padded packets, size-bucketed responses; suñůlink.shield and nodes keep the cover going around the clock |
| Logs | A policy you have to trust | Nothing to log: no relay sees content or both ends |
| Encryption | Mostly classical key exchange; some offer hybrid post-quantum | ML-KEM-1024 and ML-DSA-87 only, with no classical fallback |
| Off switch | Can drop, leak or be turned off; needs a kill switch | No unprotected mode exists |
| Who runs it | One company, one subscription | Independent operators paid by the protocol for proven work |
today: everything on webË
Messages, calls, payments, feeds, forums, sites and live streams all travel this way, in the khėnsu.ñü app and in any webË app built on khensu-core. No VPN is needed for any of them, and a VPN would add nothing.
planned: webË exit, for the rest of the internet
- On the device: a Network Extension packet tunnel on iPhone, iPad and Mac sends all the device’s traffic into webË, so ordinary apps and websites are covered too. It is part of the khėnsu.ñü app, with no separate VPN account.
- Two relays: each connection goes through an entry relay and an exit relay from different operators, the same split as webË fetches. The exit relay opens the connection to the website; HTTPS to the website stays end to end, so the exit sees only the site’s name and traffic size.
- Stealth stays on: the tunnel looks like ordinary HTTPS and uses padded trunks and size buckets. Bulk browsing can’t fit inside the 2-second ticks, so timing cover for the open web is weaker than for messages; we will say so in the app.
- Exit operators: exit duty is opt-in, needs extra stake, and runs only where the operator chooses, because exit relays receive abuse complaints for other people’s traffic, as Tor exits do.
- DNS: resolved at the exit relay inside the tunnel, never by your internet provider.
- Nothing processed on servers: relays only forward. There is no filtering, ad blocking or inspection at the exit.
build an app on webË
- Sites: a site is a signed manifest plus static files and optional WebAssembly, published at
your-name.khensu.nuand hosted by the network. There is no server-side code. A site can embed feeds, forums and live tracks by reference. - Apps:
khensu-core(Apache-2.0, Rust) gives you the transport, MLS groups, names and objects, with Swift bindings as an XCFramework for iPhone, iPad and Mac. Your app gets the same stealth and post-quantum encryption as khėnsu.ñü, with no extra work. - Browsers: the Chromium extension resolves
webe://andhttps://*.khensu.nuthrough a local daemon, so webË pages open in an ordinary browser. - Develop locally:
khensu-devnetruns a node, the mix network, the chain and the push gateway on one machine.
Every webË app keeps the same rules, enforced by the protocol and by review:
- Stealth can’t be turned off, and there is no faster visible mode.
- Nothing processes user data on a server; nodes only relay, cache and count.
- ML-KEM-1024 and ML-DSA-87 only, with no classical fallback.
- Content is signed by its publisher and addressed by its hash, so no node can alter it.
- Sites can’t reach the ordinary web or other names unless their policy lists them, which blocks third-party tracking by construction.
post-quantum web contracts (proposed)
A webË contract is an agreement between people that enforces itself, without a server and without a public record of who agreed to what. It is a design proposal, open for review in WEBE.md section 14.
- The code: a small, deterministic WebAssembly program, signed by its author with ML-DSA-87 and addressed by its hash, published like a site. Anyone can read what it will do before agreeing.
- Runs on the parties’ devices: each step runs on the phones and Macs of the people in the contract, never on nodes. Inputs such as amounts, delivery proofs and messages stay private to the parties.
- Proved, not replayed: each step produces a STARK proof (hash-based, so post-quantum) that the program ran correctly on the committed state. The chain stores only the proof, a commitment to the new state and any shielded-pool notes, never the inputs.
- Settled privately: money moves through the shielded pool with ML-KEM-1024 note encryption, and every message between parties goes over the mixnet, so not even the operators can see who has a contract with whom.
- Expires with the era: contract state follows the pool’s eras, so nothing sits on the chain forever.
what you can build with contracts
- Escrow and milestones: a client locks payment; each milestone releases when both sides sign, or when an arbiter they chose decides.
- Threshold pledges: “I’ll pay if 1,000 others do.” Pledges stay hidden and unlinkable until the threshold is met, then settle together, or refund on the deadline.
- Revenue splits: collaborators on a post, song or film are paid their shares automatically from every payment it earns.
- Tickets and memberships: anonymous credentials that prove you paid, without showing who you are or linking one visit to the next.
- Bounties: a reward paid to whoever first submits something that passes the contract’s check, such as a bug proof or a translation.
- Time-locked releases: a file, key or message that opens on a date, or if you stop checking in.
By design there is no global shared state that any contract can read, so there is no public order book, no front-running and nothing for a quantum computer to break later. Contracts that need public state use a forum or feed as their record.
deeper work for the network (proposed)
Nodes earn work receipts for more than relaying. Every job below touches only ciphertext or data its owner chose to publish. User data is still never processed on a server.
- Proof aggregation: nodes with spare CPU fold each block’s spend and contract proofs into one recursive STARK, so phones verify one small proof instead of thousands.
- Encrypted storage: erasure-coded shards of sites, media and backups, held as ciphertext and checked with storage proofs, paid per byte-day.
- Public media renditions: Macs and GPUs encode ñü.media versions of posts their owners published openly. Private media is always encoded on the sender’s device.
- Private lookups: private information retrieval for names, keys and directories, so a node answers a query without learning what was asked.
- Randomness and timestamps: a threshold randomness beacon for committee lotteries, raffles and fair ordering, and post-quantum timestamps that prove a hash existed at a given time.
- Mesh and satellite bridging: nodes and suñůlink.shield units carry mixnet traffic between places with no internet and the rest of the network.
extend khėnsu.ñü
There are two ways to change khėnsu.ñü: pull requests for code, and consensus for the network’s rules.
code: pull requests
- Send pull requests to any repository once it opens. Outside contributors sign a contributor licence agreement once, through a bot on the first pull request.
khensu-coreis Apache-2.0; the apps, node, chain, services and sites are AGPL-3.0, so modified versions that others use must publish their changes.- Cryptography and protocol changes start with a written design, as a pull request to
khensu-specs, and need review before any code. - Node and app builds are reproducible, and every release hash is published to the transparency log, so anyone can check that what runs is what was merged.
network rules: consensus
- Rules that every node enforces (fees, eligibility, penalties, cipher suites) change only through the chain’s governance: a proposal needs 2/3 of the epoch’s 21-member committee and the founder’s signature.
- Every rule change waits a 30-day timelock, during which the committee can veto it. Emergency fixes take 48 hours and may only tighten rules, such as disabling a cipher.
- Nobody, including the founder, can use governance to read content, unmask users or make stealth optional.
- Committee seats go by lottery, weighted by node reputation and stake, so running a reliable node is how you get a vote.
See Contribute and Repositories and licences, or write tohello@elliottwave.studio.