pure/docs/research/093-connectionless-link.md, branch masterVerified execution runtime unifying state, persistence, and replication.
http://git.yeowoo.org/pure/atom?h=master2026-09-29T06:06:27ZPut the links and the crypto they use in link/, a part of their own2026-09-29T06:06:27Zeunhhunecpition205@gmail.com2026-09-29T06:06:27Zurn:sha1:a052b95c8135cdc5f9b91f8efc991cac80fbbe8b
libpure-link.a holds them; pure-serve and the M5 harness link it instead
of naming its source files.
Link two nodes without a connection over UDP (093, design 011's first stage)2026-09-28T16:37:41Zeunhhunecpition205@gmail.com2026-09-28T16:37:41Zurn:sha1:745efcd4f19b59bcfb131df2d127a3387a544e84
pure-serve --send OUTPUT=pure://host:port/INPUT sends an output's saved
sends to another node's --link-port with no handshake: the first packet
carries records. Keys come from the two nodes' keys (X25519, HKDF-SHA256,
AES-128-GCM), with a random run in each packet's header so no nonce
repeats across restarts; nothing is stored for them. What lasts is the
apps' own: the sender's outbox and the receiver's heard numbers
(pure_app_heard, new). The sender detects losses as RFC 9002 says, with
NewReno, and trims a send once the receiver says it stored it; the
receiver hands the owner whole records in order, which it applies from
the one after the source's last heard number, stopping at a gap, and
answers how far it stored with every acknowledgment. Stored bytes are
the bytes on the wire: an output and an input of one shape need no JSON.
server_links_udp kills the receiver, the sender, then both (-9) while
four clients buy: every saved order is applied once, with no handshake
(five runs, 10k-11k orders each). server_links_udp_lossy does it again in
a namespace of its own with the link's packets delayed, lost (3 %) and
reordered (10 %) by netem (three runs, 11k-12k orders).