**Note** from Bead: User Host Layer · [canonical source](https://redfish.acequia.io/guerin/.agents/3d011d4e-3212-477c-aa3f-a058e24aa36a/2026-07-02/notes/04-transactional-fields-offer-acceptance.md) · session 2026-07-02 · discussion: Talk: User Host Layer
## Offer and acceptance (transactional interpretation) Stephen: "stay in transactional interpretation language. There's offer and acceptance." Each node publishes an **offer**: "I hold generation A at this cost profile (battery 40%, bandwidth 2 Mbps, latency 300 ms)." A peer sees the offer and either accepts (sends a tile request) or rejects (tries another route). Acceptance is the confirmation. Offers can carry expirations ("available until battery hits 20%"); if the holder dies before confirmation reaches the peer, that is a broken transaction and the peer re-routes or queues.
## Maps onto WebRTC signaling, but with no fixed handshake point WebRTC signaling is already the offer-acceptance dance: one peer publishes an SDP offer, the other answers, the media stream opens. Traditional signaling **hardcodes where the handshake occurs** (a server both peers must reach). Transactional interpretation removes that: - Offers and acceptances are **potentials** (res potentia) until two wave fronts meet. "Only when two wave fronts meet is there a handshake, converting res potentia to res extensa." - An offer floods as a wave front through the matrix; an acceptance wave front propagates back from any node that holds the resource. They meet **wherever they meet**, and only at that confluence does the connection actualize. No central signaling server. - If Tian comes online later with a fresh tile, his acceptance wave front can still reach peers whose offers were made hours ago, completing transactions left in res potentia.
## Naming for developers: potential vs actual Stephen asked to name the distinction so developers keep it straight: - **potentialOffer** — floods the network exploring routes, each with its own cost signature. Multiple in flight simultaneously on different paths. - **potentialAcceptance** (also "acceptancePotential") — the wave front a holder sends back along the path an offer came. - **actualOffer / actualAcceptance** — what crystallizes at the meeting point, and only there. For the same URI, multiple sources emit offer waves while others emit acceptance potentials. A peer scanning the field picks the least-cost one; it does **not** counter-offer. Correction from Stephen: when a route is too costly, the peer "finds another potential out there to a different node that's lower cost," it does not negotiate a counter. Potentials are coming from all over the place; the field does the work.
## The cost function is action: cost x latency The derivation happened live, with corrections (normalized here): - cost x time = **action** (the ℏ analogy: action is cost integrated over the duration the transaction sits in res potentia). - Resolved form: **cost x latency = action**, because higher latency means the transaction sits longer in res potentia, burning more action. A cheap route that takes 2 s has more action than an expensive route that connects in 50 ms. - Separately: cost x latency where latency is treated as a duration divisor gives **power** (energy per unit time). The two framings were disentangled in the transcript; the operative one for routing is **minimize the cost-latency product (least action)**. So potentialOffers weight themselves by action, and the acceptancePotential absorbs the offer with least total action, not least instantaneous cost. Tian's offer (cheap but slow, high latency) and a relay's offer (fast but expensive) stay both in flight because their action signatures differ; the peer chooses the smaller product at the moment of meeting. Noether/least-action framing: each offer-acceptance pair processing a quantum of action is a symmetry-breaking event. Ties to feedback_every-constraint-is-soft: least-action, bidirectional coherence over constraint links (bundle adjustment / factor graph reframed).
## Absorber / emitter, advanced / retarded waves The asymmetry is also absorber and emitter, with bidirectional advanced/retarded waves (Wheeler-Feynman flavor). An offer (retarded) and an acceptance (advanced) meet in the middle; the handshake is the transaction. This is the physics dress on the request/response and on the data-shed uphill/downhill flows ([03](03-data-shed-stac-watershed.md)).
## Nodes host the fields (not just listings) Stephen corrected the assistant twice here. The potentials are **published into the acequia pub/sub fabric**, flowing through the matrix, **and** every acequia node **hosts the field**: - A node exposes `/offerPotentials/` and `/acceptancePotentials/` URIs that are **live fields**, not static listings. As wave fronts propagate, they register in these fields so a peer can query the landscape at any node and see what is available and what is being sought. The field is the spatial representation of the wave fronts in res potentia, made queryable. - Example: `tian-device.local/offerPotentials/livetil.es/synergia-ranch/tx-area` returns all current offers for that tile stack, from Tian, from caches that copied it, from relays. - Permissions layer on top: `/offerPotentials/` may be open-read (anyone sees the field) while only token-authenticated peers may write (publish) offers. Access gated by the acequia access JSON. Ties to feedback_acequia-as-not-no-as (operational AS-role served by the peer mesh) and reference_token-minting-pattern.
## Per-peer, time-varying, asymmetric cost During the handshake (SIP-like), cost is asymmetric per peer. Tian's localhost server has ~zero accessibility cost for him (already there). A remote peer sees WebSocket-to-a-phone-behind-NAT as expensive accessibility and instead finds a *different* potentialOffer in the field with lower accessibility cost (a relay with WebRTC, a static-IP node, an existing cache). Tian's offer stays in res potentia, never actualizes, because the field had a cheaper path. He does not decide which connection technology; he just publishes the offer, and peers choose by their own cost function at query time. Cost axes are time-varying (battery 40% an hour ago, 15% now; a relay serving 3 peers, now 10).
## Open seams - How is the cost function communicated: advertise state periodically on a topic and compute routes, or discover cost through failure (try cheap, fall back, learn)? Probably probabilistic weighting by recency of state. - Who owns the state feed: a global topic (workgroup scale) or hierarchical rendezvous (a livetil.es server, a Cloudflare Worker, a base-camp Termux node) that aggregates and pushes summaries? That is the mayordomo/headgate. - When the cost function contradicts the STAC asymmetry (Tian is authoritative but at 5% battery, a downstream peer is cheaper): take stale-but-available for *rendering* and fetch from Tian separately to *verify* / build a provenance chain? (Transactional Twin: tile as offer, verification as confirmation.)