AGTP Presence: Ambient Discovery and Visibility for Agents

1.1. The Addressing Abstraction

The question put to this work on the IETF lists is the right one to answer in the document itself: over what protocol, and to what address. Over AGTP, to a Canonical Agent-ID. The protocol resolves the Agent-ID to the agent's current attachment (Section 2.1.1) and routes between conventionally addressed nodes; the application layer never sees an IP address, in the way a user of a filesystem never sees a disk sector although the sector exists and the data is on it. The address becomes the network's concern and leaves the agent's view.¶

The model therefore scales with identity; addresses come and go beneath it. Light clients hold no routing state; relay-mediated agents hold no routable endpoint of their own. Routable addresses scale with the number of full nodes and relays; agents scale with the number of identities. Ten full nodes can carry a scope of a million ephemeral agents, because what the ten nodes hold is a million attachments keyed by Agent-ID, which is to say a million 32-byte keys and the short signed records they point to. Show up, get absorbed, get routed.¶

1.2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses terminology from [AGTP], [AGTP-IDENTIFIERS], [AGTP-TRUST], [AGTP-CERT], and [AGTP-DISCOVERY]. Selected additional terms specific to this document:¶

Presence:

The state of an agent being known to other agents within an applicable visibility scope as a result of joining the AGTP substrate, without requiring explicit registration with a directory.¶

Attachment:

The signed, short-lived, updatable record of where an agent can currently be reached: the substrate node or relay that holds the agent's connection, the binding it is reachable over, and a validity window. The Canonical Agent-ID is permanent identity; the attachment is its current location and changes without the identity changing. An ANNOUNCE publishes an attachment; a PROBE returns one. See Section 2.1.1.¶

Discover, Search, Resolve:

As defined in [AGTP-DISCOVERY] following [RFC6763]. Presence provides discovery: a known Agent-ID to its attachment. Search (criteria to candidates) is the DISCOVER method of [AGTP-DISCOVERY] and runs over Presence. Resolve (name to Agent-ID) is the Agent Name Service. Where earlier revisions of this document said "discovery query" for what a light client sends to a relay, this revision says search query or attachment lookup as the case requires.¶

Visibility Scope:

The set of other agents that can observe a given agent's presence. Determined by the agent's certificate-declared visibility posture and the requesting agent's trust tier, governance domain, or explicit group membership.¶

Bootstrap Peer:

An AGTP agent or service that accepts initial connections from new agents joining the network and provides initial routing table state for DHT participation.¶

Light Client:

A participation mode in which an agent maintains no DHT routing state but communicates with full-node peers for presence announcement, attachment lookup, and search.¶

Full Node:

A participation mode in which an agent maintains DHT routing tables, participates in gossip, and serves attachment lookups and search queries for other agents.¶

Relay:

A full-node agent that accepts presence announcements, attachment lookups, and search queries on behalf of light-client agents.¶

2.1. DHT Over Canonical Agent-IDs

Canonical Agent-IDs as defined in [AGTP-IDENTIFIERS] are 256-bit SHA-256 hashes of Agent Genesis documents. This makes them content-addressable identifiers compatible with distributed hash table addressing.¶

AGTP Presence specifies a Kademlia-style DHT [KADEMLIA] keyed by Canonical Agent-ID. Full-node agents maintain k-bucket routing tables of size k=20. Lookups proceed via XOR distance metric. Parallel lookups (alpha=3) reduce latency and provide resistance against eclipse attacks per the S/Kademlia hardening approach [SKADEMLIA].¶

The DHT supports three operations:¶

• FIND_NODE: Given a target Agent-ID, returns the k closest agents the responding node is aware of. Used during DHT routing.¶

• PROBE: Given an Agent-ID, queries whether the agent is currently reachable and what its declared visibility posture is.¶

• ANNOUNCE: Publishes presence information into the DHT, replicated across the k closest nodes to the announcing agent's Agent-ID.¶

DHT operations are carried as AGTP requests on the AGTP substrate, authenticated via the AGTP wire-level identity (Agent-ID and Request-Signature, with Owner-ID resolved from the Identity Document per [AGTP-IDDOC], and the certificate where deployed) and verified per [AGTP-TRUST].¶

{
  "agent_id":   "<64 lowercase hex>",
  "node":       "<Agent-ID of the full node or relay holding the connection>",
  "binding":    "tcp-tls" | "quic" | "h3",
  "endpoint":   "<host:port the node accepts AGTP on, or null for relay-mediated>",
  "mode":       "full" | "light" | "relayed",
  "iat":        <seconds since epoch>,
  "exp":        <seconds since epoch; MUST be within the presence TTL>,
  "seq":        <monotonic sequence number per Agent-ID>
}

2.2. Gossip-Based Presence Convergence

In parallel with DHT-based addressing, AGTP Presence uses a gossip-based protocol for presence announcement and state convergence within a visibility scope. The gossip mechanism is informed by production systems such as Serf [SERF] and uses the following properties:¶

• Each full-node agent maintains a list of known peers within its applicable visibility scopes.¶

• At configurable intervals (default 5 seconds, operator-tunable), the agent selects a small random subset (default fanout 3) of known peers and exchanges presence state.¶

• Presence announcements include the announcing agent's Agent-ID, its declared visibility posture (from its AGTP-CERT extension), a timestamp, and a JWS signature over the announcement.¶

• Receiving agents verify the signature against the announcing agent's certificate before incorporating the announcement into their local presence state.¶

• Conflicting announcements for the same Agent-ID (different presence states, different timestamps) are resolved by selecting the most recent validly signed announcement.¶

Gossip propagation converges across a scoped population in seconds to low tens of seconds at scopes of thousands of agents. Implementations MAY tune gossip intervals and fanout for their operational requirements. The protocol behavior is normatively specified; numerical parameters are operator-defined.¶

2.3. Scoped Overlay Partitioning

Presence in AGTP is a scoped property. Visibility is partitioned across overlapping scopes determined by the trust tiers and verification paths defined in [AGTP-TRUST], the visibility posture declared by each agent's certificate, and the operational dimensions agents use for search: capability, industry, region.¶

This document specifies a federation-of-scoped-overlays model. A flat global DHT containing all agents would impose unnecessary participation cost on every node. The scoped partitioning model means most agents participate in views containing thousands to tens of thousands of relevant peers within bounded scopes, with deterministic resolution into other scopes when cross-scope reach is needed.¶

This mirrors how internet routing scales: BGP operates as a federation of independently operated systems with controlled inter-AS routing. AGTP Presence adopts the same architectural pattern for agent populations, with the partition axes chosen for their meaning to agent search; network topology plays no part in them.¶

3.1. Full Node

A full-node agent maintains DHT routing tables, participates in gossip exchanges with peers, accepts incoming DHT queries, and optionally serves as a relay for light-client agents.¶

Full-node agents MUST be reachable at a stable AGTP endpoint during their participation lifetime. Full nodes SHOULD have predictable availability and SHOULD NOT be subject to frequent churn.¶

Typical full-node deployments include enterprise gateways, long-lived infrastructure agents, organizational agent directories, and dedicated relay services.¶

3.2. Light Client

A light-client agent maintains no DHT routing tables or participate in gossip directly. Instead, the light-client agent communicates with one or more full-node peers (typically operated by the same Owner-ID or trusted relay services) for presence announcement and attachment lookup and search operations.¶

Light-client agents announce their presence to their chosen full-node peers, which then propagate the announcement into the DHT and gossip layer on their behalf. Search queries from light-client agents are forwarded by full-node peers, with results returned to the light client.¶

Light-client mode is appropriate for resource-constrained agents, ephemeral task agents with short lifetimes, mobile or intermittent agents, and consumer agents where DHT participation cost is disproportionate to their search needs.¶

3.3. Relay-Mediated

A relay-mediated agent operates entirely through a relay full-node. The relay receives all incoming and outgoing presence and search traffic for the relayed agent. From the network's perspective, the relay appears to be the addressable participant; the relayed agent's Agent-ID is associated with the relay endpoint.¶

Relay-mediated mode is appropriate for agents behind NAT or firewall boundaries, for agents with intermittent connectivity, and for deployments where direct DHT participation is operationally infeasible.¶

Relays MUST preserve the cryptographic integrity of the relayed agent's identity and MUST NOT modify presence announcements or search responses on behalf of the relayed agent without explicit agent consent.¶

4.1. ANNOUNCE

The ANNOUNCE method publishes an agent's presence into the AGTP Presence layer. An agent invokes ANNOUNCE upon joining the network, when its visibility posture changes within the bounds permitted by its certificate, or as a periodic refresh of its presence state. The first ANNOUNCE is a consequence of the agent's ACTIVATE transition ([AGTP]): the agent MUST announce within the presence TTL of becoming Active, and a DEACTIVATE, REVOKE, or DEPRECATE transition MUST be followed by WITHDRAW. Activation is therefore the single publish act; ANS registration ([AGTP-DISCOVERY]) and presence announcement both follow from it.¶

ANNOUNCE requests are sent to one or more peer agents within the sender's visibility scope. The receiving agents validate the announcement signature, incorporate the announcement into their local presence state, and propagate the announcement via gossip subject to the visibility rules declared by the announcing agent.¶

Request semantics:¶

• Idempotent: Yes (same announcement state may be sent repeatedly)¶

• Authority-Scope: presence:announce REQUIRED¶

• Response: 200 OK with current peer presence state, or 404 if the receiving agent is outside the announcing agent's visibility scope¶

4.2. WITHDRAW

The WITHDRAW method removes an agent's presence from the AGTP Presence layer prior to disconnection. WITHDRAW is the explicit opposite of ANNOUNCE and signals graceful exit from the network.¶

WITHDRAW requests propagate via gossip and remove the agent's presence record from peer state. Agents that omit WITHDRAW before disconnection have their presence eventually expired via TTL-based record aging.¶

Request semantics:¶

• Idempotent: Yes¶

• Authority-Scope: presence:withdraw REQUIRED¶

• Response: 200 OK on successful withdrawal acknowledgment¶

4.3. PROBE

The PROBE method queries the current state of a specific agent. PROBE is used during DHT lookups for liveness verification, by search clients evaluating returned peer lists, and by monitoring systems checking agent availability.¶

PROBE responses are filtered by the responding agent's visibility posture. An agent whose visibility posture excludes the requesting agent MUST return a 404 response, indistinguishable from a response indicating the agent is unknown. This refusal enforces the invisible presence mode.¶

Request semantics:¶

• Idempotent: Yes¶

• Authority-Scope: presence:probe REQUIRED¶

• Response: 200 OK with current presence state, 404 if the agent is outside the requesting agent's visibility scope or unknown¶

5.1. Presence Visibility

Presence visibility determines whether the agent appears in ambient search at all. The following modes are defined:¶

Invisible-mode agents remain on the AGTP substrate and are reachable by other agents that already possess the Invisible agent's Agent-ID. The invisible mode applies to search results; direct addressing by Agent-ID is unaffected.¶

5.2. Disclosure Visibility

Disclosure visibility determines what attributes are advertised about an agent that is itself visible. The following modes are defined:¶

Agents in existence-only disclosure mode are visible in search results but advertise no operational metadata. Searching agents that wish to learn more must invoke explicit AGTP methods (DESCRIBE, QUERY) against the discovered agent, which the agent may then authorize or deny.¶

5.3. Audience Scoping

Audience scoping further constrains which agents may observe a visible agent. Audience scoping composes with presence visibility: an agent in public presence mode with restricted audience scoping is visible only to the specified audience even though its presence mode would otherwise allow broad visibility.¶

The following audience scope expressions are defined:¶

The capability expression composes with the capability partition dimension: an agent restricting its audience to capability:settlement is visible only to other agents that have bound the settlement capability through the method library, regardless of which scope they joined to make the search.¶

Audience expressions MAY be combined with logical operators (AND, OR, NOT) in the certificate extension to express compound audience constraints.¶

5.4. Certificate Extension Schema

Visibility posture is declared in an AGTP-CERT extension. The extension OID and schema are defined in Section 10. The extension carries three required fields corresponding to the three visibility axes:¶

PresenceVisibilityExtension ::= SEQUENCE { presenceMode PresenceMode, disclosureMode DisclosureMode, audienceScope AudienceExpression } ¶

The visibility posture declared in the certificate is the maximum envelope within which the agent may operate. Runtime visibility may be reduced within this envelope via the Presence-Mode header on ANNOUNCE and outbound AGTP requests, but MUST NOT exceed the certificate-declared envelope.¶

5.5. Runtime Mode Signaling

Agents MAY adjust their effective visibility at runtime within the envelope declared by their certificate. The Presence-Mode header on outbound AGTP requests signals the agent's current operational visibility mode. Receiving agents MUST honor the declared runtime mode when generating presence announcements or PROBE responses.¶

For example, an agent whose certificate declares presenceMode: public may temporarily operate as presenceMode: invisible by signaling Presence-Mode: invisible on its requests. The agent cannot exceed its certificate envelope (cannot upgrade from owner-domain to public) but may reduce visibility within it at any time.¶

6.1. Multi-Seed Bootstrap

Agents joining the network SHOULD maintain a list of at least three bootstrap peers operated by independent parties. Bootstrap peer lists MAY be obtained from:¶

• AGTP-CERT certificate authorities, which include bootstrap peer hints in issued certificates¶

• DNS-anchored seed records published under operator domains¶

• Configuration provided by deployment tooling¶

• Previously discovered AGTP peers from prior sessions¶

Agents SHOULD rotate their bootstrap peer list periodically and SHOULD NOT depend on a single bootstrap operator indefinitely.¶

6.2. Trust-Tier-Specific Bootstrap

Tier 1 Verified, Tier 2 Org-Asserted, and Tier 3 Experimental agents MAY use distinct bootstrap peer lists appropriate to their tier. Tier 1 bootstrap peers, in particular, are typically operated by institutional participants (financial institutions, regulated entities, standards bodies, certificate authorities) with operational accountability for their bootstrap services.¶

6.3. Governance-Driven Bootstrap Rotation

Bootstrap peer lists MAY be rotated through governance processes defined in [AGTP-TRUST], including periodic refresh of authorized bootstrap operators and revocation of bootstrap peers that fail to meet operational requirements.¶

7.1. Sybil Resistance

Attackers may attempt to flood the network with falsified agent identities to gain disproportionate influence over routing, gossip propagation, or search results.¶

Mitigations:¶

• All Agent-IDs are 256-bit SHA-256 hashes of Agent Genesis documents per [AGTP-IDENTIFIERS]. Generating a target Agent-ID for a specific DHT region requires brute-forcing the hash preimage, which is computationally infeasible.¶

• AGTP-CERT requirements per [AGTP-CERT] bind Agent-IDs to issuing authority chains. Sybil attacks require obtaining valid certificates from cooperating authorities.¶

• Tier-scoped presence partitioning means that an attacker generating many Tier 3 Experimental agents cannot affect Tier 1 or Tier 2 visibility scopes.¶

• Per-Owner-ID announcement rate limits SHOULD be enforced by participating nodes to prevent presence flooding from a single controlling entity.¶

7.2. Eclipse Attacks

An attacker controlling a sufficient number of nodes near a target Agent-ID in DHT keyspace may be able to isolate the target from the broader network, intercepting or dropping its DHT operations.¶

Mitigations:¶

• Parallel disjoint lookups (alpha=3) per S/Kademlia [SKADEMLIA] reduce the probability that all lookup paths are controlled by attacker nodes.¶

• k-bucket diversification requirements ensure routing table entries span multiple network locations and Owner-ID domains.¶

• Deterministic content-hash Agent-IDs prevent attackers from cheaply generating IDs that cluster around a target.¶

7.3. Presence Flooding and Denial of Service

Attackers may attempt to flood the network with announcements, search queries, or probe requests to exhaust resources of participating nodes.¶

Mitigations:¶

• Per-Owner-ID and per-Agent-ID rate limits on ANNOUNCE, PROBE, and search and lookup operations.¶

• Quota enforcement tied to AGTP-CERT issuance, allowing the issuing authority to revoke certificates of abusive participants.¶

• Gossip protocol bounded fanout (default 3) prevents amplification.¶

• Light-client and relay-mediated participation modes allow legitimate resource-constrained agents to participate without enabling amplification attacks.¶

7.4. Metadata Leakage Through Traffic Analysis

Even with invisible presence mode, an agent generates network traffic that may reveal its existence and activity patterns through traffic analysis.¶

Mitigations:¶

• This document provides incomplete protection against sophisticated traffic analysis. The visibility model is best-effort with respect to passive network observation.¶

• Agents requiring strong unobservability SHOULD use additional measures including TLS connection padding, traffic shaping, or participation through privacy-enhancing relays.¶

• Operators SHOULD acknowledge that invisible-mode agents are visible to the network operators they transit, even when invisible to other AGTP agents.¶

7.5. Visibility Declaration vs. Enforcement

Cryptographic declaration of visibility posture via AGTP-CERT extensions ensures that an agent's visibility intent is verifiable. Enforcement of visibility, however, depends on the cooperation of participating nodes.¶

This document specifies that conforming AGTP Presence implementations MUST honor declared visibility postures in their ANNOUNCE, PROBE, and gossip behaviors. Non-conforming implementations may ignore declared posture. Visibility is enforced by the protocol where implementations conform; the cryptographic declaration prevents visibility claims from being falsified; a non-conforming actor can still observe what it chooses to observe.¶

The situation is the same as TLS certificate validation: a server's certificate declares its identity verifiably, but a non-conforming client may choose to ignore validation failures.¶

7.6. Bootstrap Peer Capture

An attacker controlling bootstrap services may influence the initial routing state of joining agents, potentially enabling eclipse-class attacks on newly joined participants.¶

Mitigations:¶

• Multi-seed bootstrap with peers operated by independent parties.¶

• Periodic rotation of bootstrap peer lists.¶

• Trust-tier-specific bootstrap with institutional accountability for Tier 1 bootstrap services.¶

• Governance-driven revocation of bootstrap peers that fail operational requirements.¶

7.7. Privacy of Search Queries

Search queries themselves may reveal information about the querying agent's interests, intentions, or operational state.¶

Mitigations:¶

• Search queries carry AGTP wire-level identity, so they cannot be fully anonymous within the AGTP substrate.¶

• Operators concerned about query privacy MAY route search queries through privacy-enhancing relays or use cover traffic.¶

• Future revisions of this document may specify query blinding or oblivious lookup mechanisms for high-privacy use cases.¶

7.8. Partition Vocabulary Governance

The capability partition dimension derives from the AGTP method library and inherits its governance properties. The industry and region partition dimensions depend on external registries (such as NAICS, ISIC, ISO 3166) and inherit those registries' governance properties.¶

The architectural concern: whoever governs the partition vocabulary has structural influence over how agents are partitioned and therefore over which agents become visible to which others. Free-form partition strings would shatter the keyspace and collapse cross-scope resolution. Tightly governed vocabularies create central authorities in a system whose value proposition includes decentralization.¶

Mitigations:¶

• The capability axis is governed by the method library, which is itself a constrained vocabulary tied to AGTP method definitions. This avoids introducing a new governance body for the capability axis specifically.¶

• Industry and region axes use established external registries with long-standing governance. AGTP Presence maintains none of these registries; it consumes them.¶

• Implementations SHOULD support extensible dimension registries to allow operational deployments to define additional partition axes for specific use cases without requiring changes to this document.¶

• Overlay coordinators that manage split and merge decisions for scopes SHOULD operate under governance frameworks appropriate to the trust tier they serve.¶

8.1. Composition with AGTP Base

The new methods (ANNOUNCE, WITHDRAW, PROBE) extend the lifecycle verb category defined in the base specification. They are carried as standard AGTP requests on the AGTP wire format, authenticated via existing identity headers (Agent-ID, Owner-ID, Authority-Scope), and verified per the existing trust framework.¶

8.2. Composition with AGTP-IDENTIFIERS

Canonical Agent-IDs as defined in [AGTP-IDENTIFIERS] provide the content-addressable keys used by the DHT. No changes to the identifier specification are required.¶

8.3. Composition with AGTP-TRUST

Trust tiers and verification paths defined in [AGTP-TRUST] define the scoping model for visibility partitioning. The Tier 1, Tier 2, and Tier 3 classifications determine default overlay partitioning.¶

8.4. Composition with AGTP-CERT

The visibility extension defined in this document is registered in the AGTP-CERT certificate extension namespace. AGTP-CERT certificate issuance processes incorporate visibility posture declaration as part of certificate generation.¶

8.5. Composition with AGTP-DISCOVERY

[AGTP-DISCOVERY] specifies the DISCOVER method and the Agent Name Service, which operate over the presence substrate. The two documents divide the three operations of [RFC6763] between them: Presence is discovery (Agent-ID to attachment); DISCOVER's intent-driven mode is search (criteria to candidates), evaluated against the live presence layer instead of a separate registry; ANS is resolution (name to Agent-ID). Agents a search returns are agents currently visible in the requesting agent's presence scope, and each result carries the attachment Presence holds for it. The dichotomy between the two directions is stated once, in [AGTP-DISCOVERY]: ambient (push, continuous, ANNOUNCE and gossip) and reactive (pull, point in time, DISCOVER); this document uses those two words for the two directions.¶

9.1. At One Million Agents

Single-tier or single-governance-domain populations of approximately one million agents are within the proven operational envelope of existing Kademlia DHT deployments [KADEMLIA] [IPFS]. Lookup latency is O(log N), approximately 20 hops for one million nodes, typically faster in practice due to caching and parallel queries. Gossip convergence within scope completes in seconds. Routing table state per node remains bounded at approximately 20 to 30 entries.¶

9.2. At One Billion Agents

Global populations approaching one billion agents are addressed through the federation-of-scoped-overlays model. No single overlay contains the full population. Most agents participate in scoped views of thousands to tens of thousands of relevant peers. Cross-tier and cross-domain search proceeds through controlled federation points.¶

The internet scales the same way through BGP: the internet is a federation of independently operated systems with controlled inter-AS routing, with no single flat network anywhere in it. AGTP Presence adopts the same architectural pattern for agent populations.¶

9.3. Light-Client Predominance

In production deployments at scale, the participation distribution is expected to skew heavily toward light-client and relay-mediated agents. Full nodes are operated by infrastructure providers, enterprises, and institutional participants. Ephemeral consumer and task agents participate as light clients. This distribution is consistent with how other large-scale P2P systems have operated.¶

9.4. Observability and Operations

Implementers and operators of AGTP Presence networks SHOULD track the following operational metrics:¶

• DHT routing table convergence time at agent join¶

• Gossip convergence latency within visibility scopes¶

• Per-node bandwidth consumption¶

• Presence record TTL effectiveness and stale-record rates¶

• Rate of failed validation (signature failures, visibility violations, bootstrap failures)¶

10.1. AGTP Method Names

Registration of three new AGTP method names in the AGTP method registry established by [AGTP]:¶

10.2. AGTP-CERT Extension OID

Registration of an OID for the Presence Visibility Extension in the AGTP-CERT extension namespace established by [AGTP-CERT]:¶

• Extension name: PresenceVisibilityExtension¶

• OID: TBD (to be assigned)¶

• Reference: This document¶

10.3. Authority-Scope Values

Registration of three new Authority-Scope values:¶

10.4. Presence-Mode Header

Registration of the Presence-Mode header in the AGTP header registry:¶

• Header name: Presence-Mode¶

• Defined values: public, tier-scoped, owner-domain, explicit-only, invisible¶

• Reference: This document¶

10.5. Partition Dimension Registry

This document requests IANA establishment of a new registry for AGTP Presence partition dimensions. The registry contains the following initial entries:¶

Registration policy: Specification Required. New partition dimensions MUST be accompanied by a referenced vocabulary source, governance description, and expected use case description.¶

11.1. Distributed Hash Tables

Kademlia [KADEMLIA] provides the foundational DHT design used here. S/Kademlia [SKADEMLIA] contributes security hardening for adversarial network conditions. IPFS [IPFS] demonstrates production deployment of Kademlia at hundreds of thousands of nodes.¶

The contribution of AGTP Presence beyond these systems is the integration of cryptographically declared visibility scoping with DHT operations, allowing scoped views over one shared network without requiring separate physical networks per scope.¶

11.2. Gossip Protocols

Production gossip systems including Serf [SERF] demonstrate the viability of gossip-based membership and state convergence at scale. The gossip mechanism specified here adopts the bounded-fanout epidemic propagation model used in these systems, with the addition of certificate-based signature verification for all announcements.¶

11.3. Peer-to-Peer Discovery

libp2p [LIBP2P] provides general-purpose peer discovery primitives including Kademlia DHT and gossipsub. AGTP Presence differs in specifying trust-tier-aware visibility scoping and certificate-bound declaration of visibility posture at the protocol level.¶

11.4. Presence Protocols

XMPP presence (RFC 6121) provides per-user presence within federated servers using subscription rosters. The AGTP Presence model differs in being ambient (requiring no explicit subscription) and in having no server in the middle.¶

11.5. Comparison with Pull-Based Discovery

ARD, DNS-AID, ANS, and similar pull-based proposals provide mechanisms for querying known endpoints; in the vocabulary of [AGTP-DISCOVERY] they are search and resolution. AGTP Presence operates at a different layer, providing the live population view against which those reactive queries can be evaluated. AGTP Presence replaces none of them; it provides the live population that reactive queries run against, in place of static or stale directories.¶

12.1. Normative References

[AGTP]

Hood, C., "Agent Transfer Protocol (AGTP)", Work in Progress, Internet-Draft, draft-hood-independent-agtp-10, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-independent-agtp-10>.

[AGTP-CERT]

Hood, C., "AGTP Agent Certificate Extension", Work in Progress, Internet-Draft, draft-hood-agtp-agent-cert-04, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-agent-cert-04>.

[AGTP-DISCOVERY]

Hood, C., "AGTP Agent Discovery and Name Service", Work in Progress, Internet-Draft, draft-hood-agtp-discovery-02, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-discovery-02>.

[AGTP-IDDOC]

Hood, C., "AGTP Agent Identity Document", Work in Progress, Internet-Draft, draft-hood-agtp-identity-document-00, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-identity-document-00>.

[AGTP-IDENTIFIERS]

Hood, C., "AGTP Identifier Chain", Work in Progress, Internet-Draft, draft-hood-agtp-identifiers-03, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-identifiers-03>.

[AGTP-TRUST]

Hood, C., "AGTP Trust and Verification Specification", Work in Progress, Internet-Draft, draft-hood-agtp-trust-03, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-trust-03>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC6763]

Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/rfc/rfc6763>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

12.2. Informative References

[IPFS]

"IPFS - Content Addressed, Versioned, P2P File System", n.d., <https://ipfs.tech>.

[KADEMLIA]

Maymounkov, P. and D. Mazieres, "Kademlia: A Peer-to-peer Information System Based on the XOR Metric", 2002, <https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf>.

[LIBP2P]

"libp2p - Modular peer-to-peer networking stack", n.d., <https://libp2p.io>.

[SERF]

"Serf - Decentralized cluster membership", n.d., <https://www.serf.io>.

[SKADEMLIA]

Baumgart, I. and S. Mies, "S/Kademlia: A Practicable Approach Towards Secure Key-Based Routing", 2007.