Skip to content

P1.md

Latest commit

 

History

History
212 lines (159 loc) · 7.22 KB

P1.md

File metadata and controls

212 lines (159 loc) · 7.22 KB
Raw

P1 — web3:// duplex application transport

Paired Chinese version: P1.zh-CN.md

Revision: 2026-08-22

Public guides: Applications · Linux runtime

1. Scope

P1 turns a wallet-addressed destination into a persistent bidirectional application stream. It is the transport used by:

  • Linux servers publishing a local TCP service with --proxyDuplex;
  • Linux clients opening a local endpoint with --clientDuplex;
  • browser and native clients implementing the same web3:// session protocol.

This page describes the application transport. It does not redefine public L1 node joining and does not introduce a new SI command family.

2. Session model

local application
        │
        ▼
web3:// runtime
        │  exact wallet destination + logical port
        ▼
Entry A / Entry C ── CoNET L0 ── mailbox B
        │
        ▼
destination runtime ── local upstream

The application sees an ordered byte stream. L0 supplies encrypted routing and line delivery.

Step Mechanism
advertise an available line deployed SI command l0_listen
request a destination line deployed SI command l0_connect
coordinate attachment application messages duplex_offer / duplex_accept
reject attachment application message duplex_reject
transfer application bytes AES frames on the occupied line
close socket close and l0_pipe_end

duplex_* is application framing carried by existing Chat/L0 paths. It is not a new SI command family.

3. Entry and encryption rules

Object Encryption target HTTP destination
application offer destination user PGP healthy Entry A, where A differs from mailbox B
mailbox listen own mailbox route PGP healthy Entry C, where C differs from mailbox B
line connect destination mailbox route PGP healthy entry, forwarded to mailbox B
application data negotiated session encryption occupied L0 line

The HTTP request body is always:

{ "data": "<OpenPGP armor>" }

No control value is added as a plaintext sibling field. A successful entry response proves entry acceptance, not end-user delivery.

4. Addressing

The client form is:

web3://<EOA>:<port>
web3://<ExactTag>.web3:<port>

Examples:

web3://0x1111111111111111111111111111111111111111:4200
web3://CoNET.web3:8080

Tag resolution is exact and case-sensitive. CoNET.web3 and CONET.web3 may refer to different wallets and must never be collapsed into the first search result.

5. Linux server

conet-l0d start \
  --mainWallet 0x<main-paid-wallet> \
  --proxyDuplex 127.0.0.1:4200 \
  --config /etc/conet-l0d.toml

The runtime keeps the published application bound to its normal local address. Restarting the runtime does not require restarting that application.

For multiple logical ports, each [[l0.channels]] row may provide a dedicated communication EOA, communication PGP key, EIP-191 key, mailbox route key, and listen-entry set. This matches SI exclusive occupancy: one listen wallet owns one line at a time.

6. Linux client

conet-l0d start \
  --mainWallet 0x<main-paid-wallet> \
  --clientDuplex web3://0x<destination-wallet>:4200 \
  --config /etc/conet-l0d.toml

The local application connects to the endpoint printed by check-config, resolve, or startup logs. The runtime then:

  1. resolves the exact destination;
  2. selects the route for that logical port;
  3. opens or reuses an L0 line;
  4. forwards bytes in order;
  5. releases the line on close;
  6. retries with bounded backoff when the mailbox reports a temporary conflict.

7. Browser and native client

Browser/native clients use the same destination and session semantics without the Linux process. A portable implementation needs:

  • exact EOA or BeamioTag resolution;
  • OpenPGP and EIP-191 support;
  • Entry A / Entry C selection with mailbox-B exclusion;
  • streaming HTTP/SSE support or a native bridge with equivalent semantics;
  • ordered duplex framing and close handling;
  • trusted-state retention when a request fails.

This is the primary client model for Windows, macOS, Android, and iOS.

8. Fail-closed behavior

The runtime does not open a line when required identity or routing material is missing. In particular:

  • a user key cannot substitute for a mailbox route key;
  • an outbound entry list cannot silently substitute for a listen-entry list;
  • a communication EOA must match its EIP-191 private key;
  • two logical channels must not share an exclusive listen identity;
  • an occupied line belongs only to its current session generation;
  • stale accept, reject, frame, or end messages cannot mutate a newer session.

Private keys, session keys, plaintext payloads, and complete encrypted payloads must not be logged.

9. Implementation status

Capability Status
exact web3://<host>:<port> parsing implemented and unit-tested
--proxyDuplex / [[l0.proxy_duplex]] server profile implemented
l0_connect / l0_listen line handling implemented
offer / accept / reject coordination implemented
occupied-line AES framing implemented
raw or SSE-wrapped inbound armor parsing implemented
per-port communication identities implemented
local duplex client endpoints implemented
bounded reconnect and session generation implemented
browser SDK packaging protocol defined; product integrations are separate

10. Research evidence

Authorized August 2026 lab runs used the duplex transport for geth and Prysm TCP streams between overlay endpoints:

  • geth established a peer on logical port 8400;
  • beacon established a peer on logical port 4200;
  • the consensus head increased while sync distance decreased;
  • restarting only the conet-l0d processes preserved the published applications;
  • sustained line conflicts or queue saturation remained failure signals.

These results prove application transport interoperability. They do not prove that public CoNET L1 nodes have moved from public P2P to L0.

11. Acceptance gate

P1 is accepted for an application profile when:

  1. the destination wallet and port are unambiguous;
  2. the server receives an offer through its existing mailbox path;
  3. both peers agree on one current session generation;
  4. ordered bytes flow in both directions;
  5. close releases both endpoint and mailbox ownership;
  6. reconnect works without restarting the published application;
  7. no secret material appears in logs;
  8. entry failure or malformed data does not overwrite trusted state.

12. Out of scope

  • new SI p2p_stream_* commands;
  • a listenKind invented solely for L1;
  • changing the public L1 joining path;
  • treating browser support as a Linux daemon port;
  • promising generic UDP behavior from this TCP duplex profile.

13. Synchronization rule

Changes to this page, the MVP, whitepaper, or RULES.md must update the GitBook Application Protocol and Linux runtime pages in the same task.

SI pool transport selection

P1 control POSTs, listens, and occupied L0 pipes prefer the GuardianNodesInfoV6 SI pool when enabled. Failed candidates are cooled down; static SI entries remain an explicit pool-off fallback.