How to use Layer Minus

Evidence level: Implemented capability. CoNET-SI implements the forwarding plane described here. Chat, SilentPass, mining, UDP, and Beamio control flows are application compositions of that plane. They are not additional L0 protocols.

Layer Minus is a permissionless decentralized cloud whose live wire is a PGP / wallet-address forwarding network. Anyone may use it. Participants offer forward bandwidth, storage, and CPU / GPU compute and are rewarded in GB for useful ciphertext work. It accepts an OpenPGP envelope, reads the recipient key ID, and either forwards that armor or — if this node can decrypt — peels an inner OpenPGP layer and forwards when the inner key ID is not local. It does not define a product, a message schema, a VPN, or a payment flow.

Do not trust any node. A Layer Minus host may drop, log, or lie. Privacy-first apps combine privacy routing, data fragmentation, and other client cryptography so that communications, storage, compute, and decentralized AI never hand a reconstructable secret to one operator. See Permissionless cloud and zero-trust applications.

How to use L0 is therefore application-layer development: pick wallets, pick encryption targets, put an application object inside the envelope, and combine the forwarding primitives that already exist.

What L0 is

A Layer Minus node does the following:

1. Accept POST with { data: <OpenPGP armor> } over HTTP (HTTPS optional). The client must not send X-CoNET-Hop-Sigs.
2. Read getEncryptionKeyIDs() from the OpenPGP side channel.
3. If that key ID is not a routable node / mailbox, respond 404.
4. If that key ID is not this node's route PGP but is routable, miner-sign the same armor and forward it to its mailbox over HTTP :80 (X-CoNET-Hop-Sigs, cap 3). If the destination SI emits socket end, close and free this hop.
5. If the key ID is this node's route PGP, decrypt once. Then:
   • if the plaintext is still OpenPGP armor and the inner side-channel key ID is this node, treat it as an attack: emit socket end and stop;
   • if the inner key ID is not this node, check SI-to-SI hop signatures. More than 3 signatures, or a count that cannot take another hop, is an all-node flood: emit end and discard;
   • otherwise forward the inner armor and append this node's miner hop signature;
   • if this node is the mailbox, store the armor and, when a listen SSE is attached, encrypt the downlink with the user’s listen Securitykey;
   • if the plaintext is signed JSON { message, signMessage }, the last hop verifies hop signatures, meters those prior-hop bytes against the user wallet for GB, and runs the API command (listen, proxy, storage, WASM / container, and so on).

Byte-level header rules: X-CoNET-Hop-Sigs v1. The header is miner signatures for GB metering. It is not a detailed forward JSON.

That peel-and-forward step is the outer envelope and nested multi-hop primitive. A node decrypts at most one local layer. An application may wrap a user-PGP business message to an entry (or to a short hop chain). A path observer of the first /post then sees the outer key ID, not the inner recipient. Each node that can decrypt still learns the next key ID. Extra hops are extra forwarded bytes and therefore extra GB. When a destination SI ends the socket, the previous hop closes and frees that connection.

Forwarded bytes are metered for GB. That is the incentive for carrying ciphertext, not for reading it.

Any application
  │  choose wallets and keys
  │  choose encrypt-to-user-PGP or encrypt-to-route-PGP
  │  put application JSON (or AES frames) inside
  ▼
L0 forwarding plane
  POST armor (no hop header) → read key ID
    ├─ not a routable node → 404
    ├─ not local → HTTP :80 forward same armor + miner hop signature
    └─ local decrypt once → same-node inner PGP → end (attack)
                          → inner key ≠ local and hop sigs < 3 → forward inner
                          → mailbox → store / SSE (SSE encrypted with listen Securitykey)
                          → else run signed JSON command; last hop meters prior hops to the user

L0 names a peer as wallet + OpenPGP material. IP addresses remain TCP/IP locators for one hop. Changing entry, mailbox, or device does not change the wallet unless the application creates a new one.

What L0 is not

Do not treat DePIN Chat or SilentPass as “the L0 protocol.” They are two combinations of the same forwarding network.

Application developer loop

Every L0-using client repeats the same loop. Only the inner object and the encryption target change. Copy-paste TypeScript for POST /post and the command catalog is in the SI developer guide. Chat envelopes, listen, receipts, and presence are in the Chat developer guide. The developer-track index is L0 development.

1. Create wallets (routing can be separate)

The protocol identity of a mailbox row is an EOA. Generate one, or reuse an existing wallet. An AA Smart Wallet is not a destination unless it has its own AddressPGP registration.

For higher privacy, do not reuse the same EOA for routing and for the people in the product:

SI routes the inbox user PGP registered on the routing wallet. The product can name a different sender or recipient EOA inside that ciphertext. Details: Routing wallet versus sender / recipient wallets.

If a wallet or key is later exposed, the application can create an on-demand new wallet, generate a new user PGP pair, and register again. L0 has no “account recovery” of its own; it just starts forwarding to the new key ID. Rotating only the routing wallet does not require a new product identity.

2. Register public bindings on L1

Publish, for that EOA:

• user OpenPGP public key (business-message recipient);
• encryption subkey ID used on envelopes;
• selected mailbox route key ID.

Current clients use the compatibility API regiestChatRoute, then resolve peers with searchKey(walletAddress). Human-readable tags are an application lookup aid. Prefix-search results[0] is not a protocol identity.

3. Choose the encryption target

This is the only cryptographic decision L0 requires the application to get right.

Wrong target breaks the model: business JSON encrypted to B lets the mailbox read it; a listen command encrypted to the user key never reaches B.

4. Post through a healthy entry

Sign the inner object with the EOA ({ message, signMessage }), OpenPGP-encrypt it, and POST { data: armor } to a healthy entry A ≠ B.

HTTP is sufficient for payload confidentiality because the body is already ciphertext. HTTPS is optional at the same handler and is the usual browser / payment carrier. Neither is “more private” in every dimension — HTTP versus HTTPS. SI-to-SI forwarding is HTTP on port 80.

The POST hides the sender from the mailbox: B sees an entry hop and a recipient key ID, not S's client IP.

A one-layer post (encrypt only to R's user PGP) does not hide R's key ID from A or from a plaintext-HTTP path observer. An outer envelope (encrypt that armor to A's route PGP, or to a short chain of node keys) hides the inner key ID from the first-hop observer. After A decrypts once, SI forwards if the inner side channel is not local and hop signatures stay at or below 3. Same-node inner PGP is an attack. A still learns the next key ID. That is routing, not business plaintext.

5. Listen only if the application needs inbound data

Listening is another composition, not a default L0 session.

Encrypt a listen command to B's route PGP and open HTTP/SSE through a healthy entry C ≠ B. Label the session so SI can keep pools apart:

Entry acceptance or an SSE handshake is transport progress. The application still decrypts, verifies, and decides what the payload means.

6. Put the product protocol inside the envelope

L0 does not parse application JSON. The client defines:

• the inner schema (type, sendId, amounts, hosts, frames);
• whether a message is shown, queued, or discarded;
• acknowledgements, retries, and wallet rotation;
• optional extra encryption before the L0 envelope.

Three privacy elements exist: sender, recipient, and content. L0 can hide content from intermediate nodes and hide the sender's direct IP from the mailbox. Who counts as sender or recipient, whether those wallets rotate, and what the content means are application choices.

Combinations that already exist

The same forwarding plane is reused. Only the inner object and key roles change.

A new product should start from this table: reuse the forwarding primitives, then invent only the inner protocol it actually needs.

Combinations that are not in current SI

These are valid application designs on top of a forwarding network. They are not present as automatic SI policy (postOpenpgpRouteSocket already peels a local-decryptable outer PGP layer and forwards a non-local inner layer).

Document those as upgrades or product options. Do not describe them as the live L0 plane. See security limits.

Implementation anchors

Next

1. L0 development — developer-track index for SI and Chat.
2. SI developer guide — live /post contract, command catalog, and samples.
3. Chat developer guide — Chat envelopes, listen, receipts, and presence.
4. Wallet-addressed peer identity — EOA, user PGP, route PGP.
5. Zero-trust mailbox routing — S → A → B and R → C → B → R.
6. X-CoNET-Hop-Sigs v1 — compact miner hop header (not a path JSON).
7. UDP frame forwarding — one composition that adds a symmetric key.
8. Security limits — live threat grades versus proposed upgrades.
9. Applications — products that combine L0 with L1 and UI.