GAOTH PROTOCOL/REV 0.1 DRAFT — NOT FOR DISTRIBUTION

Delay-Tolerant Content Resolution Protocol · Draft 0.1

GAOTH

/ ɡeɪ / — Irish: wind

A delay-tolerant content resolution protocol that operates when everything else has failed or not yet succeeded. Signed declarations of desire that propagate until fulfilled, clean up after themselves, and treat every transport as equivalent.

Status
Draft 0.1
Primitives
4 message types
Transport
Agnostic
Failure State
None

Section 01

Motivation

The internet's origin is a clean design principle: route a packet toward its destination using whatever path is available, and let the network — not the sender — be responsible for delivery. ARPANET's insight was not redundant paths. It was that the packet only needs to know where it is going, not how it gets there. Silence, by convention, means success.

Decentralised infrastructure has mostly inherited a simpler model: resolve a clearnet address, fetch directly. This works when infrastructure is stable. It fails — and fails permanently — when an origin goes offline, is censored, or sits behind unstable connectivity.

The question every modern decentralised protocol eventually faces is: how do you get this content to this user via whatever pathway is available?

Gaoth is Irish for "wind." It moves without infrastructure, finds its way through gaps, and leaves no trace when it has done its work.

Section 02

Design Principles

Five constraints that make Gaoth possible.

2.1
Address by Identity, Not Location

The critical shift that makes Gaoth possible is the same shift ARPANET made. A content hash plus author public key is a stable identity that does not change when a server moves, goes down, or becomes unreachable. A node holding a WANT does not need to know where the content currently is — only what it is. The routing layer discovers location opportunistically.

2.2
The Network Is Responsible for Delivery

The sender issues a WANT once. They do not retry, poll, or manage delivery logic. Every node that touches the WANT takes responsibility for re-asking on the next wakeup event. Delivery emerges from patience and opportunism, not coordination.

2.3
Silence Is Valid

Gaoth does not distinguish between "content does not exist" and "content is not currently reachable." A WANT that expires simply disappears. The requester can re-issue it. There is no failure state — only an unfulfilled want.

2.4
Transport Agnosticism

Gaoth does not care how its primitives are transmitted. A WANT can travel over clearnet HTTP, BLE proximity exchange, store-and-forward relay, or any future transport binding. The protocol layer is always the same. The transport beneath it is always interchangeable.

2.5
Self-Cleaning

Every WANT has a TTL. Every fulfilled WANT issues a RESOLVED signal. Nodes that receive RESOLVED discard their queued WANTs and any bundles they were carrying. The network sheds load the moment delivery is confirmed, without any central coordination.

Section 03

The Four Primitives

Gaoth is defined entirely by four message types. There are no other operations.

WANT
Propagates outward · from requester

A signed declaration of desire. Issued by a requester when content cannot be resolved directly or from local cache. Propagates outward through any available transport.

  • hashthe content hash being requested; the complete routing key
  • requester_keypublic key; proves authorship of the WANT
  • return_addresswhere to send the fulfilled bundle; explicitly ephemeral
  • ttlexpiry timestamp; nodes discard silently after this time
  • noncerandom value preventing re-propagation loops
  • signaturesigns all fields with requester_key
HAVE
Propagates inward · toward requester

A signed availability announcement. Issued by any node that holds content matching a hash it has seen in a WANT. A HAVE is not a push — it is a notice. The requester decides whether to pull.

  • hashthe content hash being announced
  • holder_keyannouncing node's public key
  • address_hintcurrent reachable address; timestamped and versioned
  • timestampfreshness marker; used to deprioritise stale hints
  • signaturesigns all fields with holder_key
CARRY
Operational mode · relay node state

A bundle in physical transit. A node that cannot immediately deliver holds it and attempts delivery on subsequent wakeup events. CARRY is not a separate message format — it is the operational mode of a node holding an undelivered bundle.

  • relay handshaketwo nearby nodes declare their CARRY inventory on encounter
  • bundle exchangetransfer bundles destined for keys either party is closer to
  • relay nodeany device running CARRY continuously on behalf of requesters it has encountered
RESOLVED
Issued by requester · proves receipt not delivery

A signed confirmation of receipt. Issued by the requester — not the delivering node — when a bundle has been received and its signature verified. A node cannot fabricate a RESOLVED on a requester's behalf.

  • drops WANTevery touched node removes WANT from queue
  • discards CARRYany held bundle for that requester and hash is released
  • marks HAVErequester becomes a new availability source; the HAVE map grows richer

RESOLVED's third effect — marking the requester as a new HAVE source — is the emergent property that makes Gaoth self-improving. Every delivery redistributes availability. The next WANT for the same hash has a shorter path.

Section 04

Protocol Lifecycle

A single WANT from issuance through propagation, resolution, and cleanup. Wakeup events transform a static declaration into an opportunistically-persistent query.

GAOTH-LIFECYCLE v0.1
WANT → HAVE → CARRY → RESOLVED
CARRY · bundle in transit
relay holds · re-attempts on wakeup
Requester
holds WANT queue
WANT
HAVE
Gaoth network
transport-agnostic
clearnet · proximity · relay · radio
WANT propagates out · HAVE propagates in
WANT
HAVE
Holder
signs HAVE
RESOLVED · signed by requester · proves receipt
all nodes drop WANT · discard CARRY · requester becomes HAVE source
Peer Encounter
new peer nearby
Clearnet Restore
network path up
New Address Info
fresher HAVE hints
Timer
background interval
TTL expires → WANT silently discarded · no failure state · requester decides to re-issue or abandon
Fig. 1 — Full WANT lifecycle. WANT propagates outward; HAVE propagates inward; CARRY holds bundles in transit; RESOLVED clears all state and redistributes availability. TTL expiry yields silent discard — there is no error path.

Section 05

Wakeup Events

A node holding outstanding WANTs does not continuously poll for resolution. It waits for a wakeup event — a signal that new resolution opportunities may have become available — then re-attempts all outstanding WANTs against whatever transports are now accessible.

Peer Encounter

A new peer has appeared in proximity. Re-ask all outstanding WANTs to this peer and exchange CARRY inventories.

May simultaneously provide a new peer, fresh address hints, and CARRY bundles — all processed in the same cycle.
Clearnet Restoration

A network path has become available after being offline. Re-attempt all outstanding WANTs via known-node HTTP.

Triggered when the client detects network access has resumed after a gap.
New Address Information

Fresh address hints have arrived. Re-evaluate outstanding WANTs using the updated HAVE information.

Resolution becomes a confidence-weighted lookup rather than a fixed-order waterfall.
Timer Expiry

A background interval fires. Re-attempt outstanding WANTs against any currently-available transport.

Fallback for environments where event-driven wakeups are unreliable.

Deduplication and Loop Prevention

When a WANT propagates to multiple nearby devices simultaneously, all of them could attempt to fulfil it. The nonce field prevents this from amplifying into noise.

The Rule

A node that has seen a nonce does not forward it again. Nodes maintain a seen-nonces cache with TTL-aligned expiry. A nonce is held until its corresponding WANT's TTL would have expired, then discarded. This bounds memory without coordination.

Section 06

The ARPANET Parallel

ARPANET's design insight was not technical. It was philosophical: make the network responsible for delivery, make the sender responsible only for addressing, and let silence mean success. The IMP (Interface Message Processor) was the world's first store-and-forward relay node — it held packets, re-attempted on connectivity events, and issued acknowledgments that let senders release their buffers.

Gaoth is the same architecture applied to content resolution in a decentralised, censorship-resistant context.

ARPANETMaps toGaoth
The packet addresses by identity, not location The WANT — identity-addressed, transport-agnostic
The IMP store-and-forward relay The relay node running CARRY — holds, re-attempts, and forwards
Connectivity event triggers re-attempt Wakeup event — proximity, clearnet restoration, new information
IMP acknowledgment lets senders release buffers RESOLVED — lets every node in the chain discard its state
Silence no failure state Expired TTL — valid outcome; requester re-issues or abandons

The network is not infrastructure. The network is the aggregate patience of every node that has agreed to carry a WANT until it finds what it is looking for.

Section 07

Summary

Gaoth is defined completely by:

· Four message types: WANT, HAVE, CARRY, RESOLVED
· Four wakeup events: peer encounter, clearnet restoration, new address information, timer
· One deduplication rule: a node that has seen a nonce does not forward it again
· One field that carries the requester's current reachability: return_address, explicitly ephemeral

Four messages. One ephemeral address field. A network that is dumb, patient, and self-cleaning. This is the complete protocol.

Section 08

Open Questions

The following remain unspecified and are noted for future protocol work.