ZeroQ Protocol: Pub/Sub and Work Queues over a WebRTC DataChannel Mesh

1. Gossip-Based Peer Discovery

A signaling server introduces peers; after that, peers introduce each other. When a DataChannel opens, each side sends a __gossip__ frame containing up to 10 known peer ids, and the receiver dials any it has not seen. That is the whole protocol.

• What is gossiped: peer ids only.
• What is not gossiped: topic metadata, subscription sets or consumer-group membership. There are no bloom filters and no topic-level routing — every message is broadcast to every connected peer, which filters locally by topic.
• Topology: each peer dials every peer it learns about, so the mesh converges to a full mesh with O(N²) connections. There is no multi-hop forwarding, so a peer only receives messages from peers it is directly connected to.

2. Client-Side Dead Letters

If a consumer calls nack(), retryCount is incremented and the message is re-broadcast, for up to three attempts. After that it is left in the local IndexedDB store, and PersistenceLayer.getDeadLetterQueue() returns the messages with retryCount >= 3.

Two caveats an earlier version of this post got wrong: dead letters live in the same object store (messages) as everything else — the “DLQ” is a filter over that store, not a separate store or topic; and PersistenceLayer is internal with no accessor on ZeroQ, so dead letters are currently only reachable by opening the zeroq-db database directly.

Note also that a consumer which simply dies without calling ack() or nack() triggers no retry at all: there is no visibility timeout and no redelivery timer.

3. Backpressure Handling

With no central broker to throttle producers, a DataChannel can be overwhelmed. ZeroQ checks dc.bufferedAmount before every send, against a hardcoded 65,536-byte (64 KiB) threshold.

Be precise about what happens above that threshold: the message is discarded. ZeroQ does not pause the producer, does not buffer to memory or IndexedDB, and does not wait for bufferedamountlow — that event is not used anywhere in the codebase. publish() still resolves successfully. The only signal is a message_dropped event on the mesh, which callers must subscribe to if they care. The same applies to a payload larger than the DataChannel's sctp.maxMessageSize (64 KiB minimum per spec, 256 KiB in Chrome), because there is no chunking.

4. Duplicate Suppression

Because a full mesh delivers the same broadcast along multiple edges, receivers need to suppress duplicates. ZeroQ keeps a Set of the last 10,000 id:retryCount strings, evicted first-in-first-out, and drops any frame whose key it has already seen.

This is duplicate suppression, not exactly-once delivery. The key is the sender-supplied UUID rather than a content hash, so a malicious peer can suppress a message by claiming its id first. Eviction is FIFO, not LRU, over a fixed 10,000-entry window, so beyond that a genuine duplicate can be redelivered. And there are no Lamport timestamps or logical clocks: Message.seq exists in the type but is always 0 and is never read. Ordering comes solely from the ordered delivery guarantee of a single DataChannel.

Where ZeroQ Fits

Cost figures for managed Kafka vary by an order of magnitude with retention, throughput and vendor; this post no longer quotes a single monthly number, because the earlier “$400/month” figure was not sourced. Compare your own bill.

import { ZeroQ } from 'https://cdn.jsdelivr.net/gh/itsoumya-d/zeroq@main/dist/index.mjs';

// ---- Peer A: the worker ----
const worker = new ZeroQ({ discoveryUrl: 'wss://your-signaling-server/ws' });

await worker.consume('agent_events', (msg, ack, nack) => {
  try {
    console.log('Processing AI task:', msg.payload);
    processTask(msg.payload);
    ack();
  } catch (err) {
    nack();   // up to 3 attempts, then left as a dead letter
  }
});

// ---- Peer B: the producer, in a separate tab or process ----
const producer = new ZeroQ({ discoveryUrl: 'wss://your-signaling-server/ws' });

await producer.createQueue('agent_events');
await producer.enqueue('agent_events', {
  task_id: '101',
  payload: 'Analyze local repository'
});