Architecture and Implementation Blueprint for a Twenty-Model Direct P2P Fleet on the MiniModel Network

Full report

On this page

The transition from centralized infrastructure to a robust, decentralized peer-to-peer (P2P) collaborative economy requires strict engineering discipline, deterministic resource allocation, and explicit cryptographic boundaries1. Centralized models concentrate data and power, whereas P2P networks distribute computational load and governance directly among participants1. This report defines an exhaustive architectural and operational specification for deploying twenty quality-qualified TinyRustLM .slm models over the MiniModel direct P2P network. The design relies on a downloadable Rust/.NET operational host, rigid process segregation via independent process lanes, and mandatory external cryptographic proofs to ensure verifiable model sharing without relying on centralized byte proxies.

1. Public Catalog Observation Log and Explicit Unknowns

An architectural evaluation must reconcile the target production state—twenty distinct, high-quality models—with the current capabilities and artifacts observed in the existing environment. An analysis of the public catalog at mirust.com reveals a significant discrepancy between the system's intended capacity and its present experimental baseline6. The current directory lists exactly eight models, all of which are categorized as experimental "deterministic smoke" fixtures6. No trained assistant-quality models are currently claimed or available in the catalog. The existing artifacts are strictly utilized for testing parser and application binary interface (ABI) regression6.

Achieving the twenty-model production mandate requires resolving several explicit unknowns. First, the source of twenty distinct artifacts remains undefined. Because relabeled copies and superficial smoke fixtures are strictly prohibited by the deployment constraints, twenty unique, assistant-quality artifacts must be acquired, trained, or verified through the quality-qualification gates. Second, the infrastructure for the external observer fleet is currently unmapped. The protocol dictates that public proofs require receipts from genuinely outside-network observers, necessitating the provisioning of geographically distributed, independently governed nodes equipped with Ed25519 keypairs. Finally, the TinyRustLM runtime currently imposes a strict 128 MiB transfer ceiling for any single raw allocation, operating purely on main-thread scalar CPU execution8. Deploying models that exceed this memory boundary will require transitioning from full-file transfers to chunked or streaming loading mechanisms, or modifying the host transfer limits entirely. Furthermore, while the domain name implies GGUF support, the active runtime strictly parses the custom .slm format (version 1\) possessing a 108-byte header; GGUF compatibility is completely absent8.

2. Fleet, Process, and Network Diagrams

The system architecture is engineered to maintain a strict separation of concerns, ensuring that bytes flow exclusively between consenting peers without routing through central proxies. The centralized MiniModel.org platform is relegated entirely to discovery, indexing, and metadata operations, while the decentralized fleet handles the heavy computational and bandwidth loads of model distribution1. The primary node architecture centers on a Rust/.NET operational host. This companion application serves as the persistent daemon managing the P2P lifecycle, while the browser UI acts solely as a chat and presentation interface8. The host orchestrates the underlying process supervision layer, completely isolating the network serving responsibilities into independent process lanes. Within the local machine, the host daemon does not serve files directly. Instead, it interacts with the operating system's process supervision layer—such as systemd on Linux—to instantiate precisely two independent process lanes per admitted model. This results in forty independent worker processes for a twenty-model fleet. Both lanes associated with a specific model map to a single, read-only .slm artifact stored on the local disk. By utilizing memory-mapped files in read-only mode, the operating system's page cache guarantees that the model bytes are not duplicated in physical RAM, circumventing the massive memory overhead typically associated with running forty concurrent file servers9. Externally, the network diagram diverges into two distinct operational planes. The control plane involves the local Rust/.NET host submitting endpoint URLs and cryptographic piece sets to an outside network observer. This observer acts as an independent auditor, probing both lanes from outside the host's local area network (LAN) and Network Address Translation (NAT) boundaries. If the lanes successfully respond with the correct byte hashes, the observer issues a cryptographic receipt. The data plane is established only after this receipt is submitted to the MiniModel.org catalog. Consenting peers discover the advertised endpoints via the catalog and initiate direct, P2P data transfers with the local lanes.

3. Identity and Configuration Schemas

A robust P2P network requires an immutable, verifiable identity model to prevent spoofing, routing attacks, and data corruption4. The identity schema binds the fleet, models, lanes, and proof receipts through deterministic cryptography, heavily utilizing Ed25519 digital signatures subject to strict ZIP-215 validation rules11.

The configuration strictly enforces Ed25519 canonicalization rules to ensure compatibility with batch signature verification, which is critical for processing high volumes of P2P connection receipts11. Implementations must utilize the cofactored verification equation ([Figure omitted from source export]) as required by FIPS 186-5 and ZIP-21512. Furthermore, the system must rigidly reject non-canonical scalar values by enforcing [Figure omitted from source export], preventing malicious actors from adding [Figure omitted from source export] to [Figure omitted from source export] to forge mathematically valid but malleable signatures12. While small order [Figure omitted from source export] values are rejected to maintain strong binding resilience against key substitution attacks, non-canonical [Figure omitted from source export] encodings may be accepted without security degradation, aligning with standard consensus layer semantics12.

4. Admission and Serving State Machines

The lifecycle of a model—from initial acquisition to public catalog serving—is governed by a deterministic, fail-closed state machine. Any failure during validation results in immediate quarantine, preventing unverified bytes from entering the executable runtime or the P2P swarm. The admission sequence begins with the Quality Receipt Check. Because only quality-qualified models may be admitted, the incoming artifact must present a cryptographic receipt signed by a recognized MiniModel authority. If this receipt is missing, expired, or cryptographically invalid, the state machine halts. Following this, the system executes a rigorous structural validation of the .slm container. The parser reads the file to verify the 108-byte header, asserting the presence of the SLM1 magic bytes, the version integer, and the custom FNV-1a checksum limits8. The tensor directory is scanned to ensure all payloads are 64-byte aligned and adhere to the supported f32, q8\_0, or q4\_0 data type contracts8. Once structural integrity is proven, the provenance and license review phase commences. The manifest\_id is hashed and checked against a local deny-list, ensuring the model's licensing permits unrestricted P2P distribution without triggering legal encumbrances. Upon passing, the system transitions to piece generation. The validated .slm artifact is hashed into uniform chunks, producing a Merkle tree where the root becomes the piece\_set\_id. Before exposing the file to the network, the operational host performs a local round trip. The host initiates a read of the artifact through the local loopback interface, verifying both the integrity of the byte stream and the stability of the file descriptor read paths. If the local fetch succeeds, the Rust/.NET host initializes the two-lane serve state by signaling the local OS daemon to spawn the independent processes for Lane A and Lane B. The final phases secure external validation. The endpoints associated with the lanes enter a probing state, awaiting contact from an outside network observer. The observer attempts to download a randomized challenge piece from both lanes. Only if both lanes return identical, cryptographically valid response hashes does the observer generate the signed proof receipt. Finally, the host takes this receipt and executes the catalog publication, transitioning the endpoints from a configured state to an advertised state on MiniModel.org, officially opening the model to P2P swarming.

5. Capacity Model for 1, 5, and 20 Models

Deterministic resource governance is critical when exposing local hardware to P2P swarm dynamics. Serving twenty models concurrently across forty independent process lanes requires precise mathematical modeling of memory, file descriptors, and compute overhead to prevent host exhaustion. The baseline calculations leverage the known footprint of the TinyRustLM architecture. The forward scratch memory is calculated as [Figure omitted from source export] bytes, while the Key-Value (KV) cache requires [Figure omitted from source export] bytes9. Logits require [Figure omitted from source export] bytes9. The reference file sizes for the TinyLM-16M architecture dictate that a q8\_0 quantized model occupies 16.37 MiB, a q4\_0 model occupies 10.16 MiB, and a raw f32 model occupies 65.04 MiB6. To model the physical storage and memory demands, we project a mixed-tier deployment across three scenarios. The single-model scenario assumes one q8\_0 artifact. The five-model scenario assumes a mix of three q8\_0, one q4\_0, and one f32 artifact. The full twenty-model fleet assumes ten q8\_0, five q4\_0, and five f32 artifacts.

The file descriptor (FD) calculation is derived from the requirement that each of the forty lanes must maintain its own connections. Each lane requires one FD for the listening socket, one FD for the read-only memory-mapped .slm file, and a configured maximum of 32 FDs for active peer connections. Therefore, each lane consumes 34 FDs, yielding a global maximum of 1,360 FDs for a fully saturated twenty-model fleet10. The page cache architecture is vital for system stability. Because the lanes are isolated processes, standard memory allocation would duplicate the model bytes forty times. However, by enforcing a strict read-only map to the artifact store, the operating system's virtual memory manager deduplicates the physical pages. Even at maximum concurrency, the total RAM consumed by the cached models will never exceed the total disk footprint of 539.65 MiB10. Resource governance extends beyond static memory. Hashing CPU overhead is a significant factor; during startup revalidation, the host must compute SHA-256 hashes across the entire 539.65 MiB dataset to ensure no local bit rot has occurred. While modern cryptographic accelerators process this in under a second, the revalidation routine is throttled to prevent CPU spikes from degrading concurrent chat inference. Outbound bandwidth is strictly managed using a global token bucket algorithm, ensuring the user's primary internet connection is never saturated. Fairness among peers is maintained via a tit-for-tat reciprocal upload mechanism, similar to BitTorrent, allocating more bandwidth to peers that actively contribute pieces back to the swarm5. To mitigate denial-of-service (DoS) attacks, global and per-peer concurrency limits are strictly enforced, and a hot/cold policy aggressively shuts down lanes that have not received valid HTTP requests within a defined idle threshold.

6. HTTP Allow/Deny Profile

Because model bytes flow directly between consenting peers without traversing a trusted central proxy, the local serving implementation must be rigorously constrained4. The evolution of the basic tinyrustlm-local-server into a public-facing P2P node requires a strict HTTP serving profile to mitigate web-based attack vectors8. The server strictly permits only GET and HEAD methods. Any attempt to utilize POST, PUT, OPTIONS, DELETE, or custom methods immediately yields a 405 Method Not Allowed response. The routing surface is entirely closed except for exact matches against the /pieces/{piece\_set\_id}/{piece\_index} pattern. All non-matching routes yield a sterile 404 Not Found without revealing server version details. Path normalization and traversal defenses are paramount. Before routing, the server performs URL unescaping and strict normalization. The presence of any directory traversal sequences (such as ../ or %2e%2e%2f) results in an immediate, silent TCP connection drop (TCP RST) to frustrate automated vulnerability scanners. Furthermore, the application mitigates symlink and reparse point attacks by opening the artifact store with flags that explicitly reject symbolic link resolution (e.g., O\_NOFOLLOW on Linux systems), preventing arbitrary file read vulnerabilities. Header processing is heavily bounded. The total incoming header payload cannot exceed 4 KB. Required Cross-Origin Resource Sharing (CORS) headers, specifically Access-Control-Allow-Origin: \* and Access-Control-Allow-Methods: GET, HEAD, are appended to valid responses to facilitate browser-based peer connections. To support the resumable imports critical to P2P efficiency, the server enforces the Accept-Ranges: bytes directive. However, to eliminate the complex attack surface of HTTP Request Smuggling, chunked transfer encoding is globally disabled. Every response must carry an exact Content-Length header matching the piece payload. If an incoming request lacks a precise content length or attempts to utilize Transfer-Encoding: chunked, the server forcefully closes the connection. Upon completion of a piece transmission, the server applies a strict Connection: close policy, rapidly freeing the file descriptor to service the next peer. Legacy protocols like HTTP/0.9 and highly multiplexed protocols like HTTP/2 are intentionally omitted to keep the parsing state machine deterministic and minimal.

7. NAT Workflow and Status Vocabulary

Public P2P infrastructure routinely fails when deployed behind Carrier-Grade NAT (CGNAT) and stringent residential firewalls17. The P2P fleet cannot rely on silent or non-consensual modifications to router states. Instead, it must utilize explicit port mapping protocols and maintain an accurate, observable status workflow from initial configuration to public advertisement19. The primary mechanism for traversing NAT is the Port Control Protocol (PCP), a modern standard (RFC 6887\) operating over UDP port 535119. The host issues PCP MAP opcodes to the gateway, explicitly requesting a binding between an internal port and an external, routable IP address20. Because PCP natively supports IPv6 and carrier-grade equipment, it is the preferred traversal method20. For legacy consumer routers, the system falls back to the Universal Plug and Play Internet Gateway Device (UPnP IGD) protocol, which operates via SSDP on UDP port 190019. In complex network topologies, such as Dual-Stack Lite (DS-Lite) or NAT64 deployments utilizing double NAT, local UPnP mapping requests often fail to propagate to the ISP's CGNAT layer17. To address this, the system attempts to detect the presence of an IGD-PCP Interworking Function (IWF) embedded in the local router, which translates local UPnP requests into upstream PCP mappings18. If automated traversal fails, the host provides instructions for manual port forwarding or operator-approved tunnels. To ensure operational transparency, the host transitions through a strict status vocabulary:

• Configured: The lane is bound locally and actively listening, but no external reachability has been established or requested.
• Mapping\_Requested: A PCP MAP request or UPnP IGD broadcast has been transmitted to the local gateway21.
• Mapped: The gateway has acknowledged the request, allocating an external IP and port for the lane.
• Probing: The host is currently awaiting the external observer to verify the mapped endpoint from outside the network.
• Advertised: The mapping has been cryptographically verified by the observer, and the endpoint is published to the MiniModel.org catalog.

8. External Proof and Announcement Protocol

The MiniModel catalog must maintain high fidelity; it must not index unreachable, fraudulent, or stalled endpoints. The announcement protocol strictly requires a canonical receipt bound to the specific artifact and lane, verified by a genuinely external entity. The canonical receipt is formatted as a structured binary payload or a dense JSON Web Token (JWT), signed using Ed25519. The payload strictly binds the model\_id, artifact\_id, and piece\_set\_id. It includes the normalized URLs for both lane\_a and lane\_b. The receipt records the observer\_id (the public key of the verifying entity) and the response\_hashes, which are the exact SHA-256 hashes of a randomized challenge piece downloaded during the probe. To prevent spoofing and replay attacks, the receipt includes a cryptographic nonce, the issue\_time, and an expiry timestamp strictly bounded to a 15-minute window, effectively mitigating long-term endpoint drift. To defend against signature malleability, the Ed25519 canonicalization rules mandated in the identity schema are applied here. The observer's signature must pass the ZIP-215 cofactored verification equation, and the receipt is immediately discarded if the scalar component [Figure omitted from source export] is not properly bounded12. Replay attacks are further neutralized by enforcing a 30-second clock skew tolerance on the issue\_time. To prevent a single compromised observer from polluting the catalog with fabricated receipts, MiniModel.org requires announcements to be backed by a rotating quorum of authorized observers. The catalog lifecycle is directly tied to these proofs. When a model is successfully published, its status is Active. If one of the two independent lanes fails a subsequent probe or experiences a local crash, the host detects the failure and the model transitions to a Degraded status, displaying a yellow warning in the user's chat interface. If both lanes fail, the observer generates a revocation receipt, and the model is instantly Quarantined from the catalog. If the 15-minute receipt expires without a successful renewal, the entry becomes Stale and is hidden from discovery. If a license violation or security flaw is discovered in the artifact, the catalog flags it as Revoked or Superseded.

9. Import, Corruption, and Recovery Model

Because P2P networks are inherently susceptible to packet loss, mid-transfer disconnects, and malicious byte injection from untrusted peers, the artifact import sequence must be highly resilient and explicitly verified. The import sequence begins with durable journaling. The client creates a sparse file representing the final artifact size on disk, alongside a write-ahead log (WAL) to track piece acquisition. Before mixing pieces from multiple sources, the client demands complete identity agreement; it verifies that the peers serving Lane A and Lane B present identical artifact\_id and piece\_set\_id hashes. Downloads are executed using resumable HTTP Range requests, allowing the client to pull disparate chunks concurrently. As each piece arrives, it is temporarily buffered in memory, and its SHA-256 hash is computed. While the TinyRustLM .slm container utilizes an FNV-1a checksum for detecting accidental local bit flips, FNV-1a is cryptographically insecure and unsuitable for P2P defense8. Therefore, the SHA-256 hash of the received piece is checked against the trusted Merkle tree derived from the piece set identity. If a piece fails this cryptographic check, the corruption quarantine protocol is triggered. The malicious or corrupted chunk is immediately discarded from memory, and the offending peer's reputation score is heavily penalized, leading to an eventual connection ban. The client then re-requests the missing piece from an alternate, trusted peer. Once all pieces are successfully downloaded and independently verified, the client executes an atomic final promotion. The fully assembled file is moved from the temporary staging directory to the persistent read-only store using an atomic rename() OS system call, ensuring that sudden power loss cannot corrupt the data store. Finally, a complete Rust verification pass is executed against the assembled file. The runtime checks the SLM1 magic bytes, the version integer, the header structures, and the exact tensor shapes8. Only after this final, holistic check passes is the model marked available for serving.

10. Continuous Operations and Runbooks

Sustaining the availability of twenty models across forty distinct process lanes requires automated, self-healing continuous operations. The architecture explicitly rejects monolithic thread pools, instead leveraging native operating system init and process supervision capabilities to isolate failures.

Independent Process Supervision

For Linux deployments, the Rust/.NET companion utilizes systemd socket activation for unparalleled reliability and minimal idle memory overhead22. The system generates a .socket unit configuration that pre-binds the required IPv4/IPv6:Port endpoint. Crucially, the configuration uses Accept=false, which instructs systemd to listen on the network interface and hold the file descriptors, passing them to the worker process when a connection arrives, rather than spawning a new process per connection like traditional inetd22. This architecture guarantees atomic failure on collision: if two misconfigured lanes attempt to bind the same fixed port without systemd supervision, a collision occurs; however, by allowing systemd to manage the listener sockets, port conflicts are resolved before the process even boots. If the Rust binary serving Lane A panics or is terminated due to an out-of-memory condition, the systemd .socket remains open. New incoming peer connections simply queue in the kernel. Systemd instantly restarts the .service, passes the socket via the native sd\_listen\_fds() API, and the newly spawned process seamlessly drains the backlog without a single connection being refused22. For Windows deployments, where systemd is unavailable, the Rust/.NET host achieves equivalent process supervision using Windows Job Objects and the HTTP Server API (http.sys). The parent host pre-binds the URL ACLs and manages the listener queues. The forty worker processes are spawned under strict Job Object constraints, ensuring that if a worker dies, it is cleanly reaped and restarted, while the parent continues to queue incoming HTTP requests to prevent dropped connections. On both platforms, shutdown operations trigger a graceful drain phase, allowing active piece transfers to complete before the file descriptors are finally closed.

Continuous Verification

Maintaining swarm health requires continuous background verification. The host executes a local health cadence every 60 seconds, querying the loopback endpoints to ensure the lanes are responsive. To maintain the active catalog presence, the host initiates an external proof renewal every 10 minutes, securing a new observer receipt before the strict 15-minute expiry window closes. To prevent insidious disk corruption (bit rot), the host performs model-byte spot checks, reading random chunks of the read-only store and comparing them against the known SHA-256 piece hashes. A full revalidation schedule is executed weekly during off-peak hours. Bandwidth accounting is tracked locally, recording the volume of bytes served to the P2P swarm. This privacy-preserving diagnostic data is aggregated entirely on the local node; there is no proprietary telemetry backend harvesting IP addresses or transfer logs. Users may opt to broadcast their uptime and contribution metrics to MiniModel.org voluntarily.

11. Test Matrix and Required Evidence

Prior to executing a full production rollout, the architecture must satisfy a rigorous acceptance plan. This matrix cleanly separates behaviors that can be proven via local Continuous Integration (CI) from features that strictly require authorized external infrastructure.

12. Staged Implementation Backlog

The engineering effort required to materialize this blueprint is structured into five sequential delivery phases, designed to iteratively burn down architectural risk.

• Phase 1: Local Server Hardening: Refactor the existing tinyrustlm-local-server to enforce strict HTTP GET/HEAD serving8. Implement URL normalization, directory traversal defenses, O\_NOFOLLOW symlink protection, and remove all chunked transfer encoding logic. Address the 128 MiB transfer ceiling by implementing streaming file reads.
• Phase 2: Process Supervision Integration: Develop the systemd socket activation templates (model@.socket and model@.service)22. Implement the Rust FFI bindings to ingest sd\_listen\_fds() for Linux, and integrate the HTTP Server API for Windows.
• Phase 3: Cryptographic Identity & Verification: Implement Ed25519 ZIP-215 receipt signing and validation routines, ensuring the cofactored equation logic is perfectly aligned with the standard12. Develop the Merkle tree piece-hashing logic.
• Phase 4: NAT Transversals: Integrate a robust PCP and UPnP IGD client library19. Implement the state machine governing the transition from Configured to Mapped, including fallback logic for double NAT detection18.
• Phase 5: P2P Network Operations: Deploy the geographically distributed MiniModel observer fleet. Establish the catalog lifecycle API on MiniModel.org. Execute the final 20-model scale-out and monitor the 40 lanes under sustained P2P swarm load.

13. Direct Primary-Source Links with Dates

The architectural constraints, limits, and specifications utilized in this report are strictly derived from the following documented states, accurate as of June 25, 2026:

• P2P Models Collaborative Economy: Research on MiniModel decentralized infrastructure, unstructured/hybrid networking theory, and resilience1.
• TinyRustLM Implementation Source Audit: Source-grounded documentation of the custom .slm container, the 108-byte header structure, CPU scalar constraints, FNV-1a checksums, and model profiles6.
• TinyRustLM Operations Handbook: Explicit definitions of the 128 MiB transfer ceiling, operational limits, state boundaries, and memory footprint formulas9.
• NAT and Port Control Protocols: IETF RFC 6887 (PCP) and RFC 6970 (UPnP IGD-PCP Interworking Function) specifications governing Carrier-Grade NAT traversal17.
• Ed25519 ZIP-215 Canonicalization: Cryptographic specifications, Zcash protocol alignments, and FIPS 186-5 requirements for signature validation and malleability defense11.
• Systemd Socket Activation: Official freedesktop documentation and operational guides for ListenStream, Accept=false pre-binding, zero-downtime application updates, and file descriptor passing22.

Works cited

1. P2P Models \- P2P Models, https://p2pmodels.eu/
2. What Is a Peer-to-Peer (P2P) Network? (With Examples) | Indeed.com, https://www.indeed.com/career-advice/career-development/what-is-a-peer-to-peer-network
3. An Introduction to Peer-to-Peer Network Model | Baeldung on Computer Science, https://www.baeldung.com/cs/peer-to-peer-network-model
4. What Is a Peer-to-Peer Network? | Vbrick Explains P2P, https://vbrick.com/blogs/what-is-peer-to-peer/
5. P2P Networking \- balajis.com, https://balajis.com/p/p2p-networking
6. Models \- MiRust, https://mirust.com/models/
7. MiRust: Home, https://mirust.com/
8. Implementation \- MiRust, https://mirust.com/implementation/
9. Implementation operations \- MiRust, https://mirust.com/implementation-operations/
10. unknown\_url
11. ed25519 package \- github.com/oasisprotocol/curve25519-voi/primitives/ed25519 \- Go Packages, https://pkg.go.dev/github.com/oasisprotocol/curve25519-voi/primitives/ed25519
12. ADR 0009: Ed25519 Signature Verification Semantics | Oasis Documentation, https://docs.oasis.io/adrs/0009-ed25519-semantics/
13. Network Upgrade Guide \- Zcash Documentation \- Read the Docs, https://zcash.readthedocs.io/en/latest/rtd\_pages/nu\_dev\_guide.html
14. Verifying signatures using ZIP215 criteria · Issue \#664 · dalek-cryptography/curve25519-dalek \- GitHub, https://github.com/dalek-cryptography/curve25519-dalek/issues/664
15. RFC 8032 \- Edwards-Curve Digital Signature Algorithm (EdDSA) \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc8032
16. \[ZIP 216\] Require Canonical Jubjub Point Encodings · Issue \#400 · zcash/zips \- GitHub, https://github.com/zcash/zips/issues/400
17. Using PCP (Port Control Protocol) in practice? \- Super User, https://superuser.com/questions/1301857/using-pcp-port-control-protocol-in-practice
18. RFC 6970 \- Universal Plug and Play (UPnP) Internet Gateway Device \- Port Control Protocol Interworking Function (IGD-PCP IWF) \- Datatracker, https://datatracker.ietf.org/doc/html/rfc6970
19. UPnP IGD & PCP | pfSense Documentation, https://docs.netgate.com/pfsense/en/latest/services/upnp.html
20. Port Control Protocol \- Wikipedia, https://en.wikipedia.org/wiki/Port\_Control\_Protocol
21. Port Control Protocol (PCP) NAT | FortiGate / FortiOS 7.6.0 \- Fortinet Document Library, https://docs.fortinet.com/document/fortigate/7.6.0/fortinet-carrier-grade-nat-field-reference-architecture-guide/255562/port-control-protocol-pcp-nat
22. How to Create a systemd Socket-Activated Service on Ubuntu \- OneUptime, https://oneuptime.com/blog/post/2026-03-02-how-to-create-a-systemd-socket-activated-service-on-ubuntu/view
23. systemd for Developers I, http://0pointer.de/blog/projects/socket-activation.html
24. Start a systemd service only \after\ the target socket is listening?, https://unix.stackexchange.com/questions/319904/start-a-systemd-service-only-after-the-target-socket-is-listening
25. systemd.socket \- Freedesktop.org, https://www.freedesktop.org/software/systemd/man/systemd.socket.html
26. About \- P2P Models, https://p2pmodels.eu/about/
27. What is P2P (Peer-to-Peer Process)? \- GeeksforGeeks, https://www.geeksforgeeks.org/computer-networks/what-is-p2p-peer-to-peer-process/
28. Enterprise Interoperability Viii: Keith Popplewell Klaus-Dieter Thoben Thomas Knothe Raúl Poler Editors | PDF | Computer Security \- Scribd, https://www.scribd.com/document/727999474/978-3-030-13693-2
29. Instruction Manual: SLM Series | PDF | Computer Engineering \- Scribd, https://www.scribd.com/document/672429490/Slm
30. OAM and SAA \- Nokia Documentation Center, https://documentation.nokia.com/sar/23-10-1/books/oam/oam-saa.html
31. Zcash Zebra Security Assessment \- NCC Group, https://www.nccgroup.com/media/bw3nq0vm/\_ncc\_group\_zcashfoundation\_e005955\_report\_2023-06-27\_v10.pdf
32. What is Ed25519 in cybersecurity? \- Hexnode Blogs, https://www.hexnode.com/blogs/explained/what-is-ed25519-in-cybersecurity/
33. EVP\_SIGNATURE-ED25519 \- OpenSSL Documentation, https://docs.openssl.org/3.4/man7/EVP\_SIGNATURE-ED25519/
34. Signatures: Ed25519 — HACL\* and EverCrypt Manual documentation, https://hacl-star.github.io/HaclSig.html
35. RFC 8080 \- Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC, https://datatracker.ietf.org/doc/html/rfc8080
36. EdDSA and Ed25519 \- Practical Cryptography for Developers, https://cryptobook.nakov.com/digital-signatures/eddsa-and-ed25519
37. systemd \- ArchWiki, https://wiki.archlinux.org/title/Systemd
38. Systemd Socket Activation Explained \- ilManzo's blog, https://ilmanzo.github.io/post/systemd-socket-activated-services/