PaperlayerView exact revision on arXiv

Source-linked AI summary

GLP Networking API Specification

Dan Bachar, Ehud Shapiro

arXiv:2610.32583v1cs.NIcs.DCcs.PL

TL;DR

Mobile madGLP agents need peer discovery and connectivity across proximity and NAT-bound settings. This specification gives three underlays one API, combining recognition, rendezvous, Noise, and platform attestation. Attestations are verified against platform roots without third-party contact during session establishment.

  • Problem

    Agents must discover and contact nearby peers without infrastructure or trackability, while mobile agents behind NAT lack stable, directly observable public addresses.

    Source: §3 · p. 12, §4.2 · p. 14

  • Method

    The specification gives three underlays one API, using rotating proximity recognition, rendezvous-coordinated UDP hole punching, Noise authentication, and platform-root-verified attestation.

    Source: §1 · p. 2, §2.6 · pp. 7–8, §3.1 · p. 12

  • Results

    The layer specifies a common API over three underlays and verifies platform attestations against Apple or Google roots without third-party contact during session establishment.

    Source: §1 · p. 2, §2.6 · p. 8

  • Takeaways & Limitations

    Attestation protects only uses GLP restricts to attested peers, since a peer may instead declare itself unattested.

    Source: §2.6 · p. 8

    Android attestation provisioning and revocation status depend on Google contact, while iOS key attestation reaches Apple once and Apple documents no revocation.

    Source: §2.6 · p. 9

Abstract

from arXiv · show

Multiagent deterministic GLP (madGLP) runs Grassroots Logic Programs (GLP) as agents that communicate solely by asynchronous message passing, and assumes fair delivery: every message sent is eventually delivered. Each agent runs on a person's smartphone, named by the person's public key. A grassroots platform depends on no global resource but the network, so agents must reach one another over Bluetooth Low Energy, on a local network, and across the Internet from behind NAT, via rendezvous servers anyone can run. What madGLP requires of such a network, and what the network requires of the platform, has not been specified. We specify the networking layer beneath madGLP. Anything that can be done in GLP is done in GLP: the layer provides only what GLP cannot reach - the network stack, the location service, application attestation, and cryptographic primitives. Three transport underlays share one interface. Over PAN and LAN, an agent advertises a rotating recognition token derived from its key and time slot, so a peer who knows the key recognises it before contact and nobody else can track it; whether it answers unrecognised contacts is a per-underlay trust level set by GLP. Over WAN, a rendezvous server is a static-address host running the headless layer and a GLP rendezvous agent that coordinates hole punching, relays no payload, and belongs to no social graph. On every underlay, peers establish a mutually authenticated Noise session from Ed25519 keys, then attest, bound to the handshake hash, that each runs the application published under its developer's key, verified against Apple's and Google's roots with no third party contacted. One message protocol, over UDP datagrams and GATT writes, provides the fair, unordered, atomic and authenticated delivery madGLP assumes.

1 Introduction

The specification defines the networking layer beneath madGLP, while GLP retains social-graph and peer-management logic. A shared API spans proximity and Internet underlays, with each providing a different way for agents to connect.

1 Introduction

  • The layer supplies network access, location, attestation, and cryptographic primitives; social graphs, friendship, address distribution, reconnection, and rendezvous protocol remain GLP code.Messages are opaque payloads to the networking layer.Source: §1 · p. 2
  • The underlay-agnostic API lets madGLP use one public-key overlay across three underlays, while some control operations remain underlay-specific.PAN and LAN discovery spans both proximity underlays; observing an agent’s public address is IP-only.Source: §1 · p. 2
  • PAN supports offline, infrastructure-free communication between nearby devices and serves as the face-to-face bootstrap underlay.LAN uses local-network discovery and IP; WAN uses UDP and rendezvous servers for signaling and NAT traversal.Source: §1 · p. 2

2 Networking API

The runtime calls an underlay-agnostic networking interface, and the layer implements the selected underlays. Peer identity is a persistent Ed25519 public key; deployments may run any subset of underlays.

2 Networking API

  • The runtime issues the same networking calls regardless of transport, while PAN, LAN, and WAN realizations carry them.The interface connects the runtime to the layer beneath it.Source: §2 · p. 3

2.2 Instantiation

  • An agent can implement any subset of PAN, LAN, and WAN and remain conforming; unimplemented underlays have no discovery presence or sub-object.The layer exposes functions on itself when they span underlays and on an underlay sub-object when they are specific to it.Source: §2 · p. 3, §2.2 · p. 4

2.1 Identity

  • Each agent’s persistent 32-byte Ed25519 public key serves as its identity for addressing, authentication, and signing.The key pair is supplied when the layer is instantiated; key rotation or device moves use another pair.Source: §2.1 · p. 3

2.3 Connection and Reachability

The layer reports peer reachability and attestation status to the runtime, while GLP decides how to use that information. A known-peer set and ANNOUNCE records support trust checks, identity bootstrap, liveness, and reconnection.

2.3 Connection and Reachability

  • Peer reachability reports identify the available underlays and attested application, leaving path selection to the layer and use of unattested peers to GLP.GLP can use PAN reachability to identify which friends are physically nearby.Source: §2.3 · p. 4

2.4 Known Peers

  • The known-peer set stores keys supplied by GLP, not friendships; it governs recognition, unsolicited WAN contact checks, reconnection, and recorded addresses.Removing a key also removes its recorded address.Source: §2.4 · p. 5

2.5 ANNOUNCE and Liveness

  • On PAN, ANNOUNCE can supply the key for an unrecognized first contact under Open trust and provides a second liveness check for links without surfaced disconnects.A stale PAN connection is severed on both GATT legs before a disconnect is synthesized.Source: §2.5 · p. 6
  • On LAN and WAN, ANNOUNCE detects silent UDP sessions; two missed intervals tear down a session and trigger a disconnect, while heartbeats also drive reconnection and queued-message replay.LAN may use ANNOUNCE to bootstrap identity on a first contact under Open trust; WAN already expects the peer’s key.Source: §2.5 · p. 6

2.6 Session Establishment

Peers establish per-underlay Noise sessions using Ed25519 identities, then exchange attestation before becoming reachable. Attestation is bound to the session, but platform proofs and their limits differ.

2.6 Session Establishment

  • Noise mutually authenticates Ed25519 key holders and derives forward-secret session keys; a peer becomes reachable only after the handshake and attestation exchange complete.Each underlay has a separate session between a pair of peers.Source: §2.6 · p. 7
  • When the initiator knows the responder key, Noise IK encrypts its first message to that key; an unrecognized first contact under Open trust uses XX and verifies keys against ANNOUNCE.Closed-trust responders reject unknown IK keys and all XX first messages.Source: §2.6 · p. 7
  • Each session’s attestation signature binds the application version and identity key to the final Noise handshake hash, preventing replay onto another session.Peers verify attestations against platform roots; an offered but invalid attestation tears the session down.Source: §2.6 · p. 8
  • Attestation proves that a genuine application holds the identity key, not that the key’s owner does; a copied key on another machine opens only unattested sessions.A genuine application that imports a key attests it like a key it generated.Source: §2.6 · p. 8
  • Android provisioning and revocation status depend on Google, whereas iOS key attestation contacts Apple once and documents no revocation; neither vendor is contacted during a session.A device that has never reached Google cannot attest; a verifier that never reaches Google does not learn that a key has been revoked.Source: §2.6 · p. 9
  • Attestation identifies the developer, application name, and version, but neither platform measures running code; the version is the application’s signed undertaking.Android’s certificate chain can be forged on a device with a modified operating system, bounding the claim against modified systems.Source: §2.6 · p. 9

2.7 Geofencing

The layer registers named geofences and reports entry or exit events to GLP without passing along location coordinates. Those reports depend on platform observability; crossings during unobservable periods are lost.

2.7 Geofencing

  • GLP registers a named circular geofence with a radius in metres, and the layer reports each crossing as an entered or exited event.A second declaration of the same place replaces the first; removePlace unregisters it.Source: §2.7 · p. 9
  • Geofence events carry the place name and crossing direction, but no coordinates reach the runtime or a peer through the layer.GLP, not the networking layer, decides what a place means.Source: §2.7 · p. 9
  • When the platform stops reporting crossings, the layer reports the device as unobservable; crossings during that period are lost and not replayed.Reporting stops in the background or when location permission is withdrawn, and resumes when the condition is reversed.Source: §2.7 · pp. 9–10

2.8 Cold Calls

A cold call is a first-contact attempt between agents without an active channel. GLP sets independent PAN and LAN trust levels that govern whether unsolicited proximity contacts are answered.

2.8 Cold Calls

  • A cold call is a first-contact connection attempt between agents that do not already share an active communication channel.It may occur over PAN, LAN, or WAN between agents whose programs have declared each other's keys; its meaning is GLP-level, not part of the networking layer.Source: §2.8 · p. 10
  • Open trust completes contact with unknown proximity peers, while Closed trust ignores unmatched PAN and LAN encounters and reveals the key only to known peers.Open trust uses ANNOUNCE and a Noise XX handshake; Closed trust answers an IK handshake only from a known key.Source: §2.8 · p. 10
  • PAN and LAN trust levels are set independently and both default to Closed.GLP can set each level using setTrustLevel on that underlay's sub-object.Source: §2.8 · p. 10
  • Unsolicited WAN contact is refused unless the peer is known, except that a rendezvous server answers any key.An inbound IP contact from a source address within the agent's local prefixes is treated as LAN contact and governed by LAN trust.Source: §2.8 · p. 10

2.9 Point-to-Point Communication

The layer provides reliable byte-payload delivery between peers identified by public key. Its shared message protocol and networking assumptions specify how delivery remains complete and authenticated across underlays.

2.9 Point-to-Point Communication

  • The layer reliably delivers arbitrary byte payloads between peers identified by public key.The runtime sends with send(pubKey, payload) and receives reassembled payloads through onMessageReceived.Source: §2.9 · p. 11

2.10 Message Protocol

  • The shared protocol fragments messages for UDP datagrams or BLE GATT writes, acknowledges and retransmits fragments, then reassembles each message before delivery.A bounded per-peer send window and backoff govern retransmission; exhausted attempts tear down the session and queue the message for the next path.Source: §2.10 · p. 11
  • A retransmission after a lost acknowledgment may deliver a message more than once, and message order is not promised.madGLP deduplicates repeated deliveries; a lost fragment delays only its own message.Source: §2.10 · p. 11

2.11 Networking Assumptions

  • Every message sent is eventually delivered at least once if the recipient eventually becomes reachable, with queued messages surviving application termination.Concurrent messages may arrive in any order, but each is delivered atomically, with integrity and sender authentication.Source: §2.11 · pp. 11–12

3 Proximity Underlays: PAN and LAN

The proximity underlays let nearby agents discover and contact one another without infrastructure, including offline over BLE. Their shared design recognizes known peers before contact while allowing GLP to control responses to unknown contacts.

3.1 Concepts and Principles

  • A rotating 8-byte token derived from the public key, time slot, and underlay label lets known peers recognize an agent before contact without giving others a stable identifier.Adjacent-slot matching absorbs clock skew, and the advertisement carries no public key.Source: §3.1 · p. 12
  • Under Open trust, unmatched proximity presences can be contacted or answered; under Closed trust they are ignored, with PAN and LAN levels independent.Recognized peers are contacted using an IK handshake; Open-trust unknown contacts use ANNOUNCE followed by XX.Source: §3.1 · pp. 12–13

3.2 LAN

  • LAN agents discover one another through DNS-SD over multicast DNS, advertising the rotating token as a service instance whose SRV record carries the LAN address and UDP port.A matched instance yields an address for UDP contact.Source: §3.2 · p. 13

3.3 PAN

  • PAN provides offline, infrastructure-free communication between devices in direct radio range and is the bootstrap underlay for first face-to-face encounters.Its carrier is Bluetooth Low Energy.Source: §3.3 · p. 13

3.3.1 Advertising and Recognition

  • A BLE advertisement combines a fixed 8-byte Grassroots prefix with the rotating recognition token, and the token is refreshed when its time slot ends.On iOS, background advertising is discoverable only by a scanner for the exact UUID, so strangers need the app in the foreground.Source: §3.3.1 · pp. 13–14

3.3.2 Connection and Identity

  • After a recognized BLE connection, peers establish an IK session; an unknown presence under Open trust first exchanges ANNOUNCE and then runs XX.No Bluetooth bonding or pairing confirmation is required.Source: §3.3.2 · p. 14

3.3.3 Communication

  • PAN communication sends payloads over the established GATT connection using the shared message protocol, with fragmentation and reassembly before runtime delivery.GATT writes carry the fragments.Source: §3.3.3 · p. 14

4 WAN Underlay

The WAN realization carries the message protocol over UDP and uses rendezvous agents for signaling and NAT traversal. It also specifies connection, address-recovery, local-network identity, cold-call, and message-delivery behavior.

4 WAN Underlay

  • WAN communication uses UDP datagrams and rendezvous agents for signaling and NAT traversal.The rendezvous protocol itself is GLP code.Source: §4 · p. 14

4.1 WAN Connection

  • Peers establish a session after a UDP path forms; when both may initiate, the endpoint with the smaller public key initiates, and two silent intervals trigger disconnection.ANNOUNCE serves as the liveness check because UDP has no connections.Source: §4.1 · p. 14

4.2 Connectivity and Address

  • When an address change breaks UDP paths, the moved endpoint reconnects to known peers and rendezvous servers; GLP distributes fresh addresses to peers that cannot be reached directly.Peers can receive addresses through surviving channels or a BLE-adjacent friend, then reconnect using the layer functions.Source: §4.2 · pp. 15–16

4.3 Local Network Identity

  • The layer reports an opaque, best-effort local-network fingerprint; a match is evidence, not proof, that the agent is on the same network.The fingerprint may be unavailable or identical across distinct networks.Source: §4.3 · pp. 16–17

4.4 WAN Cold-Call

  • A WAN cold call requires mutually declared peer keys, a UDP connection, and a session before the caller sends the payload to the callee’s index-0 serializer.How peers learn each other’s keys is out of scope for this layer.Source: §4.4 · p. 17

4.5 WAN Communication

  • WAN send transmits session-encrypted fragments in UDP datagrams, and message receipt delivers complete, reassembled messages to the runtime.Source: §4.5 · p. 17

5 The Seam: Layer Functions behind the System Predicates

The seam specifies layer functions behind GLP system predicates, keeping underlay-specific operations in the layer while GLP agents use the predicates. Replacing an underlay changes the layer implementation, not the GLP code.

5 The Seam: Layer Functions behind the System Predicates

  • Ten system predicates expose address observation, UDP hole punching, geofences, trust levels, peer management, and rendezvous-server declaration through GLP.The language and implementation papers define the predicates and their clauses; this section specifies the functions behind them.Source: §5 · pp. 17–18
  • Changing the underlay or traversal mechanism changes only the layer’s implementation of the functions; GLP code using the predicates remains unaffected.Source: §5 · p. 18
  • The layer registers and removes geofences and reports entered or exited events when the platform reports a crossing.Events may be unobservable while platform reporting is stopped, such as when the application is backgrounded or permission is withdrawn.Source: §5 · p. 18
  • The layer supplies Ed25519 signing and verification, while the runtime adds the signing program’s source identity for the language-level predicates.The layer does not learn about programs or friendships.Source: §5 · pp. 18–19

6 Rendezvous Server

A rendezvous server gives NAT-bound agents a fixed, globally reachable point for address discovery and UDP hole-punch coordination. The server does not relay payloads, and this section specifies hosting requirements rather than the rendezvous agent or its protocols.

6 Rendezvous Server

  • A rendezvous server is a host with a static, globally routable address running a lightweight GLP rendezvous agent, providing NAT-bound agents a fixed outbound-reachable point.Agents use it to discover public addresses and coordinate UDP hole punching.Source: §6 · p. 19
  • The section specifies hosting requirements only; the rendezvous agent and the reconnection and first-contact protocols are out of scope.Source: §6 · p. 19
  • On connection, the server observes an agent’s source address and exposes it for public-address discovery without external STUN infrastructure.Source: §6 · p. 19
  • The server relays observed addresses for hole-punch coordination but never forwards madGLP payloads; when direct connectivity fails, relaying is an application-level concern handled in GLP.The peers establish Noise and exchange messages directly once a UDP path forms.Source: §6 · p. 19
  • Any individual or organization can run servers independently, and agents may use several or none when communicating over PAN or LAN.Rendezvous servers do not communicate with one another.Source: §6 · p. 20

7 Complete API Summary

The complete API groups underlay-agnostic layer calls separately from proximity and WAN sub-object calls. It connects runtime operations and callbacks with the GLP predicates they support.

7 Complete API Summary

  • The API summary distinguishes five underlay-agnostic groups from Proximity calls on PAN/LAN and WAN calls on the WAN sub-object.The table maps system predicates to the layer functions specified in Section 5.Source: §7 · p. 20

Known peers

  • Known-peer operations add or remove recognized keys and report peer connections or disconnections with the reachable underlay and attested application, if any.Source: Known peers · p. 20

Communication

  • Communication operations implement madGLP send and receive, while the API also exposes Ed25519 signature verification.Source: Communication · p. 21

Proximity underlays (PAN and LAN)

Loading 2610.32583v1…