MiniModel Peer-to-Peer Technology Tradeoff Report: Architecture for Rust-First SLM Exchange

Full report

On this page

The proliferation of small language models (SLMs), typically characterized by parameter counts ranging from one million to ten billion, has fundamentally shifted the landscape of computational linguistics and edge artificial intelligence1. Unlike their massive counterparts, SLMs are architected for deployment in resource-constrained environments, offering low-latency inference on consumer hardware without reliance on centralized cloud infrastructure4. Within this context, the MiniModel ecosystem, operating in tandem with the TinyRustLM application framework, requires a highly resilient, decentralized distribution mechanism for its proprietary .slm model artifacts7. The project's digital presence spans multiple domains, including the core application interface at https://TinyRustLM.com/, the primary project nexus at https://MiniModel.org/, the model registry located at https://MiniModel.org/catalog/models.v0.json, and the technical documentation hub at https://MiniModel.MiRust.com/7. A core tenet of the MiniModel philosophy, heavily influenced by the principles of teleodynamic learning, is the strict enforcement of executable boundaries and resource-bounded control7. This philosophy dictates a severe infrastructural constraint: all project-operated servers must remain exclusively metadata-only10. Under no circumstances may project infrastructure host, proxy, execute, or serve the actual bytes of the user models. Consequently, the acquisition and exchange of .slm files must be executed over a peer-to-peer (P2P) network. This network must natively support a Rust-first ecosystem, ensuring memory safety, zero-cost abstractions, and seamless WebAssembly (Wasm) compilation for browser-based inference10. This comprehensive report evaluates six distinct peer-to-peer technology architectures to determine the optimal substrate for the MiniModel exchange. The analysis scrutinizes Rust-native QUIC/blob transfer, Rust-libp2p, BitTorrent-style chunking, Iroh, Pear/Bare/Hypercore, and a plain direct HTTP peer-piece serving bridge. The objective is to formulate a definitive, phased architectural roadmap that satisfies the strict security, performance, and operational requirements of the decentralized MiniModel ecosystem.

Architectural Imperatives and Evaluation Criteria

The evaluation of the decentralized network stack relies on ten critical criteria. These vectors ensure the chosen technology aligns with the memory-safe, high-performance, and decentralized mandates of the TinyRustLM and MiniModel architecture. The first criterion is Rust implementation maturity. The foundational transport and cryptographic layers must possess production-grade, battle-tested Rust implementations. This is essential to align with the memory safety, concurrency guarantees, and zero-cost abstractions inherent to the TinyRustLM ecosystem10. A mature Rust crate ecosystem prevents the need for unsafe Foreign Function Interfaces (FFI) to C or C++ libraries, thereby reducing the attack surface and maintaining the integrity of the compilation pipeline. The second criterion evaluates browser compatibility. The capacity to execute seamlessly within WebAssembly (Wasm) environments is paramount for local-first inference paradigms12. The network stack must communicate directly across browser tabs using modern web standards. Because browsers cannot bind raw UDP or TCP sockets, the underlying technology must support protocols like WebTransport or WebRTC to facilitate browser-to-node and browser-to-browser data exchange without requiring intermediary proxies14. The third criterion concerns Network Address Translation (NAT) traversal and peer discovery. The network must robustly penetrate NAT gateways and firewalls without requiring users to configure manual port forwarding16. This necessitates sophisticated hole-punching mechanisms, STUN/TURN alternatives, or secure relay fallbacks to ensure deterministic connectivity between ephemeral edge devices18. The fourth criterion mandates strict chunk verification. Immutable SLM model artifacts must be divided into discrete blocks that can be independently verified in transit. This prevents malicious actors in the P2P swarm from injecting poisoned weights into the data stream, which could compromise model behavior or trigger adversarial code execution20. The fifth criterion requires native Merkle support. Cryptographic tree structures, such as Merkle trees or BLAKE3 verified streaming, must be integrated into the protocol. This guarantees data integrity continuously during the download process, allowing the receiving node to verify sub-sequences of the .slm file instantly without waiting for the entire multi-gigabyte artifact to reside in memory22. The sixth criterion assesses the security model. The protocol must enforce mandatory end-to-end encryption, utilizing state-of-the-art cipher suites such as TLS 1.3, ChaCha20-Poly1305, or the Noise protocol framework. Furthermore, it requires robust peer authentication to ensure that nodes are communicating with mathematically verifiable identities17. The seventh criterion addresses operational complexity. The engineering burden placed on the MiniModel maintainers to implement, debug, and scale the networking stack must be minimized. Technologies that provide high-level, ergonomic Rust APIs for connection management and data multiplexing are heavily favored over low-level, primitive-heavy frameworks that require vast amounts of custom boilerplate. The eighth criterion focuses on user comprehension. The end-user experience must effectively obscure the inherent complexities of peer-to-peer networking. The process of acquiring a model from the MiniModel catalog must feel as deterministic, reliable, and instantaneous as a traditional centralized HTTPS download, shielding the user from swarm management or hash verification manual labor. The ninth criterion is the absolute fit with metadata-only servers. The architecture must flawlessly integrate with trackers, Distributed Hash Tables (DHTs), or signaling servers that orchestrate connections and verify hashes. These central infrastructure nodes must execute their routing duties without ever touching, buffering, or inspecting the actual .slm model payloads, adhering to the strict teleodynamic project boundaries7. The tenth and final criterion analyzes the risk of JavaScript runtime infrastructure dependency. The chosen stack must entirely avoid entanglement with Node.js, V8 engines, or JavaScript-heavy ecosystems. Incorporating dependencies that prioritize JavaScript runtimes violates the lean, zero-overhead Rust paradigm and introduces unnecessary maintenance burdens and security vulnerabilities associated with dual-language stacks25.

Detailed Technology Assessments

Rust-Native QUIC and Blob Transfer

Constructing a bespoke transfer protocol directly atop Rust QUIC implementations, utilizing foundational crates such as quinn or wtransport, provides absolute control over the networking stack26. QUIC operates over UDP, providing built-in TLS 1.3 encryption, stream multiplexing without the head-of-line blocking that plagues TCP, and highly optimized, low-latency handshakes14. By bypassing high-level frameworks, the engineering team can tailor the protocol specifically for the .slm file structures, optimizing buffer sizes and flow control algorithms exclusively for tensor weight distribution. The maturity within the Rust QUIC ecosystem is generally high at the transport layer, with robust libraries actively maintained and utilized in production environments. Browser compatibility is theoretically exceptional, provided WebTransport is utilized as the primary application-layer protocol. WebTransport allows browser sandboxes to connect to self-signed servers by verifying the SHA-256 hash of the TLS certificate, effectively bypassing the rigid Certificate Authority (CA) requirements that have historically hindered decentralized browser-based communication via WebSockets13. However, constructing a custom application-layer blob transfer protocol introduces severe operational complexity. While a library like wtransport handles the QUIC streams27, the MiniModel team would be forced to manually architect the chunk verification logic, peer discovery algorithms, and all NAT traversal mechanisms. Without existing infrastructure for Direct Connection Upgrade through Relay (DCUtR) or STUN-like UDP hole punching, developers must author complex network traversal logic entirely from scratch. Furthermore, chunk verification and Merkle support would require manual integration with external cryptographic crates, building the entire data integrity layer byte-by-byte. This approach guarantees zero JavaScript dependency and fits the metadata-only server model perfectly, but the development overhead renders it highly impractical for a lean engineering team.

Rust-libp2p

The rust-libp2p ecosystem represents the industry standard for modular peer-to-peer networking, providing a vast array of composable protocols18. It abstracts the complexities of the network layer by offering interchangeable transport modules (TCP, QUIC, WebRTC, WebTransport), multiplexing protocols (Yamux, mplex), security frameworks (Noise, TLS), and sophisticated peer routing via the Kademlia DHT14. The Rust implementation is exceptionally mature, powering the underlying networking for major blockchain architectures and distributed storage networks18. Browser compatibility within rust-libp2p is highly robust. The library facilitates WebTransport and WebRTC-direct connections, enabling seamless browser-to-node and browser-to-browser communications without relying on centralized relays13. The framework dramatically reduces handshake round-trip times; for example, a WebTransport connection established over QUIC requires only three round trips, compared to the six round trips necessitated by legacy WebSocket setups running over TCP14. NAT traversal is handled natively via the AutoNAT protocol and Circuit Relay v2, allowing private nodes located behind restrictive firewalls to negotiate direct connections or, if necessary, fall back to utilizing relay nodes15. Despite these profound networking capabilities, rust-libp2p is inherently agnostic to the application payload it carries. It provides the encrypted streams, but it does not dictate how a .slm file is chunked, hashed, or verified. The MiniModel project would still need to architect a custom chunking and Merkle verification overlay, potentially integrating libraries like bao for BLAKE3 streaming, on top of the generic libp2p streams22. The primary drawback is immense operational complexity. The modularity of libp2p introduces a notoriously steep learning curve, requiring the meticulous configuration of multiaddresses, stream muxers, and swarm behaviors. While it perfectly aligns with the metadata-only server constraint and avoids JavaScript dependencies, the sheer volume of boilerplate required to achieve simple verifiable file transfer makes it a heavy dependency for a project focused on AI model distribution.

BitTorrent-Style Chunking

The BitTorrent protocol remains the most battle-tested and widely deployed peer-to-peer file distribution mechanism in existence. Traditional implementations segment target files into uniformly sized pieces, hashing each piece with SHA-1 or SHA-256, and storing these sequential hashes in a centralized .torrent metadata file31. Modern Rust implementations, such as cratetorrent or the underlying mechanics of vflight, demonstrate that this paradigm can be highly performant, leveraging memory-safe language features and asynchronous I/O to maximize disk and network throughput21. While the conceptual model of tracking peers and verifying cryptographic chunks maps neatly to the MiniModel objectives, the legacy BitTorrent protocol exhibits significant structural drawbacks. Browser compatibility is inherently poor unless bridged via specialized protocols like WebTorrent, which relies heavily on WebRTC data channels and often necessitates complex JavaScript bridging layers that violate the Rust-first Wasm mandate. Furthermore, the traditional BitTorrent piece validation architecture requires downloading entire pieces (often several megabytes in size) before cryptographic verification occurs. If a piece fails validation, the entire block is discarded, wasting bandwidth31. Modern cryptographic approaches favor verified streaming, which arranges chunks in a binary Merkle tree, allowing for instantaneous verification of sub-sequences as small as one kilobyte without needing to hash the entire file22. While the fundamental BitTorrent concept—a metadata server acting as a tracker to coordinate swarms of peers exchanging verified chunks21—is perfectly aligned with the project goals, adopting the strict legacy BitTorrent wire protocol introduces unnecessary network overhead, relies on outdated hashing paradigms, and severely limits reach into browser-based Wasm environments.

Iroh

Iroh is a high-performance, modular networking stack written entirely in Rust that establishes direct QUIC connections between endpoints, utilizing Ed25519 public keys for addressing rather than fragile IP addresses16. When a direct connection fails due to restrictive NATs or symmetric firewalls, Iroh transparently and seamlessly falls back to utilizing relay servers, ensuring that connectivity is always maintained17. Iroh presents a compelling synthesis of libp2p's modular transport capabilities and BitTorrent's content addressing, wrapped in a highly ergonomic and focused Rust API. A critical advantage of Iroh is the iroh-blobs protocol, which specifically implements BLAKE3 verified streaming natively34. This allows a requesting node to ask for specific byte ranges of a .slm model; the providing node answers with data encoded as a BLAKE3 verified stream, ensuring data integrity continuously at the 1KiB chunk level20. This architecture is ideal for SLM distribution, where a consumer may wish to verify model weights incrementally during streaming, or even begin loading validated tensors into memory before the entire file transfer completes. Implementation maturity is exceedingly high. The Iroh team has shifted focus from attempting to replace IPFS to acting as a high-performance embedded networking library optimized for application developers37. Browser compatibility is currently robust and actively expanding. Iroh's Wasm integration allows compilation to the wasm32-unknown-unknown target, with WebSockets and WebTransport bridging specifically designed to facilitate browser environments communicating seamlessly with native nodes12. The security model is unimpeachable, relying on mutual authentication where the endpoint's public key acts directly as its TLS identity35. Crucially, Iroh fits perfectly with the metadata-only server constraint. The MiniModel project servers can simply host Iroh Relays or Mainline DHT bootstrap nodes to facilitate hole-punching and peer discovery, never proxying the multi-gigabyte .slm payloads17. Operational complexity is remarkably low compared to libp2p, and the risk of JavaScript dependency is absolute zero, as the stack is pure, idiomatic Rust17.

Pear, Bare, and Hypercore

The Hypercore protocol, originally emerging from the Dat ecosystem, functions as a distributed, append-only log23. Data integrity within this system is maintained via a flat, in-order Merkle tree, utilizing BLAKE2b hashes to secure blocks of data as they are sequentially appended to the log23. The broader ecosystem relies heavily on the Hyperswarm DHT for robust peer discovery and sophisticated UDP hole-punching mechanisms41. While the underlying cryptography and peer-to-peer networking concepts are theoretically sound, the Hypercore architecture presents severe conceptual and technical misalignments with the MiniModel project. Primarily, Hypercore is heavily optimized for mutating, dynamic datasets—append-only logs designed to synchronize file systems, chat applications, or real-time event streams23. A published .slm model, listed in the MiniModel catalog, is an immutable, static binary artifact. Wrapping an immutable tensor file in an append-only log structure introduces unnecessary conceptual complexity and computational overhead. More critically, the entire Hypercore ecosystem is deeply and inextricably rooted in JavaScript, specifically driven by the Pear and Bare runtimes25. While Rust ports do exist (such as the hypercore-protocol-rs and datrs crates), they have historically functioned as secondary implementations, lagging significantly behind the JavaScript reference implementations in both stability and feature completeness42. Relying on this technology stack introduces an unacceptably high risk of making JavaScript runtime infrastructure a core, inescapable dependency for the network25. Given the teleodynamic commitment to strict, executable boundaries within a Rust-oriented architecture, and the necessity of keeping the runtime footprint minimal for edge inference7, the Pear/Hypercore ecosystem must be definitively disqualified.

Plain Direct HTTP Peer-Piece Serving (Early Bridge)

A minimalist, highly pragmatic approach involves equipping native Rust peers with embedded HTTP/3 servers (utilizing optimized crates like h3 or wtransport) to serve .slm model chunks directly via standard RESTful endpoints45. In this simplified architecture, the central MiniModel server acts as a traditional HTTP tracker. When a client requests a model, the server provides a manifest containing the expected chunk hashes alongside a list of IP addresses of known peers currently seeding those chunks. The client then utilizes standard HTTP GET requests, leveraging Range headers, to retrieve specific chunks in parallel from the swarm. This approach offers the lowest possible operational complexity for an early-stage deployment. Browser compatibility is absolutely flawless, as any modern web client can issue standard fetch requests to retrieve data. However, verification remains entirely manual; the client must hash the downloaded payload against the metadata provided by the central server before trusting the bytes. The fatal flaw of this method is the complete lack of a comprehensive NAT traversal story. Peers sitting behind standard consumer routers, carrier-grade NATs, or corporate firewalls cannot natively host publicly accessible HTTP endpoints without manual port forwarding—an unacceptable requirement for a consumer-grade application. While this architecture serves as an excellent, low-friction "Phase 1" bridge to bootstrap the network among dedicated, publicly routable seeders (such as cloud instances), it simply cannot function as the terminal peer-to-peer architecture for a truly decentralized, ubiquitous SLM exchange.

Synthesis and Architectural Tradeoffs

The quantitative and qualitative tradeoffs of the six evaluated systems can be mapped directly across the defined constraints. The following table synthesizes these capabilities to highlight the optimal path forward for the MiniModel ecosystem.

The exhaustive analysis indicates that Iroh, specifically utilizing the iroh-blobs protocol, provides the most cohesive alignment with the strict MiniModel objectives. It masterfully abstracts the deep complexities of QUIC connections, connection migration, and NAT traversal while providing out-of-the-box BLAKE3 verified streaming explicitly tailored for immutable data blobs20. Conversely, while rust-libp2p offers supreme networking modularity, it demands significant engineering boilerplate to implement the chunking cryptography required for .slm artifacts. Hypercore poses a severe risk of JavaScript ecosystem entanglement, effectively polluting the Rust ecosystem25, and raw HTTP lacks the NAT penetration required for a genuinely decentralized consumer mesh. Therefore, Iroh is recommended as the foundational technology, augmented by a phased integration path.

Phased Network Deployment Strategy

To mitigate operational risk, ensure continuous delivery of the .slm exchange capabilities, and validate cryptographic assumptions before introducing network latency, a staggered, five-phase rollout is strongly recommended. This approach isolates data integrity from network transport, allowing the MiniModel system to mature safely.

Phase 1: Local Manifests and Receipts

The foundational phase focuses exclusively on data integrity and cryptographic verification, operating completely isolated from any network transport. The engineering mechanism requires the implementation of a deterministic chunking algorithm utilizing the BLAKE3 hashing function21. The .slm files are segmented into static sizes, and a Merkle tree is generated representing the exact state of the artifact. The primary deliverable is a local Rust Command Line Interface (CLI) utility capable of generating a structured JSON or binary manifest of chunk hashes for any given .slm model. This utility must also be capable of validating an existing model on disk against a provided manifest. The objective is to ensure that the foundational cryptographic proofs are mathematically sound and highly performant in Rust before introducing the complexities of asynchronous network streams.

Phase 2: Local Peer-Piece Export/Import

This subsequent phase introduces the concept of data portability and reassembly without requiring active network streaming. The MiniModel runtime is updated to seamlessly ingest and export disparate chunks of models based on the cryptographic manifests generated during Phase 1\. The deliverable is the programmatic ability to reconstruct a full .slm model artifact from a fragmented, unordered directory of validated chunks, effectively simulating a completed peer-to-peer download entirely on the local file system. The objective is to validate the file I/O operations, memory buffering strategies, and continuous BLAKE3 hash verification under standard operating system constraints, ensuring that the strict teleodynamic resource bounds are respected and that memory starvation does not occur7.

Phase 3: Known-Peer Direct Transfer

This phase marks the introduction of active network transport, initially utilizing the Plain Direct HTTP Peer-Piece Serving model as an early bridge. A central, metadata-only signaling server is deployed at https://MiniModel.org/. It maps .slm cryptographic identifiers to the static IP addresses of known, highly available seeders operated by the project maintainers. The deliverable is a Rust client that queries the metadata server, receives a manifest and a list of HTTP endpoints, and executes parallel GET requests using byte-range headers to download chunks from the known peers. The objective is to establish baseline network transfer rates, validate concurrent connection handling within the asynchronous runtime, and unequivocally prove the efficacy of the metadata-only server constraint in a production-like environment10.

Phase 4: Optional Peer Discovery

This critical phase transitions the network from a federated, known-peer model to a decentralized topology utilizing Iroh. The core integration of iroh-net and iroh-blobs takes place. The central server architecture transitions from an HTTP directory to hosting an Iroh relay and a Mainline DHT bootstrap node17. Clients establish secure QUIC connections directly via Ed25519 node IDs16. Publicly routable peers begin seeding .slm models to one another, with the Iroh relay gracefully facilitating NAT hole-punching for peers trapped behind consumer routers. The objective is to test NAT traversal reliability and connection stability across highly diverse and restrictive consumer network environments.

Phase 5: Broader P2P Network

The final phase represents the full realization of the decentralized SLM exchange. This involves broad browser integration, where Wasm-compiled Iroh clients execute directly within browser tabs, utilizing WebTransport or secure WebSockets to connect seamlessly to native Rust desktop nodes13. The deliverable is a fully opaque, frictionless user experience where initiating a model download automatically sources chunks from a massive global swarm of desktop and browser nodes, with data integrity verified instantaneously via BLAKE3 streaming34. The objective is to achieve global scale, extreme high availability, and maximum network throughput without ever relying on centralized bandwidth or infrastructure.

Vulnerability Analysis and Unresolved Vectors

Deploying a decentralized exchange for executable or interpretable binary formats, such as SLMs, introduces highly distinct and complex risk profiles that must be aggressively modeled and mitigated. The most critical threat is malicious chunk injection and systemic swarm poisoning. In a decentralized, open swarm, malicious or compromised actors will inevitably attempt to inject corrupted or manipulated tensor weights into the network. If an SLM is tampered with, it could lead to arbitrary code execution (depending on the specific runtime Application Binary Interface) or subtle, insidious behavioral poisoning of the AI. The strict reliance on BLAKE3 verified streaming fundamentally mitigates the code execution risk; the cryptographic protocol ensures that a malicious chunk is identified and discarded mathematically before it can be committed to disk or loaded into active memory22. However, a systemic denial-of-service (DoS) risk remains. A swarm flooded with malicious peers could force legitimate clients to continuously download, fail validation, discard, and re-request chunks, exhausting bandwidth and battery life. A secondary vulnerability involves data availability and rapid seeder attrition. Peer-to-peer networks inherently suffer from the "leech" problem. Because SLMs are heavily optimized and relatively small (frequently under 3GB)2, they download extremely rapidly. Consequently, peers spend very little time actively participating in the swarm. Without a built-in cryptographic or economic incentive to continue seeding, rare, specialized, or older .slm models may completely lose availability as peers drop offline. To mitigate this, the MiniModel project must commit to maintaining baseline infrastructure—acting as high-availability, permanent seeders—to guarantee the distribution of critical foundation models3. Browser NAT traversal restrictions present a significant unresolved technical vector. While WebTransport is highly performant and secure, browser security sandboxes strictly prohibit web applications from binding to raw UDP sockets39. Therefore, browser nodes cannot participate in traditional UDP hole-punching mechanisms used by native desktop peers. It remains an open question how effectively browser nodes can act as active seeders rather than just passive leechers. While WebRTC does allow browser-to-browser P2P communication14, managing the heavy Session Description Protocol (SDP) signaling overhead required to coordinate thousands of simultaneous chunk requests may severely bottleneck the JavaScript main thread, degrading the user experience. Finally, metadata server liability must be continuously evaluated. While the central servers located at https://MiniModel.org/ strictly host cryptographic manifests and routing data, acting as a tracker inherently involves mapping IP addresses to specific content. Regulatory frameworks regarding the facilitation of peer-to-peer transfers are complex and vary by jurisdiction. This may pose a liability risk, even if the project enforces strict, open-source model license policies7. Ongoing legal consultation and adherence to strict zero-logging policies on the DHT bootstrap nodes are essential.

Specification: Minimum Viable P2P Protocol

The Minimum Viable Protocol (MVP) for the initial decentralized MiniModel SLM exchange must prioritize deterministic behavior, cryptographic safety, and simplicity over complex, fully autonomous mesh features. The MVP architecture is strictly defined across four layers.

Acceptance Criteria

Prior to transitioning the peer-to-peer architecture from internal development to a public release within the MiniModel ecosystem, the system must satisfy rigorous empirical testing. Acceptance is strictly contingent on meeting several non-negotiable benchmarks. The protocol must achieve a minimum sustained transfer rate equivalent to 85% of available TCP bandwidth under ideal network conditions. This proves that QUIC packet pacing, encryption overhead, and real-time chunk verification do not introduce severe CPU bottlenecks. Connection establishment, including the handshake and TLS negotiation, must occur consistently within 3 round-trip times14. Furthermore, the implementation must adhere strictly to teleodynamic resource bounds. During a multi-gigabyte .slm transfer, the Rust networking daemon must not exceed 50 MB of resident RAM footprint. It must utilize zero-copy I/O mechanisms wherever possible to stream verified chunks directly to disk storage21. CPU utilization dedicated to BLAKE3 verification must remain under 15% on a standard multi-core consumer processor, ensuring that the actual model inference threads are never starved for compute resources.

Tests Needed Before Public Release

To validate the acceptance criteria, specific, highly structured test harnesses must be developed and executed before public availability. These tests must isolate various failure domains within the distributed system. First, an Adversarial Swarm Test must be conducted. In this simulated environment, a controlled swarm is instantiated where 30% of the participating peers are programmed to actively serve corrupted, randomized, or subtly altered chunk payloads. The client must successfully identify the corruption, aggressively ban the malicious peers from its local routing table, and seamlessly assemble the exact cryptographic match of the target .slm file without panicking, crashing, or entering an infinite retry loop22. Second, a NAT Penetration Rate analysis must be executed using a framework like Chaos Mesh. The Iroh hole-punching mechanism must successfully negotiate direct UDP connections in at least 70% of standard simulated consumer NAT configurations (including symmetric and cone NATs). This ensures the network scales efficiently and limits reliance on the bandwidth-constrained fallback relays17. Finally, a Zero-JS Verification audit must be performed. The compiled binary, specifically the wasm32-unknown-unknown target intended for deployment via https://MiniModel.MiRust.com/, must be deeply audited to ensure absolutely zero dependency on Node.js, V8, or external JavaScript runtimes. The Wasm artifacts must be tested in a headless browser environment to guarantee that the Rust supply chain remains pristine and that all networking calls are correctly bridged through native browser APIs like WebTransport10.

Works cited

1. Small Language Models (SLMs): Comprehensive Guide 2026 \- CogitX, https://cogitx.ai/blog/small-language-models-slms-comprehensive-guide-2026
2. The Best Open-Source Small Language Models (SLMs) in 2026 \- BentoML, https://www.bentoml.com/blog/the-best-open-source-small-language-models
3. Small Language Models (SLM): A Comprehensive Overview \- Hugging Face, https://huggingface.co/blog/jjokah/small-language-model
4. What Are Small Language Models (SLMs)? \- Microsoft Azure, https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-are-small-language-models
5. SLMs vs Quantized LLMs: What Actually Works for Browser AI | by Vishal Mysore \- Medium, https://medium.com/@visrow/slms-vs-quantized-llms-what-actually-works-for-browser-ai-c4bf3d1485b8
6. What are Small Language Models (SLM)? \- IBM, https://www.ibm.com/think/topics/small-language-models
7. The five commitments of Teleodynamic Learning \- MiRust, https://mirust.com/five-commitments-of-teleodynamic-learning/
8. slm\_inference \- Lib.rs, https://lib.rs/crates/slm\_inference
9. All MINI Models, Prices, Features & Details, https://www.miniusa.com/model.html
10. Research \- MiRust, https://mirust.com/research/
11. Rust Software Development Agency | Out of the Box Systems, https://www.obox.systems/services/rust-development
12. nnrp-core — Rust network library // Lib.rs, https://lib.rs/crates/nnrp-core
13. Browser Node Connectivity \- libp2p, https://libp2p.io/docs/browser-connectivity/
14. WebTransport \- libp2p, https://libp2p.io/docs/webtransport/
15. libp2p Connectivity, https://libp2p-microgen.vercel.app/
16. Deep dive into iroh: A replacement for WireGuard or a P2P layer for your application?, https://kerkour.com/iroh-v1-p2p
17. What is iroh?, https://docs.iroh.computer/what-is-iroh
18. Introduction to libp2p \- Max Inden, https://max-inden.de/static/introduction-to-libp2p.pdf
19. libp2p \- A modular network stack | libp2p, https://libp2p.io/
20. iroh\_blobs::protocol \- Rust \- Docs.rs, https://docs.rs/iroh-blobs/latest/iroh\_blobs/protocol/index.html
21. GitHub \- danzbyrd/vflight: Share files over the Veilid distributed network, https://github.com/danzbyrd/vflight
22. n0-computer/abao: an implementation of BLAKE3 verified streaming \- GitHub, https://github.com/n0-computer/abao
23. Dat (software) \- Grokipedia, https://grokipedia.com/page/Dat\_(software)
24. wtransport \- Rust, https://docs.rs/wtransport
25. \[ RFC \] AeroShare: User-to-User Encrypted P2P Transfer (Peer) · axpdev-lab aeroftp · Discussion \#284 \- GitHub, https://github.com/axpdev-lab/aeroftp/discussions/284
26. Changelog \- Iroh, https://www.iroh.computer/changelog
27. wtransport \- crates.io: Rust Package Registry, https://crates.io/crates/wtransport
28. Introducing WTransport: Empowering WebTransport in Rust\! \- Reddit, https://www.reddit.com/r/rust/comments/13sq1am/introducing\_wtransport\_empowering\_webtransport\_in/
29. wtransport/webtransport-rs \- GitHub, https://github.com/wtransport/webtransport-rs
30. Referendum \#146 \- Polkadot Polkassembly, https://polkadot.polkassembly.io/referenda/146
31. Understanding BitTorrent 2: A Deep Dive into Torrent file \- 株式会社NXTED, https://www.nxted.co.jp/blog/blog\_detail?id=48
32. ＃47 Understanding BitTorrent 2: A Deep Dive into Torrent file \- Zenn, https://zenn.dev/nxted\_sapporo/articles/bd6593d4ad23a9
33. I wrote cratetorrent, a BitTorrent engine in Rust\! \- Reddit, https://www.reddit.com/r/rust/comments/kiah3q/i\_wrote\_cratetorrent\_a\_bittorrent\_engine\_in\_rust/
34. Blobs \- Iroh Docs, https://docs.iroh.computer/protocols/blobs
35. iroh \- crates.io: Rust Package Registry, https://crates.io/crates/iroh
36. iroh\_blobs \- Rust \- Docs.rs, https://docs.rs/iroh-blobs/latest/iroh\_blobs/
37. Iroh: A library to establish direct connection between peers \- Hacker News, https://news.ycombinator.com/item?id=44379173
38. Iroh-blobs | Hacker News, https://news.ycombinator.com/item?id=45727557
39. Iroh & the Web, https://www.iroh.computer/blog/iroh-and-the-web
40. hypercore \- Rust \- Docs.rs, https://docs.rs/hypercore
41. GitHub \- datrs/hyperspace-rs: Hypercore storage and replication daemon, written in Rust, https://github.com/datrs/hyperspace-rs
42. hypercore\_protocol \- Rust \- Docs.rs, https://docs.rs/hypercore-protocol
43. datrs/hypercore-protocol-rs \- GitHub, https://github.com/datrs/hypercore-protocol-rs
44. datrs/hypercore: Secure, distributed, append-only log \- GitHub, https://github.com/datrs/hypercore
45. WebTransport server support in the h3 crate is available today\! : r/rust \- Reddit, https://www.reddit.com/r/rust/comments/14afmic/webtransport\_server\_support\_in\_the\_h3\_crate\_is/
46. Small Language Models vs Large Language Models: Key Advantages for Engineering Teams | Augment Code, https://www.augmentcode.com/learn/small-language-models-vs-large-language-models-key-advantages-for-engineering-teams
47. fastnet \- crates.io: Rust Package Registry, https://crates.io/crates/fastnet
48. The Hitchhiker's Guide to Building a Distributed Filesystem in Rust. The continuation (part 2\) | by xorio | System Weakness, https://systemweakness.com/the-hitchhikers-guide-to-building-a-distributed-filesystem-in-rust-the-continuation-part-2-ad1fd8bc9cf8