Peerix – Blog

Peerix v0.5 Released

Thu, 25 Jun 2026 00:00:00 +0000

Peerix v0.5 is now available. This is a significant update that reimagines how data travels between peers — introducing streaming transfers with progress tracking, abortable transmissions, and optional metadata — while simplifying the underlying channel architecture.

Highlights: Streaming Data Transfers

v0.5 fundamentally changes how send works and how you receive data over channels. Instead of a fire-and-forget API, send now returns an async iterable that doubles as a promise — letting you track transfer progress or simply await completion.

ReadableStream for incoming and outgoing data

The send method now supports streaming any data through a single channel. Large payloads are automatically chunked and buffered on the wire, so you can transmit files and binary blobs without worrying about maximum message size limits.

On the receiving side, the channel:message event fires as soon as the first chunk arrives. The data payload is a ReadableStream/Promise that you can iterate over to receive chunks incrementally — or consume as a promise to get the fully assembled message when you don’t need progress tracking.

Progress tracking

The transfer object returned by send is an async iterator. By looping over it, you can observe how much data has been sent at each step:

const file = new File([new Uint8Array(1024 * 1024)], "example.dat");
const transfer = peer.send(file, {
 label: "chat", // channel label
 info: { name: file.name, size: file.size }, // metadata
 signal: AbortSignal.timeout(10000), // abort signal
});

// track the progress of the transfer
for await (const progress of transfer) {
 const { id, label, current, total } = progress;
 const percent = Math.round((current / total) * 100);
 console.log(`[${id}:${label}] Sending... ${percent}%`);
}

Receiving the file and tracking progress on the other end:

peer.on("channel:message", async (e) => {
 const { remote, label, data, info } = e;
 let current = 0;
 const chunks = [];

 // read data by chunks
 for await (const chunk of data) {
 chunks.push(chunk);
 current += chunk.length;
 const percent = Math.round((current / info.size) * 100);
 console.log(`[${remote.id}:${label}] Receiving... ${percent}%`);
 }

 const file = new File(chunks, info.name);
 console.log("Received:", file);

 // cancel the stream if needed
 // data.cancel();
});

Abortable transfers

You can cancel a transmission at any time using AbortSignal. The example above uses AbortSignal.timeout(10000) to auto-cancel after 10 seconds, but you can also create an AbortController and call .abort() manually whenever your application logic dictates.

Cancellation works on the receiver side as well. Since incoming data is a ReadableStream, you can call data.cancel() at any point during iteration to stop receiving further chunks.

Optional Metadata

The new info option on send lets you attach arbitrary metadata alongside your data. This metadata is delivered with every channel:message event, so the receiving peer can inspect it without waiting for the full payload. This is useful for describing the payload — file names, sizes, types, or any custom information the receiver needs to process the message correctly.

Breaking changes

Data is now sent through a single data channel per peer. If you omit the label option, messages are routed to the default channel instead of all existing channels.
Incoming data is now either a ReadableStream or a Promise. Read the stream to track receiving progress or use the promise to get a specific data type when the full message is received.

Peer Serialization

A new toJSON method was added to both local and remote peers. Use it to serialize peer identity information for logging, debugging, or state persistence:

console.log(peer.toJSON()); // { id: "...", room: "...", ... }

Testing Improvements

Unit tests were added for internal utilities and several signaling drivers. This improves confidence in core functionality and makes future refactoring safer.

Upgrade Notes

When upgrading to v0.5, review the following breaking changes:

send API: The return value is now an async iterable transfer object instead of a plain Promise. If you previously awaited send directly, it will still work (the transfer resolves when delivery completes), but you can now also iterate over it for progress updates.
Incoming data shape: The data in channel:message events is now always a ReadableStream/Promise. To receive the full message, await it: const payload = await event.data. To track receiving progress, iterate with for await (const chunk of event.data).
Single channel: Data is sent over one data channel instead of multiple. The default label is used when no label is provided.

Conclusion

v0.5 transforms data channel messaging into a first-class streaming experience with progress visibility and transfer control built in. For full details on these changes, please visit our updated resources:

📚 Documentation
📑 API Reference

Peerix v0.4 Released

Thu, 28 May 2026 00:00:00 +0000

Peerix v0.4 is now available. Peerix continues its mission of simplifying WebRTC development by abstracting the heavy lifting of signaling and connection management into a minimal, transport-agnostic API. This release focuses on expanding our signaling transport options for production environments, refining our API for a better developer experience, and optimizing performance under the hood.

Highlights: New Signaling Drivers for Production Scale

While our earlier releases focused on getting peers connected, v0.4 is about moving from local prototypes to distributed production environments. We’ve added two major signaling drivers to support industry-standard messaging infrastructure.

MQTT Driver

The MqttDriver enables signaling via the MQTT protocol and is specifically designed for MQTT over WebSockets. This allows developers to leverage robust brokers like Mosquitto for their signaling needs. It is an ideal choice for lightweight pub/sub signaling within existing messaging ecosystems.

Requires the external mqtt module.
Requires a running MQTT broker, for example, a Mosquitto server.
Documentation: MQTT Driver

Centrifuge Driver

The CentrifugeDriver integrates with the Centrifugo real-time messaging server. This driver is built for developers who need high fan-out capabilities and reliable reconnection support in high-traffic production environments.

Requires the external centrifuge module.
Requires a running Centrifugo server.
Documentation: Centrifuge Driver

SSE Driver Enhancements

The SseDriver has been updated to default to the Mercure-compatible endpoint (/.well-known/mercure), making it easier for developers using the Mercure hub to get started without additional configuration. This change simplifies setup and reduces friction for those leveraging Mercure for their signaling needs.

No external modules required.
Requires a running Mercure server or another SSE-compatible server (with a code example provided).
Documentation: SSE Driver

Improved Developer Experience: Local Testing with Docker

To lower the barrier for local development, v0.4 now includes example code snippets and configurations for running signaling backends locally using Docker. You can now quickly spin up instances of NATS, Mercure, Mosquitto, and Centrifugo with standardized setups. This ensures that your local testing environment mirrors your production infrastructure as closely as possible.

API Refinements

In our ongoing effort to create a more intuitive and consistent API, we have made some key changes to method naming conventions. The term publish has been reserved exclusively for the Signaling Layer to align with standard messaging terminology. For the Application Layer, we have introduced share and unshare to better describe how media and data streams are managed. This change helps avoid confusion between signaling events and application-level actions.

Migration Mapping

Old Method	New Method	Layer
`Driver.dispatch`	`Driver.publish`	Driver
`Peer.publish`	`Peer.share`	Peer (media streams)
`Peer.unpublish`	`Peer.unshare`	Peer (media streams)

Performance and Technical Optimizations

As a core maintainer, my focus is often on the “under-the-hood” efficiencies that keep your apps performant. This release includes several technical wins for reducing message overhead:

Protobuf-like Format: We have transitioned from a custom binary format to a Protobuf-like format for signaling messages. This transition allows us to use an industry-standard serialization method and reuse it across several internal components, reducing the need for custom parsing logic and minimizing message sizes.
ICE Candidate Debouncing: To minimize signaling chatter, we’ve introduced the iceCandidateDebounce option in the Peer class. It defaults to 50ms, batching candidates to reduce the frequency of messages sent during the negotiation phase.
SocketIoDriver Enhancements: We have added an ackTimeout option to the SocketIoDriver, giving you granular control over how long the client waits for server acknowledgments.
Simplified Event Naming: Most drivers now use peer or room identifiers directly as event names. By avoiding string concatenation, we’ve shortened name lengths to reduce signaling overhead.

Upgrade and Migration Notes

If you are moving from v0.3 to v0.4, please review these breaking changes:

Method Renaming: All application-level calls to publish and unpublish must be updated to share and unshare. This change applies to both the Peer and RemotePeer classes.
Driver Active State: The Driver class now initializes with the active accessor set to false by default. Ensure your logic accounts for the driver state during startup.
Prefix Handling & Separators: Some drivers now use empty prefixes by default and no longer automatically include separators. If you require a separator, it must be part of your prefix string.
- Example: If your prefix is peerix and the event is event, it will result in peerixevent. To get peerix:event, you must define the prefix as peerix:.
Namespace Hashing Compatibility: When namespaceHashing is disabled, the room property is now automatically escaped. This prevents character compatibility issues with certain signaling backends that do not support specific symbols or spaces.

Conclusion

This release brings us closer to a truly plug-and-play WebRTC experience that scales. For full details on these changes, please visit our updated resources:

📚 Documentation
📑 API Reference

Peerix v0.3 Released

Sat, 23 May 2026 00:00:00 +0000

Peerix v0.3 is now available. This release introduces a new SSE signaling driver, strengthens secure defaults, improves signaling efficiency, and updates compatibility and licensing for wider adoption.

Highlights

New `SseDriver` for signaling

Peerix now includes SseDriver for signaling over Server-Sent Events (SSE).

The SSE driver is a browser-friendly option for production signaling: incoming updates are delivered through a single SSE stream, while outbound signaling messages are sent via standard HTTP POST requests.

import { Peer, SseDriver } from "peerix";

const driver = new SseDriver({
 url: "http://localhost:8080/api/sse",
});

const peer = new Peer({ driver });
await peer.join({ room: "my-room" });

See the SSE Driver docs for full usage and a server example.

Lower signaling overhead with ICE candidate debouncing

Peerix now debounces ICE candidate signaling. This reduces message bursts during negotiation and lowers transport load, especially in rooms where multiple peers join around the same time.

More secure defaults

v0.3 improves signaling security and identity defaults:

Signaling encryption now uses derived keys instead of manually supplied secret keys.
Signaling encryption is enabled by default.
Peer IDs now use compressed public keys.
signalingHashing has been renamed to namespaceHashing for clarity and consistency.

These updates make secure setups easier out of the box while preserving flexibility for advanced deployments.

Modern runtime baseline

This release raises the minimum build target to ES2020 to support modern JavaScript features such as BigInt.

Updated licensing

Peerix is now licensed under Apache-2.0, replacing GPL-3.0. This makes adoption easier for both open-source and commercial projects.

Upgrade notes

When upgrading to v0.3, review the following:

If you used manually managed signaling secret keys, migrate to the new derived-key flow.
If you configured signalingHashing, rename it to namespaceHashing.
If your environment depends on older JavaScript targets, ensure your toolchain supports ES2020.
If you need cross-browser/server signaling without WebSockets, consider moving to SseDriver.

Thank you

Thanks to everyone testing Peerix and sharing feedback. Your input continues to improve reliability, performance, and developer experience.

More improvements are coming soon across core functionality, drivers, examples, and documentation.

Peerix v0.2 Released

Wed, 13 May 2026 00:00:00 +0000

Peerix v0.2 is now available. This release expands signaling options, simplifies interoperability, and improves default privacy behavior in production environments.

Highlights

New signaling drivers

Peerix now includes two new built-in signaling drivers:

SocketIoDriver for applications using Socket.IO infrastructure.
SupabaseDriver for projects built on Supabase Realtime.

These drivers make it easier to integrate Peerix into existing stacks without adding custom signaling glue code.

In v0.2, both drivers follow the same setup pattern used by other Peerix signaling drivers: create your transport client, pass it to the driver, then initialize Peer with that driver. This makes it simple to switch transports without changing application-level peer logic.

Socket.IO driver

Socket.IO is a popular real-time communication library that provides a WebSocket-like API with fallbacks for older browsers. The SocketIoDriver allows you to use Socket.IO as the signaling transport for Peerix, enabling seamless integration with existing Socket.IO servers.

import { Peer, SocketIoDriver } from "peerix";
import { io } from "socket.io-client";

const socket = io("https://your-socket-server");

const driver = new SocketIoDriver({ socket });
const peer = new Peer({ driver });
await peer.join({ room: "my-room" });

Note that you will need a compatible server-side Socket.IO implementation to use this driver. See the Socket.IO Driver docs for a code example.

Supabase driver

Supabase Realtime is a serverless real-time database and messaging service built on PostgreSQL. The SupabaseDriver allows you to use Supabase Realtime as the signaling transport for Peerix, making it easy to integrate with applications already using Supabase.

import { Peer, SupabaseDriver } from "peerix";
import { createClient } from "@supabase/supabase-js";

const supabase = createClient(
 "https://your-project.supabase.co",
 "public-anon-key",
);

const driver = new SupabaseDriver({ supabase });
const peer = new Peer({ driver });
await peer.join({ room: "my-room" });

Note that you will need to set up a Supabase Realtime subscription on the server side to use this driver.

NATS driver update

The NatsDriver now uses nats-core instead of nats.ws because of deprecation. This change improves consistency and aligns Peerix with the current direction of the NATS JavaScript ecosystem.

NATS (`nats-core`) example

import { Peer, NatsDriver } from "peerix";
import { wsconnect } from "@nats-io/nats-core";

const nc = await wsconnect({ servers: ["wss://demo.nats.io:8443"] });

const driver = new NatsDriver({ nc });
const peer = new Peer({ driver });
await peer.join({ room: "my-room" });

See NATS Driver docs for full details and migration guidance.

Driver cleanup with `destroy`

When your app unmounts a page, leaves a workspace, or otherwise tears down realtime state, explicitly destroy the driver to avoid dangling subscriptions or listeners:

await peer.leave();
driver.destroy();

Serialization-friendly driver interface

The driver interface now favors plain arrays over typed arrays. This improves serialization across environments and transports, especially when messages cross boundaries where typed arrays can be awkward or lossy.

Namespace hashing enabled by default

Namespace hashing is now enabled by default. This delivers two practical benefits:

Better privacy by avoiding direct exposure of raw namespace values.
Better compatibility by preventing issues with unsupported namespace characters.

Upgrade notes

When moving to v0.2, review the following:

If you rely on readable namespace values in infrastructure logs or tooling, account for hashing now being enabled by default.
If your custom drivers depend on typed array assumptions, update them to work with plain arrays.
If you use NATS signaling, verify your setup against the nats-core dependency.

Thank you

Thanks to everyone trying Peerix early and sharing feedback. Your input helps shape the roadmap and improve real-world reliability.

More updates are coming soon, including continued work on drivers and developer experience.

Welcome to Peerix

Wed, 06 May 2026 00:00:00 +0000

My name is Anton Skshidlevsky (aka meefik), and I’m a software engineer with over twenty years of experience in software development and over ten years of experience in building WebRTC web applications. Today, I’m excited to announce the first release of Peerix, a JavaScript/TypeScript open-source library designed to simplify building WebRTC peer-to-peer applications. After months of development and testing, Peerix is now available for developers to use and contribute to.

Background

Over ten years ago, I started building peer-to-peer web applications using WebRTC. It was an exciting but often frustrating journey, as I had to repeatedly solve the same problems around signaling, connection management, and media/data exchange across browsers and devices. However, from time to time, things went wrong. I wanted a simpler way to build these apps without reinventing the wheel every time, but existing libraries didn’t quite fit the bill.

That’s exactly why I created Peerix, which brings all of this expertise together. It abstracts away the complexities of WebRTC and provides a clean, minimal API for building peer-to-peer apps quickly and reliably. Whether you’re building a simple chat app, a video conferencing service, a collaborative tool, or a more sophisticated multi-stream, multi-channel experience, Peerix aims to make it easier to get up and running without getting bogged down in the details of signaling and connection management. I’m excited to share it with the community and see what you build with it!

Currently, Peerix implements core functionality around WebRTC and peer-to-peer connections. Even now, it supports a wide range of use cases, from simple data sharing to multi-stream media applications. The core API is designed to be minimal and intuitive, with sensible defaults for signaling and connection management. Just a few lines of code are needed to get started. In the future, we plan to add more features and add-ons, as well as additional signaling drivers to further enhance the capabilities of Peerix.

Why peer-to-peer

Peer-to-peer communication has many advantages, including lower latency, better privacy, and reduced server costs. By connecting peers directly, you can build applications that are more responsive and scalable, without relying on centralized servers for media processing or routing. Peerix is designed to make it easy to build these kinds of applications, allowing you to focus on building your application’s features and user experience, rather than dealing with the complexities of WebRTC and signaling.

I admit that sometimes a server-side component is necessary, especially for media processing or routing in large-scale applications. However, for many use cases, a pure peer-to-peer architecture can provide significant benefits. With the correct configuration, each peer can connect to dozens of other peers without hitting performance issues, and the server can be reserved for signaling and coordination rather than media processing. You can have thousands of rooms with dozens of peers each, all without needing a single SFU or MCU. You can even do some media processing directly in the browser with add-ons, such as recording or mixing, without needing to route media through a server. So peer-to-peer is powerful and can be the right choice for many applications, and Peerix is here to make it easier to build those applications.

Why Peerix

WebRTC is powerful but complex. Most apps re-implement the same boilerplate: signaling channels, ICE configuration, connection lifecycle, and multi-track negotiation. That complexity slows prototyping, increases bugs, and raises the barrier for developers who just want to share media or data peer-to-peer.

Interestingly, there are not many libraries that offer a clean, well-documented abstraction over WebRTC, including modern concepts like multi-track, data channels, and pluggable signaling. Many libraries focus on specific use cases (e.g., video calls) or require server-side components (e.g., SFUs). Peerix fills the gap for a flexible, transport-agnostic client-side library that abstracts away the common complexities of WebRTC while still allowing you to build a wide range of peer-to-peer applications.

The problem it solves

Typical WebRTC apps face several challenges:

Signaling vendor lock-in: many libraries tie you to a specific signaling method (e.g., WebSockets), making it hard to switch or support multiple transports.
Hard-to-manage negotiations of multiple media streams and data channels across multiple peers in mesh and room-based topologies.
STUN/TURN and reconnection complexities that leak into app code.
Extra boilerplate for additional functionality like E2E encryption, recording, storage, state synchronization, etc.

Peerix centralizes these concerns in a single Peer class and a pluggable driver model for signaling, so the same API works locally (MemoryDriver), between tabs (BroadcastChannelDriver), or across the internet (NATS driver or custom drivers). It can be extended with add-ons without modifying your core app logic.

Core idea

Peerix provides a simple yet powerful abstraction of WebRTC with transport-agnostic architecture and extends its capabilities with add-ons, all while keeping the API minimal.

At the heart of Peerix is a simple principle: a room-based topology involves a single connection per peer and multiplexes media tracks and data channels over that connection using transport-agnostic drivers. This reduces signaling chatter and avoids creating multiple redundant peer connections for each stream or channel. The pluggable driver model abstracts away the signaling transport, allowing you to choose or implement the one that best fits your use case without changing your app code. The library exposes clear lifecycle events so that apps can react declaratively.

Advantages

Let’s summarize the key advantages of Peerix:

Minimal API surface: quick to learn and integrate.
Pluggable signaling drivers: swap BroadcastChannel, NATS, or your own driver over WebSockets.
Single-connection multiplexing: efficient resource use and simpler negotiation.
Flexible: share multiple streams, open multiple data channels, and attach add-ons to extend functionality.

Who is it for

Peerix is for developers building real-time apps such as chat, conferencing, file sharing, collaborative tools, and games who want to avoid reimplementing signaling and connection plumbing, and who need a flexible, extensible foundation for peer-to-peer communication in the browser. If you want to build peer-to-peer web apps without reinventing the wheel, Peerix is for you.

When not to use it

If you need server-side media processing or routing, Peerix is not an SFU (Selective Forwarding Unit) or MCU (Multipoint Control Unit).

License

Peerix is licensed under the Apache License, Version 2.0. This means you can use, modify, and distribute Peerix in your open-source or commercial projects without any restrictions. See the LICENSE file for details.

Future plans

In the future, we plan to expand Peerix with additional features and signaling drivers. Some of the upcoming features include:

Additional signaling drivers: SSE driver, Socket.IO driver, Supabase driver, and more.
Recording add-on: easily record media streams or data channels.
State synchronization add-on: keep application state in sync across peers.
Video/audio mixing add-on: mix multiple media streams together for composite outputs.

Get started

A code snippet to illustrate how simple it is to get started with Peerix:

import { Peer, BroadcastChannelDriver } from "peerix";

// create a signaling driver
const driver = new BroadcastChannelDriver();

// create a Peer instance
const peer = new Peer({ driver });

// listen for events
peer.on("channel:open", ({ remote, label }) => remote.send("hello", { label }));
peer.on("channel:message", async ({ data }) => console.log("msg", await data));

// open a data channel
peer.open({ label: "default" });

// join a room
peer.join({ room: "room-id" });

See the Getting Started guide to install Peerix and try it in your browser. Contributions, issues, and driver add-ons are welcome — Peerix aims to be a practical, community-driven toolkit for peer-to-peer web apps.

Welcome aboard — now let’s make peer-to-peer apps easier.

Get Started

Read the documentation

API Reference

Explore the API reference

Conclusion

Eventually, we hope Peerix will become a go-to library for developers building peer-to-peer web applications, providing a solid foundation that abstracts away the complexities of WebRTC while still allowing for flexibility and extensibility. We look forward to seeing what the community builds with Peerix and welcome contributions to help make it even better.

Peerix – Blog

Peerix v0.5 Released

Highlights: Streaming Data Transfers

ReadableStream for incoming and outgoing data

Progress tracking

Abortable transfers

Optional Metadata

Breaking changes

Peer Serialization

Testing Improvements

Upgrade Notes

Conclusion

Peerix v0.4 Released

Highlights: New Signaling Drivers for Production Scale

MQTT Driver

Centrifuge Driver

SSE Driver Enhancements

Improved Developer Experience: Local Testing with Docker

API Refinements

Performance and Technical Optimizations

Upgrade and Migration Notes

Conclusion

Peerix v0.3 Released

Highlights

New SseDriver for signaling

Lower signaling overhead with ICE candidate debouncing

More secure defaults

Modern runtime baseline

Updated licensing

Upgrade notes

Thank you

Peerix v0.2 Released

Highlights

New signaling drivers

Socket.IO driver

Supabase driver

NATS driver update

NATS (nats-core) example

Driver cleanup with destroy

Serialization-friendly driver interface

Namespace hashing enabled by default

Upgrade notes

Thank you

Welcome to Peerix

Background

Why peer-to-peer

Why Peerix

The problem it solves

Core idea

Advantages

Who is it for

When not to use it

License

Future plans

Get started

Conclusion

New `SseDriver` for signaling

NATS (`nats-core`) example

Driver cleanup with `destroy`