AGTP Presence: Ambient Discovery and Visibility for Agent Substrates

1.1. 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.¶

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 does not maintain DHT routing state but communicates with full-node peers for presence announcement and discovery queries.¶

Full Node:

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

Relay:

A full-node agent that accepts presence announcements and discovery 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 structurally 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, Owner-ID, certificate) and verified per [AGTP-TRUST].¶

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 not a global 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 actually use for discovery: 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 not as a flat global network but as a federation of autonomous systems with controlled inter-AS routing. AGTP Presence adopts the same architectural pattern for agent populations, with the partition axes being meaningful to agent discovery rather than network topology.¶

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 does not maintain 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 discovery 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. Discovery 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 discovery 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 discovery 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 discovery 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.¶

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 not in 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 do not invoke 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 discovery 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 does not exist. This is the structural enforcement mechanism for 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 not in the requesting agent's visibility scope or does not exist¶

5.1. Presence Visibility

Presence visibility determines whether the agent appears in ambient discovery 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 discovery query results; it does not prevent direct addressing.¶

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 discovery results but advertise no operational metadata. Discovering 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 discovery.¶

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 discovery 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, discovery queries, or probe requests to exhaust resources of participating nodes.¶

Mitigations:¶

• Per-Owner-ID and per-Agent-ID rate limits on ANNOUNCE, PROBE, and discovery 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 does not provide complete 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 if not visible 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 but does not prevent non-conforming actors from observing what they choose to observe.¶

This is structurally similar to 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 Discovery Queries

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

Mitigations:¶

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

• Operators concerned about query privacy MAY route discovery 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 structurally 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 does not maintain 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

The Agent Name Service (ANS) defined in [AGTP-DISCOVERY] provides the rich query interface that operates over the presence substrate. ANS queries are resolved against the live presence layer rather than against a separate registry. Agents discoverable through ANS are agents currently visible in the requesting agent's presence scope.¶

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 discovery proceeds through controlled federation points.¶

This is structurally analogous to how the internet scales through BGP: the internet is not a single flat network but a federation of autonomous systems with controlled inter-AS routing. 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 a shared substrate 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 as substrate properties rather than application-layer policy.¶

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 (not requiring explicit subscription) and in being substrate-level rather than server-mediated.¶

11.5. Comparison with Pull-Based Discovery

ARD, DNS-AID, ANS, and similar pull-based discovery proposals provide mechanisms for querying known endpoints. AGTP Presence operates at a different layer, providing the live population view against which those pull-based queries can be evaluated. AGTP Presence does not replace pull-based discovery; it provides the substrate that makes pull-based discovery operate against a known live population rather than against static or stale directories.¶

12.1. Normative References

[AGTP]

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

[AGTP-CERT]

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

[AGTP-DISCOVERY]

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

[AGTP-IDENTIFIERS]

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

[AGTP-TRUST]

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

[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>.

[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

[EU-AI-ACT]

"EU AI Act Article 12 - Record-Keeping", n.d., <https://artificialintelligenceact.eu>.

[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>.

[RFC7574]

Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to-Peer Streaming Peer Protocol (PPSPP)", RFC 7574, DOI 10.17487/RFC7574, July 2015, <https://www.rfc-editor.org/rfc/rfc7574>.

[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.