L0 development

Evidence level: Implemented capability. CoNET-SI implements POST /post, hop forwarding, mailbox storage, labeled SSE pools, presence, acknowledgements, and UDP relay. Persistent application streams and web3:// are application compositions over those primitives; SI does not parse their business objects.

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: independent wallet-addressed roles, private application paths, and micropayments designed so no single party owns the stack. Thesis: Permissionless cloud and zero-trust applications. Product direction: Privacy-first Decentralized AI (whitepaper).

Start here

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

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 :80 only.
• Host {domain} comes from Guardian getAllNodes field PGPKey. 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.

Application protocols built on L0

web3:// is a cross-platform application protocol using L0 infrastructure. It composes the existing /post, entry, mailbox, and encrypted-session primitives; it does not add an SI command.

Use one source for each concern:

• Applications — web3://: product model and platform choices;
• web3:// Application Protocol: normative URI, envelope, signature, response, stream, and failure contract;
• CoNET-project/web3Url: browser client implementation; and
• Developers — conet-l0d: Linux server/client runtime.

A conforming implementation still follows the L0 invariants above: exact wallet resolution, user-PGP business encryption, entry-to-mailbox routing, HTTP JSON limited to { "data": "<OpenPGP armor>" }, and fail-closed identity and authorization checks.

Specification synchronization

Any change to the web3:// grammar, envelope fields, signing domain, encryption target, route selection, Entry contract, response shape, storage boundary, or browser lifecycle must update the Applications page, the protocol page, and affected runtime guides in the same change set. Changes to the underlying L0 wire contract must also update the relevant L0 protocol and SI developer pages before release.

Three families

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. Do not put NoPush / beamioNoPush on the HTTP JSON. Wire samples: SI developer guide — mailbox work.

Chat module

CoNET Chat is relationship-private communication infrastructure on Layer Minus, not a social silo. Applications get wallet-addressed envelopes, mailbox delivery, receipts, presence, and optional encrypted-history recovery without placing the user’s contact graph in a centralized messaging database. Product thesis: CoNET Chat.

Chat is an application composition, not an extra L0 protocol.

Its central field-visibility rule is easy to test: from / sender EOA is inside the signed application envelope and that complete envelope is encrypted to the recipient user PGP. The sender wallet address and the sender PGP key must not be copied into /post, a hop header, a mailbox command, push metadata, or relay logs. Only the recipient learns them after decrypt. The sender PGP private key never leaves the sender device. Entry A sees the client IP but not the sender wallet or sender PGP key; mailbox B sees the destination route but receives the transport connection from A. The key id visible on the ciphertext is the recipient key id. This separates IP observation, wallet routing, and message content without claiming that IP metadata disappears. Every inbound chat message uses the same rule. The session peer and bubble sender are the EOA recovered from the EIP-191 signature, not a wallet or @BeamioTag copied from the JSON. BeamioTag is a lookup of that recovered address. A failed check drops the message: no session, no bubble.

1. Pending row { sendId, from: "me", text, createdAt }.
2. EIP-191 signMessage(text) on the outer envelope. Inbound: verifyMessage must recover from. That recovered address is the sender. voice_call_offer_v1 adds callerSignature over a canonical text that excludes identity fields; it must recover the same EOA. Then look up @BeamioTag for that address. Do not display a tag or wallet taken from the payload.
3. base64(JSON) → encrypt to the recipient EOA user PGP → POST entry A ≠ B.
4. Recipient listen: command: "mining" + listenKind: "chat" to own mailbox B, HTTP/SSE via C ≠ B. Epoch / listing heartbeats prove the SSE is alive, not that a Chat message was forwarded. B must not expire a healthy writable listen by wall-clock age.
5. After ingest, send both gossip_delivery_ack (B route PGP) and beamio_chat_delivery_receipt_v1 (sender user PGP, then mailbox-work wrap NoPush: true to the sender’s mailbox B).
6. Presence is wallet_online_query only. Ignore chain routeOnline. After that answer, CoNET Chat sends wallet_native_wake_query. Encrypt it to the contact mailbox B route PGP and POST { "data" } to an entry node C ≠ B. Do not connect to B: that entry hop is what keeps the querier's IP off the destination mailbox. B returns boolean nativeWakeable (true when a registered iOS, Android, Windows, Linux, or macOS shell can be woken). A failed lookup does not clear the last trusted flag, and the response has no device token.
7. Resolve @BeamioTag with an exact match. Never take search-users results[0].
8. Voice uses voice_message_v1: AES-256-GCM audio ciphertext is uploaded as an IPFS fragment in ordered 512 KiB chunks; the recipient-only manifest carries the fragment hash and decryption material. The gateway boundary is 256 MiB, and playback/object URLs remain local and ephemeral.
9. Real-time voice calls are separate from mailbox_listen: both wallets open random temporary voice_listen SSE sessions, then exchange opaque AES-GCM frames through signed voice_uplink / voice_downlink commands. SI does not decrypt, persist, push, or index those frames. The outgoing voice_listen also carries offerArmor, the offer already encrypted to the callee user PGP. The caller's mailbox forwards that ciphertext to the callee mailbox in the same step and does not decrypt it. The caller does not send the offer as a second POST.

Voice route commands keep the initiating application wallet inside the recipient-user-PGP offer. voice_listen wake-up metadata uses only opaque session/call identifiers plus the callee routing target. The attached offerArmor is ciphertext; the mailbox must not decrypt it or log it. Verify the command, push request, SSE frame, and logs received by each node.

Copy-paste envelopes: CoNET Chat developer guide.

Other compositions

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 end and does not peel again.
• Hop signatures cap at 3. Application clients do not set X-CoNET-Hop-Sigs on the first /post.
• After a local peel, hop-sign the inner UTF-8 armor string (prefer peel plaintext; coerce Message.armor()). Hop-sign or C→B connect failure is a fast 404. A log-only uncaughtException that leaves the SSE open is a client connect_timeout with B never dialed.
• Start the ~12s listen connect_timeout after fetch. Emit listening only on res.ok + body. Exclude the failed C domain on reconnect.
• SI forward <ip> after peel is the client source IP, not mailbox B. Do not treat “switch C” as the first fix for a fleet-wide peel crash.
• A fake-PGP 404 (body has not PGP message) is an intentional reject, not proof that SI is down.
• Do not take search-users results[0] as the encrypt-to EOA.
• Do not log private keys, full private PGP, UDP Securitykey, or application-session AES keys.
• 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
• Persistent application streams
• Peel, hop-sig, and listen timeouts
• X-CoNET-Hop-Sigs v1
• Security limits
• Node and client roles

Next

SI developer guide → · CoNET Chat developer guide → · web3:// protocol → · Linux runtime →