Five opinions, held on your behalf.

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 ships strict, with focus-aware tightening.
• Hidden and minimised applets wait until you can see them, 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. 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: 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.