Architecting Third-Party-Free Peer-to-Peer Networks: A Dual Desktop and Web Application Paradigm

Full report

On this page

The Evolution and Re-Emergence of Pure Peer-to-Peer Systems

The architectural transition from centralized client-server models to peer-to-peer (P2P) distributed computing represents a fundamental shift in network engineering, designed to transfer the burden of resource sharing, bandwidth, and processing from centralized infrastructure directly to the edges of the internet1. Historically, the term "peer-to-peer" was popularized in the late 1990s by file-sharing protocols and distributed computing systems such as Gnutella, Freenet, and Seti@Home, which sought to harness dormant CPU cycles, storage, and human presence across transient populations of network nodes1. These early architectures were characterized by their ability to self-organize, adapt to network failures, and resist censorship without requiring the intermediation or administrative overhead of a central authority1. However, as the commercial internet evolved, a significant portion of modern systems labeled as P2P began to rely heavily on server-mediated architectures. In these hybrid models, central authorities act as signaling servers, discovery registries, Session Traversal Utilities for NAT (STUN) servers, or Traversal Using Relays around NAT (TURN) relays1. While these server-mediated designs simplify peer discovery and network traversal, they undermine the core tenets of resilience, privacy, and true decentralization, reintroducing single points of failure and surveillance vulnerabilities2. Designing a dual desktop and web application architecture that mandates the absolute absence of third-party intermediaries introduces profound engineering complexities. Browsers, constrained by strict security sandboxes, cannot open raw Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) sockets6. Consequently, establishing a direct connection between an arbitrary web application and a desktop node requires sophisticated workarounds involving WebRTC, WebTransport, manual Session Description Protocol (SDP) exchanges, and Local Network Access (LNA) policy bypasses7. This report comprehensively details a unified architecture leveraging the Tauri framework and rust-libp2p for the desktop environment, paired with modern web standards and js-libp2p for the browser. By synthesizing native routing capabilities, cryptographic identity verification, and manual out-of-band signaling protocols, the architecture defined herein achieves a "pure" P2P state, entirely devoid of external infrastructure dependencies.

The Desktop Application Subsystem: Tauri and Rust Integration

The desktop node serves as the anchor of the pure P2P network, possessing the operating system-level permissions required to manipulate network interfaces, bind to arbitrary local ports, and execute complex cryptographic routines. To achieve optimal performance while maintaining a modern graphical interface, the architecture utilizes the Tauri framework in place of legacy, resource-heavy alternatives such as Electron10.

Architectural Advantages of Tauri over Legacy Frameworks

Electron relies on bundling a complete Chromium browser engine and a Node.js runtime into every compiled application11. This architecture inherently results in a massive baseline binary size, often exceeding 150 megabytes, and substantial memory overhead due to the multi-process model required to run distinct main and renderer processes atop the V8 engine11. Tauri, conversely, utilizes the host operating system's native webview component—such as WebView2 on Windows, WebKit on macOS, and WebKitGTK on Linux—which fundamentally separates the frontend rendering process from the core business logic12. By offloading backend operations to a compiled Rust binary, Tauri completely eliminates the Chromium tax. A minimal Tauri application can achieve a core executable size of under 600 kilobytes and typically idles between 20 to 100 megabytes of RAM11. This lean profile is critical in a decentralized context, where P2P network daemons, cryptographic handshakes, and active swarm management continuously consume CPU cycles. Real-world benchmarking demonstrates this efficiency; for example, the Authme application requires an 85-megabyte installer and 120 megabytes of idle RAM when built with Electron, compared to a 2.5-megabyte installer and 80 megabytes of idle RAM when built with Tauri11.

Furthermore, Tauri enforces a robust, default-deny security posture through a strict capability-based allowlist14. Native Application Programming Interfaces (APIs)—such as filesystem access, shell execution, or network socket bindings—are disabled by default and must be explicitly declared and scoped within the application's configuration at compile time12. This mitigates the risk of Cross-Site Scripting (XSS) vulnerabilities escalating into Remote Code Execution (RCE), a vector that is historically problematic in Node.js-coupled desktop frameworks where JavaScript commands can easily traverse the Inter-Process Communication (IPC) bridge to access system resources13.

Managing the Network Swarm via the Actor Model

The networking backend of the desktop application relies on rust-libp2p, a modular, transport-agnostic networking framework designed for global-scale P2P applications15. The core engine of rust-libp2p is the Swarm, a comprehensive state machine that encapsulates the active network connections, routing tables, substream multiplexers, and the collective NetworkBehaviour of the node16. A critical engineering challenge arises when integrating the asynchronous rust-libp2p Swarm with the Tauri command interface and local IPC servers. Attempting to share the Swarm across multiple threads using standard mutual exclusion locks (Mutex) frequently leads to thread starvation and deadlocks during high-throughput I/O operations, as the network stack blocks waiting for user interface callbacks19. To resolve this contention, the architecture implements the Actor model. The Swarm is isolated within a dedicated, detached asynchronous Tokio task19. Communication between the Tauri IPC layer, the local HTTP/WebSocket server, and the networking backend occurs exclusively via multi-producer, single-consumer (mpsc) message channels19. Non-blocking operations are orchestrated using the tokio::select\! macro, allowing the backend to concurrently process incoming network events, application-layer commands, and local user interface updates without resource locking19. This ensures that the node can maintain high-throughput protocol multiplexing—such as running GossipSub, Kademlia DHT, and UPnP discovery simultaneously—while remaining highly responsive to local user input19.

Browser-Based Nodes and the Security Sandbox

While desktop nodes operate with relatively few restrictions, enabling native integration with the operating system's networking stack, web applications are tightly bound by the browser's security sandbox. The JavaScript implementation of the network stack, js-libp2p, must navigate an environment where access to raw TCP or UDP sockets is strictly prohibited6. Consequently, browser-based peer communication must occur exclusively via WebRTC, WebTransport, or WebSockets, each presenting unique engineering hurdles when forced to operate in a pure, zero-third-party environment22.

WebTransport and the Certificate Hash Paradigm

WebTransport is a modern web API operating over HTTP/3 and the QUIC protocol, engineered to provide multiplexed, low-latency, bidirectional client-server communication7. Unlike WebSockets, which run over TCP and suffer from head-of-line blocking where a single lost packet delays all subsequent data, WebTransport natively supports both reliable bidirectional streams and unreliable UDP-like datagrams7. This makes it exceptionally well-suited for high-throughput P2P applications, allowing media streaming, state synchronization, and large file transfers to occur over independent streams within a single transport session7. A fundamental barrier to utilizing WebSockets or standard HTTPS APIs in P2P browser applications is the strict requirement for a trusted Transport Layer Security (TLS) certificate signed by a recognized Certificate Authority (CA)23. P2P nodes typically operate on dynamic residential IP addresses without associated domain names, making traditional CA validation both economically and technically impossible23. Without a valid certificate, browsers will aggressively block the connection, displaying insecure origin warnings and terminating the socket23. WebTransport circumvents this centralized trust limitation through the serverCertificateHashes feature. This mechanism allows a browser to establish a secure connection to a server utilizing a self-signed certificate, provided the client application is supplied with the exact cryptographic hash of the remote node's certificate prior to dialing7. However, major browser engines, specifically Chromium, impose stringent cryptographic constraints to mitigate the abuse of this feature. To be accepted via the serverCertificateHashes option, the self-signed certificate must utilize the Elliptic Curve Digital Signature Algorithm (ECDSA) with the secp256r1 (NIST P-256) named group, as RSA keys are explicitly rejected by the implementation29. Furthermore, the certificate must have a maximum validity period not exceeding 14 days from the time of issuance24. In this architecture, when the Tauri desktop app initializes, the Rust backend programmatically generates a compliant, ephemeral self-signed ECDSA certificate valid for exactly 10 days30. The backend calculates the SHA-256 hash of the Distinguished Encoding Rules (DER) formatted certificate and embeds it directly within the node's libp2p multiaddress30. When the web application attempts to dial the desktop node, it extracts this hash and passes it into the WebTransport constructor, achieving a highly secure, CA-independent, encrypted connection that fully satisfies the browser's origin security model without relying on a centralized certificate authority32.

WebRTC and the Direct Connectivity Model

For true browser-to-browser communication, where WebTransport is inapplicable due to its client-server topology, WebRTC remains the sole viable transport mechanism7. Originally conceived for real-time video and audio conferencing, WebRTC inherently supports native acoustic echo cancellation, automatic noise reduction, low-latency data channels, and built-in datagram encryption34. Within the libp2p ecosystem, WebRTC is bifurcated into two distinct protocols to handle varying network topologies efficiently: WebRTC Direct and standard WebRTC6. WebRTC Direct is designed exclusively for connecting a browser to a standalone server or desktop node6. In this model, the standalone node encodes its UDP port and its TLS certificate fingerprint directly into its multiaddress (e.g., /ip4/192.168.1.10/udp/1234/webrtc-direct/certhash/\<hash\>/p2p/\<peer-id\>)6. The dialing browser parses this address, extracts the User Fragment (ufrag) from the hash prefix, and infers the necessary remote SDP parameters locally, completely bypassing the need for a traditional signaling handshake8. Upon establishing the initial Datagram Transport Layer Security (DTLS) and Stream Control Transmission Protocol (SCTP) channels, authenticity is verified via a Noise XX cryptographic handshake executed over the initial WebRTC data channel, ensuring the remote peer possesses the private key corresponding to its advertised Peer ID8. Conversely, standard WebRTC is utilized for private-to-private, browser-to-browser connections6. This standard requires the exchange of complex SDP offers and answers alongside Interactive Connectivity Establishment (ICE) candidates4. In conventional internet architectures, this highly dynamic metadata is routed through a centralized WebSocket signaling server that acts as a matchmaker36. To remain strictly compliant with the zero-third-party mandate, this architecture must discard automated signaling servers, forcing the implementation of a completely manual, out-of-band signaling process38.

Achieving Zero-Third-Party Discovery and Signaling

The defining constraint of this architecture is the absolute prohibition of external registries, STUN/TURN servers, and signaling relays. Nodes must locate one another, exchange cryptographic parameters, and negotiate direct connections using only local capabilities, computational logic, or direct human intervention.

Manual Signaling via Out-of-Band Exchange

To establish a browser-to-browser WebRTC connection without a signaling server, the negotiation process is entirely decentralized and pushed directly to the user interface38. The protocol unfolds through a precise state machine orchestration involving the RTCPeerConnection API and human-mediated data transfer35. The sequence initiates when the host peer creates an RTCPeerConnection object and generates an SDP offer via the createOffer() method36. Because the architecture explicitly avoids STUN servers to discover public IP addresses, the ICE gathering subsystem relies solely on host candidates (local IPv4/IPv6 addresses) or ports previously opened via local router configuration protocols4. Standard WebRTC implementations utilize "trickle ICE," continually emitting new network candidates as they are discovered36. However, manual signaling requires the application to suspend output until all ICE gathering concludes, ensuring that the final SDP string presented to the user contains every possible routing path39. Once gathering is complete, the initiating client presents the base64-encoded SDP offer to the user39. The user must copy this string to their clipboard and transmit it to the receiving peer via a secure, external out-of-band channel, such as an encrypted messaging application, an email, or by generating a QR code that the remote peer scans38. The receiving peer pastes the SDP offer into their respective client, which processes the payload via setRemoteDescription(), transitioning its internal state to acknowledge the remote capabilities36. The receiving client then generates an SDP answer via createAnswer(), awaits its own local ICE gathering completion, and outputs the resulting string to its user36. This answer is transmitted back to the initiator, who applies it via setRemoteDescription()35. The RTCPeerConnection shifts to the connected state, and the peer-to-peer data channel successfully opens, concluding the manual handshake35.

While manually exchanging large cryptographic payloads introduces significant friction to the user experience, it provides mathematical certainty that no intermediary server has monitored the signaling metadata, logged the IP addresses, or intercepted the connection parameters38.

Local Discovery via Multicast DNS (mDNS)

For nodes operating within the same Local Area Network (LAN), forcing a manual SDP exchange is unnecessarily cumbersome. To automate local discovery, the architecture utilizes Multicast DNS (mDNS) and DNS Service Discovery (DNS-SD), technologies foundational to zero-configuration networking protocols like Apple's Bonjour44. Nodes broadcast UDP query packets on port 5353 to the standardized multicast address 224.0.0.251 for IPv4, or ff02::fb for IPv645. By advertising its presence, protocol support, and listening ports, a node enables peers to automatically resolve its dynamically assigned .local hostname and establish direct WebRTC or WebTransport connections without user intervention44. However, the mDNS implementation in modern web browsers has been fundamentally altered to prioritize user privacy. Historically, WebRTC suffered from a severe vulnerability where it leaked a user's genuine local IP address through ICE candidate gathering47. Malicious websites could silently instantiate an RTCPeerConnection to harvest internal subnet IPs, enabling cross-device tracking, geolocation piercing (even behind a VPN), and corporate network topology fingerprinting47. To mitigate this silent tracking, browsers now actively obfuscate local IP addresses by generating random mDNS hostnames (e.g., e6d4675b-0c93-43d1-b4be-f8ae4d050721.local) to represent local ICE candidates47. When a peer receives this obfuscated candidate, it must resolve the .local hostname on the local network to determine the actual IP address for connectivity checks47. This protection ensures that only peers physically present on the same subnet can resolve the hostname, shielding the underlying IP structure from remote malicious JavaScript47. The architecture natively accommodates these obfuscated candidates, ensuring that local peers can still discover one another autonomously while maintaining the browser's privacy safeguards47. It is worth noting that recent security research indicates that simply joining the mDNS multicast group triggers local network permission prompts on newer operating systems like Android 16, requiring careful handling of device permission flows within the web application51.

Wide-Area Discovery: The Kademlia Distributed Hash Table (DHT)

For wide-area network (WAN) discovery extending beyond the scope of a single LAN, the architecture utilizes the Kademlia Distributed Hash Table (DHT) implementation provided by libp2p52. Kademlia maps peer identities and content into a unified cryptographic keyspace, using the XOR (exclusive OR) distance metric to mathematically determine the logical "closeness" of any two nodes52. This distance metric establishes several vital mathematical properties: a node's distance to itself is exactly zero (Identity), the distance is symmetrical regardless of the direction of measurement, and the topology strictly adheres to the triangle inequality52. Nodes organize their knowledge of the network into routing tables divided by K-Buckets, where each bucket contains nodes that share a specific prefix length with the local node's ID52. This highly structured organization ensures that lookup requests require at most [Figure omitted from source export] hops to find any node in a network of [Figure omitted from source export] nodes52. The DHT facilitates two primary operations essential for a P2P architecture:

1. Peer Routing (FIND\_NODE): Resolving a cryptographic Peer ID to its active, globally routable network multiaddresses52.
2. Content Routing (GET\_PROVIDERS): Discovering peers that host specific data objects, allowing nodes to locate distributed files or decentralized application state52.

In standard deployments, a DHT requires hardcoded "bootstrap nodes"—centralized, high-uptime infrastructure provided by developers to serve as initial entry points for new clients joining the network52. Because this architecture strictly forbids reliance on third-party infrastructure, the system cannot utilize public bootstrap nodes managed by organizations like Protocol Labs56. Consequently, the DHT must be organically bootstrapped by the users themselves. A user must execute at least one successful manual SDP exchange or rely on local mDNS discovery to connect to their very first peer. Once this initial connection is formed, the local node executes a FIND\_NODE request for its own Peer ID against the newly connected peer, querying for the [Figure omitted from source export] closest nodes52. The node systematically queries these discovered peers in parallel (governed by the [Figure omitted from source export] concurrency parameter, typically set to 3), iteratively expanding its routing table and organically merging into the wider Kademlia swarm without any centralized assistance52. Furthermore, nodes that detect they possess a publicly reachable IP address automatically transition from "client mode" to "server mode," actively storing provider records and responding to network queries to support the health of the DHT52.

Navigating Network Address Translation (NAT) Without Relays

Network Address Translation (NAT) is a routing mechanism that maps multiple internal private IP addresses to a single external public IP address58. While NAT is essential for conserving the limited IPv4 address space, it actively obstructs peer-to-peer networking. Most consumer and corporate NAT firewalls block unsolicited inbound traffic, silently dropping connection attempts unless an outbound packet previously established a stateful mapping in the router's translation table58. The standard libp2p mechanism for navigating restrictive NATs involves the use of Circuit Relay v2 and Direct Connection Upgrade through Relay (DCUtR)58. In this flow, two private peers connect to a public relay node, which forwards signaling traffic. The peers measure their respective round-trip times to the relay and simultaneously dispatch Sync and Connect packets to "punch a hole" through their respective firewalls, tricking the NAT into accepting the incoming traffic27. While DCUtR successfully mitigates NAT traversal for endpoint-independent configurations, it intrinsically relies on the public relay—a third party58. Furthermore, DCUtR frequently fails when encountering symmetric NATs, which assign different external ports for every unique destination IP, making port prediction impossible64. To achieve strict zero-third-party compliance, the desktop Tauri node completely discards the relay architecture and instead employs active router configuration protocols: Universal Plug and Play (UPnP) and the NAT Port Mapping Protocol (NAT-PMP)59. Upon initialization, the Rust networking backend queries the local network gateway via the Internet Gateway Device (IGD) protocol66. If the router supports automated configuration, the application programmatically requests the gateway to forward a specific external TCP/UDP port directly to the internal desktop machine58. If successful, this operation allows the node to accept unsolicited inbound connections natively58. The backend subsequently emits an ExternalAddrConfirmed event to the Swarm, updating the node's multiaddress to reflect its new, globally routable public IP and port66. In scenarios where the router firmly rejects UPnP requests, or the network is situated behind Carrier-Grade NAT (CGN) typical of mobile networks67, the architecture relies on IPv6. As IPv6 adoption expands globally, nodes are assigned globally routable addresses by default, eliminating the need for NAT entirely and allowing true end-to-end connectivity, provided host-level firewalls are appropriately configured.

Overcoming Modern Browser Constraints (2025-2026)

Deploying a pure P2P architecture involving browser nodes requires navigating an increasingly hostile security environment. Between 2025 and 2026, major browser vendors, spearheaded by Chromium-based engines, are deploying exceptionally strict Local Network Access (LNA) constraints aimed at locking down intranet communications9.

The Local Network Access (LNA) Paradigm

Historically, any public website could freely issue HTTP requests or WebSocket connections to localhost (127.0.0.1) or private subnet IP addresses (e.g., 192.168.x.x)68. Malicious actors frequently exploited this capability to execute Cross-Site Request Forgery (CSRF) attacks against vulnerable local routers, modify DNS settings, or fingerprint internal network topologies9. Starting with Chrome 142, and seeing further aggressive expansions in Chrome 145 and 147, LNA restrictions strictly prohibit public websites from communicating with local network targets unless a complex set of criteria are met9. The specification divides all IP addresses into three distinct spaces: loopback (accessible only on the local host), local (meaningful only within the current subnet), and public (globally routable)70. To interact with loopback or local addresses, the following conditions must be satisfied:

1. The initiating web application must be served from a secure context (HTTPS)9.
2. The browser intercepts the connection attempt and issues an explicit, user-facing permission prompt, separating the consent into distinct local-network and loopback-network permissions68.
3. For programmatic fetch requests, the API must explicitly declare the target intent by including the targetAddressSpace: "local" property within the request options9.

Furthermore, LNA constraints integrate deeply with Mixed Content policies70. A secure web application loaded via HTTPS is fundamentally forbidden from fetching resources via insecure protocols like HTTP or standard WebSockets (WS)71. While browsers typically exempt localhost or .local domains from mixed content rules to aid local development9, connecting directly to raw LAN IP addresses (e.g., 192.168.1.50) is aggressively blocked as an insecure mixed content violation69.

Bypassing LNA via WebTransport and Service Workers

Because the architecture demands that the web application communicate with a locally running Tauri desktop backend (or another peer on the LAN) without relying on external domain names or CA-signed certificates, it must seamlessly bypass these LNA and Mixed Content barriers69. The solution relies entirely on the previously detailed WebTransport implementation72. The Tauri backend generates its short-lived ECDSA certificate and serves WebTransport natively over HTTPS on a designated local port32. By utilizing the serverCertificateHashes configuration within the browser, the web application securely authenticates the self-signed certificate. This maneuver fully satisfies the browser's secure context and mixed content prerequisites without triggering plaintext HTTP blocking, allowing the connection to the raw local IP address to proceed32. However, WebTransport only supports raw data streams and datagrams; it does not natively support standard HTTP requests72. To ensure that legacy REST APIs, GraphQL queries, or standard HTTP traffic can still be routed from the web application to the Tauri backend, the architecture employs a Service Worker73. The Service Worker acts as an invisible, client-side proxy73. It intercepts all standard fetch() requests emitted by the frontend, multiplexes the HTTP payload into a WebTransport bidirectional stream, and transmits the raw bytes to the Rust backend25. The desktop backend processes the request, streams the HTTP response back over WebTransport, and the Service Worker reconstructs the standard HTTP response object before handing it back to the browser's main thread73. This proxy pipeline completely encapsulates the local traffic within a secure, HTTP/3 QUIC tunnel, entirely evading mixed content termination while maintaining compatibility with standard web development practices25.

Security and Cryptography

In a trustless, pure P2P environment operating without central authorities, end-to-end encryption and cryptographic peer authentication are paramount. The architecture ensures that every transport protocol guarantees strict confidentiality, integrity, and authenticity1. Regardless of the underlying transport layer—whether it is a WebRTC data channel, a WebTransport QUIC stream, or native TCP—the connection is immediately upgraded utilizing the Noise protocol framework16. Specifically, the implementation employs the Noise XX handshake pattern8. During the connection establishment phase, peers exchange ephemeral X25519 public keys to perform an Elliptic-Curve Diffie-Hellman (ECDH) key agreement65. This agreement derives the symmetric keys utilized by the ChaCha20-Poly1305 authenticated encryption cipher19. During the handshake, peers cryptographically prove ownership of the private key corresponding to their advertised network Peer ID8. In the context of WebRTC, the implementation utilizes a Noise Prologue mechanism, concatenating the TLS fingerprints of both the initiator and the responder into the cryptographic state before the handshake begins, mathematically binding the identity verification to the specific transport session and effectively eliminating Man-In-The-Middle (MITM) attacks8. Within the Rust desktop node, key management prioritizes strict memory safety. All cryptographic keys and sensitive buffers implement the Zeroize trait provided by the RustCrypto ecosystem19. When a connection terminates, or an ephemeral key falls out of scope, the ZeroizeOnDrop mechanism automatically and explicitly overwrites the memory buffer with zeroes19. This guarantees that extracted memory dumps, core files, or sophisticated side-channel attacks cannot yield historic cryptographic material, preserving the forward secrecy of the P2P network19.

Synthesis and Conclusion

Designing an architecture that fuses desktop and web applications into a seamless, pure peer-to-peer network requires deliberately discarding the conveniences of centralized infrastructure. By leveraging the Tauri framework and rust-libp2p on the desktop, the system gains raw socket control, UPnP automated port forwarding, and highly efficient execution unburdened by the extreme memory overhead of Chromium-based wrappers. In the browser, utilizing js-libp2p alongside WebTransport, WebRTC-Direct, and manual SDP signaling provides robust connectivity despite aggressive Local Network Access (LNA) permissions and mixed content constraints. The resulting topology relies on mDNS for frictionless local discovery, the Kademlia DHT for wide-area routing organically bootstrapped by human-mediated peer interaction, and manual signaling as the ultimate, uncompromisable fallback. Service Workers and serverCertificateHashes bridge the security gap between modern browser sandboxes and local native backends. Ultimately, this paradigm demonstrates that scalable, secure, and entirely autonomous distributed systems are both mathematically and practically achievable without the intermediation, surveillance, or failure points of third-party authorities.

Works cited

1. A Survey of Peer-to-Peer Content Distribution Technologies \- Diomidis Spinellis home page, https://www.spinellis.gr/pubs/jrnl/2004-ACMCS-p2p/html/AS04.html
2. What Is a Peer-to-Peer Network? \- Coursera, https://www.coursera.org/articles/peer-to-peer
3. Interoperability of Peer-To-Peer File Sharing Protocols \- ACM SIGecom, https://www.sigecom.org/exchanges/volume\_3/3.3-Lui.pdf
4. Getting started with peer connections \- WebRTC, https://webrtc.org/getting-started/peer-connections
5. New WebRTC transport? \- Research and paper discussions \- libp2p, https://discuss.libp2p.io/t/new-webrtc-transport/392
6. WebRTC \- libp2p, https://libp2p.io/docs/webrtc/
7. webtransport/explainer.md at main \- GitHub, https://github.com/w3c/webtransport/blob/main/explainer.md
8. webrtc-direct.md \- libp2p/specs \- GitHub, https://github.com/libp2p/specs/blob/master/webrtc/webrtc-direct.md
9. New permission prompt for Local Network Access | Blog \- Chrome for Developers, https://developer.chrome.com/blog/local-network-access
10. Tauri Architecture, https://v2.tauri.app/concept/architecture/
11. Desktop Apps from Web: Tauri vs Electron vs Deno 2026 \- Digital Applied, https://www.digitalapplied.com/blog/desktop-apps-web-stack-tauri-electron-deno-wails-2026
12. Tauri vs. Electron: The Ultimate Desktop Framework Comparison \- Peerlist, https://peerlist.io/jagss/articles/tauri-vs-electron-a-deep-technical-comparison
13. Electron vs. Tauri: Building desktop apps with web technologies \- codecentric AG, https://www.codecentric.de/en/knowledge-hub/blog/electron-tauri-building-desktop-apps-web-technologies
14. Beyond Electron: Attacking Alternative Desktop Application Frameworks \- Bishop Fox, https://bishopfox.com/blog/beyond-electron-attacking-alternative-desktop-application-frameworks
15. libp2p \- A modular network stack | libp2p, https://libp2p.io/
16. libp2p \- Rust, https://libp2p.github.io/rust-libp2p/
17. The Rust Implementation of the libp2p networking stack. \- GitHub, https://github.com/libp2p/rust-libp2p
18. libp2p::swarm \- Rust \- Docs.rs, https://docs.rs/libp2p/latest/libp2p/swarm/index.html
19. Built a P2P encrypted messaging app with Rust \+ Tauri \[Open Source\] \- Reddit, https://www.reddit.com/r/cryptography/comments/1p1rvkj/built\_a\_p2p\_encrypted\_messaging\_app\_with\_rust/
20. Built a P2P encrypted messaging app with Rust \+ Tauri \[Open Source\] \- Reddit, https://www.reddit.com/r/rust/comments/1p1rawe/built\_a\_p2p\_encrypted\_messaging\_app\_with\_rust/
21. Enhancing Flutter Desktop with Tauri: A Practical Rust-Based IPC Architecture, https://reddwarf03.medium.com/enhancing-flutter-desktop-with-tauri-a-practical-rust-based-ipc-architecture-e71a8d11b04d
22. IPFS on the Web in 2024: Update From Interplanetary Shipyard, https://ipshipyard.com/blog/2024-shipyard-improving-ipfs-on-the-web/
23. Browser Node Connectivity \- libp2p, https://libp2p.io/docs/browser-connectivity/
24. WebTransport: Browser Support, Features, Use Cases | TestMu AI (Formerly LambdaTest), https://www.testmuai.com/learning-hub/webtransport-browser-support/
25. WebTransport API \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/API/WebTransport\_API
26. WebTransport \- W3C, https://www.w3.org/TR/webtransport/
27. libp2p Connectivity, https://libp2p-microgen.vercel.app/
28. Js-libp2p-webtransport \- Implementers and Contributors, https://discuss.libp2p.io/t/js-libp2p-webtransport/1253
29. Why WebTransport cannot connect to my server? \- Stack Overflow, https://stackoverflow.com/questions/79699241/why-webtransport-cannot-connect-to-my-server
30. Got "Opening Handshake Failed" when trying to run webtransport samples locally, https://stackoverflow.com/questions/77447254/got-opening-handshake-failed-when-trying-to-run-webtransport-samples-locally
31. Do I have to get a valid SSL certificate to make WebTranport server examples work?, https://stackoverflow.com/questions/75979276/do-i-have-to-get-a-valid-ssl-certificate-to-make-webtranport-server-examples-wor
32. Connect two peers with WebTransport \- Deno Docs, https://docs.deno.com/examples/web\_transport/
33. Announcing AutoTLS: Bridging the Gap Between libp2p and the Web, https://libp2p.io/blog/autotls/
34. WebRTC \- Open Web Experiment to Global Real-Time Communications, https://www.santanu.net/webrtc-realtime-communication-browser-evolution-and-standards/
35. WebRTC: Real-Time Communication in Browsers \- W3C, https://www.w3.org/TR/webrtc/
36. WebRTC Signaling Server: How It Works, Build One (Node.js), or Skip It \- Medium, https://medium.com/@jamesbordane57/webrtc-signaling-server-how-it-works-build-one-node-js-or-skip-it-890e244d90ae
37. js-libp2p/packages/transport-webrtc/README.md at main \- GitHub, https://github.com/libp2p/js-libp2p/blob/main/packages/transport-webrtc/README.md
38. lesmana/webrtc-without-signaling-server: webrtc without signaling server. a stun server is still used if connecting over the internet. \- GitHub, https://github.com/lesmana/webrtc-without-signaling-server
39. Building a Minimal WebRTC Peer Without a Signaling Server (Using Only Manual SDP Exchange) \- DEV Community, https://dev.to/hexshift/building-a-minimal-webrtc-peer-without-a-signaling-server-using-only-manual-sdp-exchange-mck
40. Using WebRTC data channels \- Web APIs | MDN, https://developer.mozilla.org/en-US/docs/Web/API/WebRTC\_API/Using\_data\_channels
41. angel-boschdom/p2p-react-game: David vs Goliath fully P2P React Game \- GitHub, https://github.com/angel-boschdom/p2p-react-game
42. A complete example for a WebRTC datachannel with manual signaling \- Stack Overflow, https://stackoverflow.com/questions/54980799/a-complete-example-for-a-webrtc-datachannel-with-manual-signaling
43. Simple WebRTC streaming with manual signaling (no signaling server) \- GitHub, https://github.com/david-1711/webrtc-manual-sdp-signaling
44. mDNS Discovery \- Download and install on Windows \- Microsoft Store, https://apps.microsoft.com/detail/9n074hxzcmtl
45. How to Enable and Use mDNS on Any System \- Medium, https://medium.com/@haridasmahato12/how-to-enable-and-use-mdns-on-any-system-c87fede76de9
46. P2P Peer Discovery \- Jordan Santell, https://jsantell.com/p2p-peer-discovery/
47. mDNS \- BlogGeek.me, https://bloggeek.me/webrtcglossary/mdns/
48. WebRTC Is the Silent IP Leak Living in Your Browser | by KeyboardSamurai | Medium, https://medium.com/@keyboardsamurai007/webrtc-is-the-silent-ip-leak-living-in-your-browser-cb72c46641cb
49. WebRTC IP Leaks: Should you still be worried? \- GetStream.io, https://getstream.io/blog/webrtc-ip-leaks/
50. PSA: Private IP addresses exposed by WebRTC changing to mDNS hostnames, https://groups.google.com/g/discuss-webrtc/c/6stQXi72BEU
51. mDNS access for WebRTC · Issue \#22 · WICG/local-network-access \- GitHub, https://github.com/WICG/local-network-access/issues/22
52. The DHT \- libp2p, https://libp2p.io/docs/dht/
53. libp2p-pubsub Peer Discovery with Kademlia DHT | by (λx.x)eranga | Effectz.AI | Medium, https://medium.com/rahasak/libp2p-pubsub-peer-discovery-with-kademlia-dht-c8b131550ac7
54. What is Discovery & Routing \- libp2p, https://libp2p.io/docs/discovery-routing-overview/
55. libp2p/js-libp2p-amino-dht-bootstrapper: A CLI for starting an Amino DHT bootstrapper \- GitHub, https://github.com/libp2p/js-libp2p-amino-dht-bootstrapper
56. Bootstrap libp2p DHT using my own node: failed to find any peer in table \#645 \- GitHub, https://github.com/libp2p/go-libp2p-kad-dht/issues/645
57. Create own DHT bootstrap node \- Users and Developers \- libp2p, https://discuss.libp2p.io/t/create-own-dht-bootstrap-node/1076
58. Large-Scale Measurement of NAT Traversal for the Decentralized Web: A Case Study of DCUtR in IPFS \- arXiv, https://arxiv.org/html/2604.12484v1
59. What are NATs \- libp2p, https://libp2p.io/docs/nat-overview/
60. Announcing the release of js-libp2p v1.0.0, https://libp2p.io/releases/2023-12-12-js-libp2p/
61. DCUtR \- libp2p, https://libp2p.io/docs/dcutr/
62. Hole Punching \- libp2p, https://libp2p.io/docs/hole-punching/
63. libp2p::tutorials::hole\_punching \- Rust \- Docs.rs, https://docs.rs/libp2p/latest/libp2p/tutorials/hole\_punching/index.html
64. What's the state of dcutr? · libp2p rust-libp2p · Discussion \#5910 \- GitHub, https://github.com/libp2p/rust-libp2p/discussions/5910
65. swift-libp2p \- Swift Package Registry, https://swiftpackageregistry.com/1amageek/swift-libp2p
66. feat: automate port-forwarding e.g. via UPnP · Issue \#3903 · libp2p/rust-libp2p \- GitHub, https://github.com/libp2p/rust-libp2p/issues/3903
67. Adapting your website for new Local Network Access restrictions in Microsoft Edge, https://learn.microsoft.com/en-us/deployedge/ms-edge-local-network-access
68. Chrome asks for permission and wants to look for and connect to any device on your local network \- ServiceNow Support, https://support.servicenow.com/kb?id=kb\_article\_view\&sysparm\_article=KB2634180
69. Local network access restrictions \- Chrome Platform Status, https://chromestatus.com/feature/5152728072060928
70. Local Network Access \- GitHub Pages, https://wicg.github.io/local-network-access/
71. Mixed content \- Security \- MDN Web Docs \- Mozilla, https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Mixed\_content
72. Private Network Access update: Introducing a deprecation trial \- Chrome for Developers, https://developer.chrome.com/blog/private-network-access-update
73. Using Service Workers \- Web APIs | MDN, https://developer.mozilla.org/en-US/docs/Web/API/Service\_Worker\_API/Using\_Service\_Workers
74. Cross-origin Service Workers \- Experimenting with Foreign Fetch | Blog, https://developer.chrome.com/blog/foreign-fetch
75. Running fetch in a web worker \- Google Developer Experts \- Medium, https://medium.com/google-developer-experts/running-fetch-in-a-web-worker-700dc33ac854