DEV Community: Andrew

Stop Routing to IPs: How Iroh 1.0 Uses Cryptographic Keys for P2P Networking

Andrew — Mon, 22 Jun 2026 12:24:33 +0000

The Problem with IP-Based Networking

IP addresses make for inherently fragile identifiers. They change whenever a device switches from Wi-Fi to cellular, reboots, or updates its DHCP lease. In modern network environments, where devices are frequently trapped behind multiple layers of NAT or CGNAT, these shifts break existing connections. Historically, developers have relied on complex or centralized solutions like STUN, TURN, or stateful VPN overlays to manage connectivity, all of which introduce latency or maintenance overhead.

Enter Iroh 1.0: Identity Through Keys

Released in June 2026, Iroh 1.0 shifts the focus from IP addresses to cryptographic public keys. By treating the public key as the stable identifier for a node, Iroh allows the network layer to handle the routing details. This ensures that even if the underlying IP changes, the connection remains authenticated and persistent.

How Iroh Stacks Up

Connection Lifecycle: Iroh attempts a direct QUIC-based UDP hole punch first, which succeeds in roughly 90% of cases. When direct connectivity fails—often due to symmetric NAT—it falls back to a stateless relay.
Efficient Infrastructure: By leveraging QUIC with TLS 1.3, Iroh ensures end-to-end encryption. Because the relay servers are stateless and merely forward encrypted packets, they are significantly cheaper and easier to scale than stateful WebRTC TURN servers.
Standardization: Iroh adopts QUIC-NAT-Traversal (QNT), an IETF standard that integrates hole punching directly into the QUIC stack. This allows for better congestion control and cleaner connection handoffs.

Implementation

Using Iroh is straightforward across multiple languages. Here is a minimal implementation in Rust using the iroh crate:

use iroh::{Endpoint, endpoint::presets, protocol::Router};

// Accepting side
let endpoint = Endpoint::bind(presets::N0).await?;
let router = Router::builder(endpoint.clone())
    .accept(ECHO_ALPN, EchoHandler)
    .spawn();
endpoint.online().await?;
let addr = endpoint.node_addr().await?;

// Connecting side
let other = Endpoint::bind(presets::N0).await?;
let conn = other.connect(addr, ECHO_ALPN).await?;
let (mut send, mut recv) = conn.open_bi().await?;
send.write_all(b"hello iroh").await?;
send.finish()?;

Trade-offs and Use Cases

Unlike WebRTC or libp2p, Iroh prioritizes practical connectivity over extreme decentralization. It avoids the bloat of ICE/SDP and the complexity of Kademlia DHTs. While Iroh is excellent for direct peer-to-peer data, it is not a web server. If your application requires handling webhooks or providing a standard HTTPS interface for external clients, you will still need a public entry point.

For local development or demoing web-facing components of your P2P app, you can use ssh to expose a local port:

ssh -p 443 -R0:localhost:8080 free.pinggy.io

By splitting your architecture-Iroh for the P2P data plane and a tunnel for the public HTTP ingress, you get the best of both worlds: decentralization where performance matters and web standard compatibility where accessibility matters.

Reference

Iroh 1.0: Dial Keys, Not IPs

Iroh 1.0 ships a stable P2P networking library that connects devices by cryptographic key instead of IP address. QUIC under the hood, 90% hole-punch success, 200M+ endpoints/month, and now stable language bindings for Python, Node.js, Swift, and Kotlin.

pinggy.io
https://github.com/n0-computer/iroh

Self-Hosting High-Fidelity TTS: Deploying VoxCPM2 with a Public Pinggy Tunnel

Andrew — Fri, 19 Jun 2026 08:32:21 +0000

If you are tired of paying per-character fees for TTS services, you can now run OpenBMB’s VoxCPM2 locally. This 2-billion-parameter model drops traditional audio tokenization, opting instead for a diffusion autoregressive architecture that produces 48 kHz, studio-quality audio. It supports 30 languages and offers advanced features like zero-shot voice design.

The Technical Advantage

Unlike two-stage models like F5-TTS or Kokoro that encode text into discrete audio tokens before decoding, VoxCPM2 stays within the latent space of a learned audio VAE. This approach preserves nuances like breath patterns and mid-sentence emotional shifts that are usually lost during quantization.

Prerequisites

To run this efficiently, ensure your environment meets these requirements:

Python 3.10 or 3.11
CUDA 12.0+
PyTorch 2.5.0+
8 GB VRAM (bfloat16 precision)
FFmpeg installed on your path

Setup and Inference

Start by creating a virtual environment, then install the package:

python3 -m venv voxcpm-env
source voxcpm-env/bin/activate
pip install voxcpm

To test your installation and pull the model weights, run:

python -c "from voxcpm import VoxCPM2; m = VoxCPM2(); print('ready')"

Serving via OpenAI-Compatible API

VoxCPM2 supports vLLM-Omni, which exposes a /v1/audio/speech endpoint. This allows you to swap your existing OpenAI SDK base URL to point at your local GPU:

pip install "vllm==0.19.0" vllm-omni
vllm serve openbmb/VoxCPM2 --omni --port 8000

Exposing via Pinggy

Since your local port 8000 isn't public, use Pinggy to create a secure tunnel without complex firewall configuration:

ssh -p 443 -R0:localhost:8000 free.pinggy.io

This command returns a public HTTPS URL. You can even secure this endpoint with basic auth if you are sharing it with a small team:

ssh -p 443 -R0:localhost:8000 a.pinggy.io -t "b:myuser:mypassword"

Integration

Once the tunnel is active, call your local instance from any environment just as you would with a cloud provider:

from openai import OpenAI

client = OpenAI(
    base_url="https://your-pinggy-url/v1",
    api_key="not-needed"
)

response = client.audio.speech.create(
    model="openbmb/VoxCPM2",
    voice="default",
    input="Local GPU deployment is live!"
)
response.stream_to_file("output.mp3")

Reference

Self-Host Free Voice AI with VoxCPM2 and Pinggy

NPM v12 Is Changing Everything: How to Secure Your Install Pipeline Now

Andrew — Wed, 17 Jun 2026 04:23:21 +0000

The Shift in Supply Chain Security

On June 3, 2026, a sophisticated supply chain attack known as "Phantom Gyp" compromised 57 npm packages in under two hours. The exploit was simple but deadly: it bypassed standard malware scanners by hiding malicious payloads within binding.gyp files—a mechanism used for compiling native addons. Because these files trigger node-gyp during installation, the code executed automatically without ever being flagged as a traditional preinstall or postinstall script.

In response, GitHub announced a massive overhaul coming in npm v12 (expected July 2026). The era of blind trust for dependencies is ending. Here is how you can prepare.

What npm v12 Changes for You

Lifecycle Scripts Become Opt-In: preinstall, install, and postinstall scripts from your node_modules will be blocked by default. You must explicitly approve them.
Git & Remote URL Restrictions: Dependencies loaded via Git or raw tarball URLs now require specific opt-in flags (--allow-git or --allow-remote).
Native Addon Control: Any package using binding.gyp will now be treated like a script, meaning implicit native builds are no longer automatic.

Audit Your Dependencies Today

Don't wait until July to discover your build is broken. You can test your project against v12 rules right now using npm 11.16.0+.

First, upgrade your npm version:
npm install -g npm@latest

Perform a dry-run audit to see which packages currently execute scripts:
npm approve-scripts --allow-scripts-pending

The Migration Workflow

To keep your pipeline running smoothly, you need to manage an allowScripts block in your package.json. You can approve your current dependency tree with a single command:

npm approve-scripts --all

Pro-tip for CI/CD: While you might be permissive on your local machine, enforce strict security in CI. Use the --strict-allow-scripts flag in your production pipelines. This forces the build to fail if an unapproved dependency attempts to execute a script, providing an immediate circuit breaker against potential supply chain attacks.

Testing Integrations

If your app relies on webhooks, you don't need a formal staging environment to verify them after your migration. You can expose your local environment to the public internet securely using Pinggy:

ssh -p 443 -R0:localhost:3000 free.pinggy.io

This provides a temporary HTTPS URL for testing webhooks from providers like Stripe or GitHub directly against your local code.

Read more about this from Blog

DEV Community: Andrew

Stop Routing to IPs: How Iroh 1.0 Uses Cryptographic Keys for P2P Networking

The Problem with IP-Based Networking

Enter Iroh 1.0: Identity Through Keys

How Iroh Stacks Up

Implementation

Trade-offs and Use Cases

Reference

Iroh 1.0: Dial Keys, Not IPs

Self-Hosting High-Fidelity TTS: Deploying VoxCPM2 with a Public Pinggy Tunnel

The Technical Advantage

Prerequisites

Setup and Inference

Serving via OpenAI-Compatible API

Exposing via Pinggy

Integration

Reference

NPM v12 Is Changing Everything: How to Secure Your Install Pipeline Now

The Shift in Supply Chain Security

What npm v12 Changes for You

Audit Your Dependencies Today

The Migration Workflow

Testing Integrations