L0 development
Evidence level: Implemented capability. CoNET-SI implements POST /post, hop forwarding, mailbox storage, labeled SSE pools, presence, acknowledgements, and UDP relay. Product coverage still depends on the client.
Public site: https://gitbook.conet.network/developers/l0.html
Layer Minus is a permissionless decentralized cloud. Anyone may use it. Participants join by offering CPU / GPU, forward traffic, and storage, and earn GB. Your application chooses wallets, encryption targets, and the object inside the envelope. SI forwards OpenPGP armor by key ID. It does not parse Chat JSON, mine epochs, or move tokens.
Build as if every node can be malicious. Combine privacy routing, fragmentation, and client-side crypto. Do not give one host plaintext or a whole reconstructable object. That is the path to privacy-first communications, storage, compute, and decentralized AI. Thesis: Permissionless cloud and zero-trust applications.
Start here
| Page | Use it for |
|---|---|
| Permissionless cloud and zero-trust applications | Who may join, GB rewards, fragmentation, and why no node is trusted |
| How to use Layer Minus | The application loop and the combinations that already exist |
| SI developer guide | Live /post contract, command catalog, and TypeScript samples |
| Chat developer guide | Chat envelopes, listenKind: "chat", dual receipts, presence, and history |
Read the SI guide before writing a new client. Read the Chat guide only if the product is mailbox messaging or a typed Beamio control message on the same path.
What you call
Your client
├─ EOA wallet + user OpenPGP + selected mailbox
├─ encrypt business JSON to recipient user PGP
│ or encrypt a signed command to a route PGP
└─ POST { data: <OpenPGP armor> } to a healthy entry
└─ SI reads key ID → forward or decrypt once
| Piece | Role |
|---|---|
| CoNET-SI | HTTP/HTTPS /post, SI-to-SI HTTP :80, mailbox, SSE, UDP relay |
| AddressPGP | L1 binding of an EOA to user PGP and a mailbox route |
| GuardianNodesInfoV6 | Public node list: domain, IP, route public key |
| Your application | Schema, UI, retries, and what a payload means |
Public node source: CoNET-project/CoNET-SI · npm @conet.project/mvp-si. Chat composition: chat-sdk.
Wire contract (do not invent another)
POST /post HTTP/1.1
Host: {domain}.conet.network
Content-Type: application/json
{"data":"<OpenPGP armored message>"}
- Client → entry: HTTP or HTTPS. HTTP is sufficient because the body is already ciphertext.
- SI → SI: HTTP
:80only. - Host
{domain}comes from GuardiangetAllNodesfieldPGPKey. Do not invent a subdomain. - For Chat, listen, ACK, presence, and UDP: pick entry A ≠ B / C ≠ B. Do not default-dial mailbox B.
- HTTP 200 or an SSE handshake is transport progress, not application delivery.
Full samples: discover nodes, register a route, encrypt a command, Chat listen.
Two families
| Family | Encrypt to | SI behavior | Typical use |
|---|---|---|---|
| Opaque business | Recipient user PGP | Forward and store. No business decrypt. | Chat text, typed JSON, udp_subscribe, sender receipts |
| Signed command | Target route PGP | Decrypt once and run the command | Chat listen, mining listen, ACK, presence, UDP relay, SilentPass |
Do not mix targets. Business JSON encrypted to mailbox B lets the mailbox read it. A listen command encrypted to a user key never reaches B.
Chat module
Chat is an application composition, not an extra L0 protocol.
- Pending row
{ sendId, from: "me", text, createdAt }. - EIP-191
signMessage(text)on the outer envelope. base64(JSON)→ encrypt to the recipient EOA user PGP → POST entry A ≠ B.- Recipient listen:
command: "mining"+listenKind: "chat"to own mailbox B, HTTP/SSE via C ≠ B. - After ingest, send both
gossip_delivery_ack(B route PGP) andbeamio_chat_delivery_receipt_v1(sender user PGP). - Presence is
wallet_online_queryonly. Ignore chainrouteOnline. - Resolve
@BeamioTagwith an exact match. Never takesearch-usersresults[0].
Copy-paste envelopes: Chat developer guide.
Other compositions
| Product | L0 primitives | Developer note |
|---|---|---|
| UDP frames | User-PGP udp_subscribe; route-PGP listen / relay |
Do not put Securitykey in a B-decryptable command |
| SilentPass | Route-PGP SilentPass / SaaS_Sock5* |
Product admission and path rotation are application-owned |
| Mining collector | command: "mining", omit listenKind, often direct to the target SI |
Infrastructure exception — see Participate in mining |
Higher privacy: split routing and app wallets
An app may register AddressPGP and sign listen / ACK / presence with a routing EOA, and keep sender / recipient EOAs only inside the encrypted business object. Mailbox B and hop GB then see the routing wallet, not the payment or display wallet. This is an application composition. L0 does not enforce it. Do not fund the routing wallet from the app wallet on-chain if you need that unlink. Full table: wallet-addressed peer identity.
Rules that break clients
- Chat listen must include
listenKind: "chat". Omitting it classifies the session as mining. - Same-node inner PGP after one decrypt is an attack: SI emits socket
endand does not peel again. - Hop signatures cap at 3. Application clients do not set
X-CoNET-Hop-Sigson the first/post. - A fake-PGP 404 (
body has not PGP message) is an intentional reject, not proof that SI is down. - Do not log private keys, full private PGP, or UDP
Securitykey. - Do not put the app sender / recipient EOA on the hop header or in a plaintext SI command if you split wallets.
Related protocol pages
- L0 overview
- Permissionless cloud and zero-trust applications
- Mailbox routing
- Security limits
- Node and client roles
Next
SI developer guide → · Chat developer guide → · Participate in mining →