# kernl > Full text of every page on this site, in reading order. # Run things you don't have to trust. > kernl is a shell that runs small applets in a sealed sandbox. Your identity, contacts, messages and files stay yours; applets borrow them only while you watch. kernl runs small, self-contained applets in a sealed sandbox. **Your identity, contacts, messages and files are yours** and travel with you. An applet borrows them only with your say-so, and only while you watch. Pass, slow down, or cut off. Each line is a decision you can see. ## A window, a loan, and a line it cannot cross alone. *Sealed* ### A window of its own Each applet runs in a sealed frame with no address of its own and no way to call out, and it cannot open a frame of its own inside it. It can draw and compute; it cannot reach anything you did not hand it. *Borrowed* ### Your things, on loan Contacts, messages, files and your account are read by the shell on the applet's behalf. A grant is something you gave and can take back, and the shell shows what each one changes. *Watched* ### A network it reaches through you Everything an applet sends or fetches goes through the shell. The guard shows you what it reports, refuses or quarantines; some refusals made deeper inside the shell are not listed yet. You can block an applet, take back any grant, or make the guard stricter for the whole shell, at any time. ## kernl is opinionated so you don't have to be. It is built on [kehto](https://github.com/kehto/web), an open toolkit that leaves every choice open. kernl makes the choices, in your favour, and writes down why. 1. **Everything in one place, reached one way** One store, one connection, one account manager. There is no second copy of your world for an applet to get at. 2. **The shell empowers you and contains the applet** Those are its only two jobs, in that order. 3. **Protections are on by default** The shell starts strict on every visit. Only you can ease it, for the whole shell until you reload; easing one applet at a time is planned. A developer flag never can. 4. **One account, many networks, no brand names** Downloads, sharing and mail plug in as bridges named by what they do for you. 5. **No private-messaging system is "the best"** The shell describes each provider truthfully and lets you choose the one your correspondent can read. [Read the five opinions](https://kernlize.github.io/why/) ## Alpha, and said so. kernl is alpha software. The sandbox and the guard work today. Private, legacy and ratchet messages work when your account can encrypt; ratchet sessions are experimental. Downloads, sharing and mail work by handing off to an app on your device; in-shell backends are planned. The shell shows anything it cannot do as unavailable rather than pretending. Applets are verified by content hash before they run and re-checked on every read from cache. If the bytes change, the applet's grants die with them. [Build on it](https://kernlize.github.io/developers/) [Read the decisions](https://kernlize.github.io/docs/decisions) ## Free. $0, no tier, no catch. *Price* ### $0 No subscription and no paid features. The whole shell is the free version. *Licence* ### MIT The source is private during alpha and opens under the MIT licence with the first public release. The decisions behind it are public now. *To try it* ### No sign-up [Open the preview](https://kernlize.github.io/app/?preview=1) and use the shell with sample applets, entirely in your browser. ## Asked often, answered plainly. ### What is an applet? A small, self-contained program published as a single verified file. kernl checks its content hash before it runs and gives it a sealed window with no network of its own. ### What can an applet see? Only what you grant, for as long as you grant it. By default it sees your theme, its own storage and which account is signed in. Network access, messages, notifications and files are each a separate grant you can take back. ### Does kernl hold my keys? No applet ever does. You can sign in with a browser extension or a remote signer so your key never enters the shell, or create a local account whose key is encrypted with a password you choose. ### What does kernl cost? Nothing. kernl is free, with no account to buy and no paid tier. It is MIT licensed; the source is private during alpha and opens with the first public release. ### Can I try it without signing in? Yes. The preview runs the whole shell in your browser with sample applets and a throwaway account. Nothing leaves the tab. ### Is it ready for daily use? Not yet. kernl is alpha software. The sandbox and the guard work. Private, legacy and ratchet messages work once you sign in with an account that can encrypt, such as a browser extension, a remote signer or a local account; ratchet sessions are experimental. Downloads, sharing and mail work by handing off to an app on your device, after the shell asks you; in-shell backends are planned. --- # Five opinions, held on your behalf. > The five opinions behind kernl, in plain words: one place for your things, a shell that contains applets, protections on by default, many networks, no ranking. kernl is built on [kehto](https://github.com/kehto/web), a toolkit that deliberately decides nothing. kernl decides everything kehto left open, and every decision breaks the same way: **towards the person at the keyboard**. 01 ## Everything in one place, reached one way. Your messages, contacts, files and account live in one store inside the shell, read through one connection and signed by one account manager. kernl does not hedge that with a second library doing the same job, because every extra copy is another thing to protect. - Applets never get a handle on the store. Services read from it for them. - Your keys are never raw bytes outside the signer that holds them. - One path in and out means one place to watch. 02 ## The shell exists to empower you and to contain the applet. A shell has two jobs. It gives you a place where your identity and your things are yours and portable. And it gives an untrusted program a place to run where the worst it can do is bounded. kernl cannot protect you from everything. It does all of it that it can. - Applets run in a sealed frame with no network of their own, and cannot open another frame inside it. - They never hold keys, never see text you did not ask to show them, and learn which account you use only if you grant it. - Before the shell signs anything for an applet that overwrites or erases part of your record, it shows you what changes, not code. - An applet's identity is bound to the exact bytes you verified. Changed bytes are a new applet, with no grants. 03 ## Protections are on by default. You loosen them, not the developer. When the toolkit offers a privacy or safety mitigation, kernl turns it on, in its strict setting, and documents how to ease it. You matter more than the applet developer does. Within reason: an applet interface so tight that nothing can be written protects nobody. - The [guard](https://kernlize.github.io/guard/) ships strict, with focus-aware tightening. - Hidden and minimised applets are measured against a smaller budget, and one that keeps downloading while hidden is stopped. - A protection is loosened by you, never by a developer or a flag. Today that choice covers the whole shell until you reload; loosening one applet at a time is planned. 04 ## One account, many networks, no brand names. Your account is how you are known, how applets are found and verified, and how you reach other people. It is not the only network kernl speaks. Downloads, sharing and mail are meant to plug in as [bridges](https://kernlize.github.io/bridges/). Today web fetch works inside the shell, and downloads, sharing and mail work by handing off to an app on your device after the shell asks you; in-shell backends are planned. There is no per-applet allowance for bridges yet. - Bridges are named by what they do for you, not by the wire format they speak. - This site does not name protocols. The protocol is the plumbing. The person is the point. 05 ## No private-messaging system is "the best". kernl is built to support any reasonable private-messaging provider through one interface. You pick the one your correspondent can read, and the shell makes that choice visible and reversible. In this alpha private, legacy and ratchet messages work when your account can encrypt; ratchet sessions are experimental. - The shell does not rank providers. It [describes them](https://kernlize.github.io/messaging/): forward secrecy or not, what the network can see, whether the other person needs the same app. - Applets are given one messaging surface that spans every provider you enable. ## The tie-breakers, in order. 1. **Your safety and agency** Always first. 2. **Doing what the open format actually says** Conformance with the upstream specification, not a convenient reading of it. 3. **The applet developer's ability to build** A competent developer, reading the docs, must still have a clear path. 4. **Documentation accuracy** A feature without docs is not shipped. 5. **Performance, then code size** In that order, and last. --- # Everything between an applet and the world. > What the kernl guard does between an applet and your network: a sealed sandbox, verified bytes, budgets, flood control and a question before anything destructive is signed, loosened only by you. The guard is the set of protections that sit between an applet and you. It is **on from the first second**, in its strict setting. It tells you when it acts and why, and only you can loosen it. ## Eleven protections, in plain words. 1. **A sealed sandbox** Each applet runs in a frame with no address of its own and a policy that forbids every network call, and it cannot open a frame of its own inside it. The only way out is through the shell, where you can see it, take back what you granted, or close the applet. It does not even learn which account you use unless you grant it. 2. **Identity bound to the bytes, with revocation** An applet's identity is tied to the exact code you verified and to the live connection it runs over. If either changes, the connection is cut and the frame is removed. What you allowed stays with that exact code, so it applies again when you reopen it; changed code starts with no grants. 3. **Verified before it runs, re-checked from cache** Applet code is checked against its content hash before the first run. Cached copies are checked again on every read, so a tampered cache cannot slip past. 4. **Old or repeated posts are not sent** When the shell posts for an applet, it refuses a post it has already sent in the last half minute, one dated too far in the past, or one dated in the future. A message from a window other than the applet's own is ignored. 5. **Behavioural rate limits** Reading, publishing, messaging, storage and downloads each have an allowance per applet, set before it starts. A request over its allowance is refused until the allowance refills. Deletions count against publishing, and are also counted on their own so you can see an applet that deletes a lot. 6. **Focus-aware tightening** An applet you are not looking at is measured against a smaller budget. A request over it is refused before it is handled, and the guard tells you; the applet can try again once you switch to it. The budget above still applies. The shell decides what is focused; the applet is never asked. 7. **Hidden applets cannot act until you can see them** While an applet is minimised or hidden, the shell refuses its requests before they are handled, except the messages that let you close, theme or reach it; the applet can try again once it is visible. One that keeps asking for downloads past its allowance is quarantined: the download that crossed the allowance is dropped, and the shell closes it and tells you. 8. **Flood control and quarantine** The shell counts every message an applet sends. Requests in a burst above the per-second rate are refused before they are handled, and the shell tells you; messages that keep the window controllable still get through. One that keeps flooding is quarantined: the message that crossed the limit is dropped, and the shell closes the applet and tells you. You can open it again when you choose. 9. **Oversized requests are refused** Requests for files and long-running searches are measured against a maximum size. One that is too large is refused before it is handled, so nothing it asked for is fetched, and the shell tells you. 10. **Device permissions denied** Camera, microphone, location and the rest are off for every applet. There is no prompt to be tricked into. 11. **Consent for destructive changes** Before the shell signs anything for an applet that overwrites or erases part of your public record (your profile, who you follow, your servers, one of your lists or any other record a new version replaces, a deletion, or a request to erase your account), it shows you what changes compared with the current version and waits for your answer. If the current version cannot be loaded, it says so. If you say no, nothing is signed. Everyday posts go through without a question, and the shell asks again every time. *What you see* ## What it reports, it explains. The guard records what it reports, refuses or quarantines, each with a stable reason you can read. Some refusals made inside the runtime that runs applets are not shown yet; they will be listed as soon as the runtime reports them. *Loosening it* ## By you, and only you. Three profiles exist: strict, balanced and relaxed. The shell boots strict, every time. For now the choice applies to the whole shell and is forgotten when you reload; easing one applet at a time is planned. No configuration file or developer flag can ease the guard. The [documentation](https://kernlize.github.io/docs/) lists each limit by profile. --- # Described, not ranked. > kernl describes several private-message providers and ranks none. Each is described by what it protects. Private, legacy and ratchet messages work in the live shell when your account can encrypt; ratchet sessions are experimental. kernl is built to offer private messaging through several providers. **None of them is "the best".** The shell tells you plainly what each one protects, and you pick the one the person you are writing to can read. ## Two providers send today; one is still to come. kernl is alpha software. Private messages and legacy messages work in the live shell once you sign in with an account that can encrypt: a browser extension, a remote signer or a local account on this device. A read-only account cannot, and the shell says so. Ratchet sessions work the same way and are experimental: the person you write to needs an app that speaks them, they are one to one, and the keys that change with every message are kept on this device, locked so only your account can open them. Clearing this site's data ends those sessions. Group sessions work the same way and are experimental too: everyone you add needs an app that speaks them and must have used it once, so that you can invite them; your groups are kept on this device, locked to your account, while their messages last only until you reload. The [preview](https://kernlize.github.io/app/?preview=1) lets you try private and legacy messages without an account, and keeps everything in your browser tab; ratchet sessions need the live shell. Your messages are opened by your own account, in the Messages panel, for you. An applet sees your messages only if you grant it messages, and you can take that grant back. ## The same six questions, asked of each. ### Private messages The default. Each message is meant to be wrapped so the network cannot see who wrote it or what it says. - **Forward secrecy**: No - **Heals after a key leak**: No - **Metadata protection**: Partial - **Other person needs this app**: No - **Groups**: Yes - **Experimental**: No ### Legacy messages The original format, kept so old conversations still open. The content is hidden; who talks to whom and when is not. - **Forward secrecy**: No - **Heals after a key leak**: No - **Metadata protection**: None - **Other person needs this app**: No - **Groups**: No - **Experimental**: No ### Ratchet sessions Keys change with every message, so a leak today does not expose yesterday. Both sides need an app that speaks it. - **Forward secrecy**: Yes - **Heals after a key leak**: Yes - **Metadata protection**: Partial - **Other person needs this app**: Yes - **Groups**: No - **Experimental**: Yes ### Group sessions A group shares keys that change as it talks and as people join or leave, so a leak exposes neither what came before nor, once the group moves on, what comes after. Everyone in it needs an app that speaks it. - **Forward secrecy**: Yes - **Heals after a key leak**: Yes - **Metadata protection**: Partial - **Other person needs this app**: Yes - **Groups**: Yes - **Experimental**: Yes ## What the rows mean. - **Forward secrecy**: If your keys leak today, messages from before today stay unreadable. - **Heals after a key leak**: Once both of you keep writing, a leaked key stops being useful to whoever has it. - **Metadata protection**: How much someone watching the network learns about who talks to whom and when. "Partial" means the sender and timing are hidden but delivery is not. - **Other person needs this app**: Whether your correspondent must use an app that speaks the same provider. - **Experimental**: The provider is still changing and may lose history between versions. kernl says so before you enable it. Applets are given one messaging surface that spans every provider you enable. The choice of provider stays with you, is shown on every conversation, and can be changed. More in the [documentation](https://kernlize.github.io/docs/). --- # Named by what they do for you. > Bridges let kernl reach other networks for you. Web fetch and downloads from peers work inside kernl today; newsgroup downloads, sharing and mail hand off to an app on your device. A bridge is a service the shell owns that turns a link into bytes or a conversation on another network. An applet never talks to the other network itself; it asks the shell, and the shell answers. **In this alpha web fetch has no consent prompt yet** and refuses private and local addresses by policy. Files shared by peers download inside kernl. Newsgroup downloads, sharing and mail hand the link to an app on your device, and the shell asks you before it leaves kernl. ## What works today, and what is waiting. *Works today* ### Web fetch Fetches a web address for an applet, through the shell, with a policy that refuses private and local addresses so an applet cannot use you to look inside your own network. *Works today* ### Downloads from peers Links to files that people share with each other download inside kernl, in the Downloads panel, where you can pause, resume, remove and save them. Peers see your network address and what you fetch. If you prefer, Settings sends these links to the download app on your device instead. *Hands off to your device* ### Newsgroup downloads Understands the links people share for newsgroup posts, and hands each one to the download app on your device after asking you. kernl itself moves no bytes for it. *Hands off to your device* ### Sharing Person-to-person file sharing between people who choose each other. The shell opens the sharing app on your device with the file the link names; an in-shell backend is on the roadmap. *Hands off to your device* ### Mail Turns a mail link into a new message in the mail app on your device, with the subject and text the link carries. Sending and receiving inside the shell wait for a backend you would run or trust. Why some bridges hand off: a web page may only make web requests and direct connections to other browsers. Newsgroup servers, sharing networks and mail servers need a kind of connection no web page is allowed to open, so until kernl can reach a helper you run or trust, an app on your device does that part. Handing off is honest about what happens: the app on your device does the transfer, so what that app shares with the other side is what Settings lists for the bridge, and nothing goes through kernl's own connections. Where no app is set up, nothing opens. A bridge with nothing to hand off to reports itself as unavailable, and an applet cannot tell the difference between "unavailable" and "you said no". ## Every bridge, the same way. 1. **An applet asks; the shell resolves** The applet never touches the other network. It hands the shell a link and gets back bytes or a conversation, or a reason. 2. **Not yet: seeing each request** Bridge requests are not listed in the [guard](https://kernlize.github.io/guard/) yet, and there is no per-applet allowance for them. Until those exist, the shell does not claim either. 3. **Named for people** "Downloads", "sharing", "mail". Not the name of the wire format underneath. If you care which one it is, the documentation says. --- # Build something people can run without trusting you. > How to build for kernl: write an applet in the open applet format, learn what the sealed sandbox and strict guard mean for your code, and read the docs first. An applet for kernl is a small, self-contained web page in the open applet format. It gets a sealed window, asks for what it needs, and reaches the world through the shell. **That constraint is the feature.** ## Three places to read. *Docs* ### [kernl documentation](https://kernlize.github.io/docs/) Concepts, how-tos and the reference for every package: the guard and its profiles, messaging providers, bridges and the shell's composition root. *Toolkit* ### [kehto](https://github.com/kehto/web) The open, unopinionated toolkit kernl is built on. If you want to build a different shell with different opinions, start there. *Format* ### [Applets under kernl](https://kernlize.github.io/docs/concepts/applets-under-kernl) How applets are packaged, addressed and verified, and the message domains an applet can ask a shell for. kernl hosts this format without changing it; the full specification lives on [the applet format's site](https://napplet.run/). ## What your applet gets, and does not. 1. **A sealed window** Your code runs in a frame with no origin and a policy that blocks every direct network call. Draw, compute, and talk to the shell over its message port. 2. **Grants, not permissions** Ask for the domains you need. The shell narrows what it advertises to what the user has granted, shows every overwrite or deletion as what it changes before signing it, and lets the user take a grant back. Knowing who is signed in is a grant too: ask for the user's account if you need it. 3. **The strict profile** Rate limits, size caps, a hidden-window download allowance and focus-aware tightening are on. Design for them: batch requests, do less when hidden, and expect a refusal to carry a stable reason you can show. 4. **Verified bytes** Your applet is identified by the hash of its content. Ship a new version and it is a new identity with fresh grants. That is deliberate. 5. **Messaging across providers** One messaging surface spans every provider the user enables. You do not pick the provider; the user does. In this alpha private, legacy and ratchet messages work in the live shell when the signed-in account can encrypt, and nothing is available while nobody is signed in. Ratchet sessions are experimental and one to one. A send through a provider that cannot serve it fails with the reason `unavailable`. Feature-detect messaging and handle `unavailable` as a normal answer, not a crash. *Source* ## MIT, opening after alpha. Four small packages and one app. Behaviour is specified in scenarios before it is implemented, and coverage is complete. Decisions, and the reasons for them, are written down and published now. The source itself is private during alpha and opens under the MIT licence with the first public release. [Read the decisions](https://kernlize.github.io/docs/decisions) *For agents* ## Read this site as text. Every page has a Markdown twin at `index.md` next to it, listed in [llms.txt](https://kernlize.github.io/llms.txt). The full text is in [llms-full.txt](https://kernlize.github.io/llms-full.txt), and the docs publish their own. --- # kernl shell > The kernl shell. Open an applet by its address and run it in a sealed sandbox, with your identity, contacts and messages on loan only while you watch.