DENSE Protocol: Defensive Publication

February 8th, 2026

Technical disclosure for the Distributed Encoded Network Signal Exchange (DENSE) protocol - a compact binary protocol for agent-to-agent communication over social media


DENSE Protocol — Defensive Publication

Title: Distributed Encoded Network Signal Exchange (DENSE): A Compact Binary Protocol for Agent-to-Agent Communication Over Character-Constrained Public Networks

Publication Date: February 8, 2026
Author: DBH Ventures
Contact: david@dbhventures.com


Abstract

This publication discloses a method and system for enabling autonomous AI agents to communicate and coordinate over existing public social media networks (Twitter/X, Discord, Telegram, Slack) using a compact binary protocol optimized for character-constrained and potentially hostile transport environments. The protocol combines high-density Unicode encoding, forward error correction, and an enumerated action codebook to achieve complete agent coordination within single messages of approximately 280 characters.


Technical Disclosure

1. System Overview

DENSE (Distributed Encoded Network Signal Exchange) is a binary protocol that enables machine-to-machine communication by encoding structured agent coordination messages into Unicode text suitable for transmission over public social media platforms. The system addresses the unique challenges of using consumer platforms as agent infrastructure:

  • Character limitations (Twitter: 280, Discord: 2000)
  • Unicode normalization that may corrupt binary data
  • Platform-specific character weighting
  • Transmission errors and truncation

2. Message Structure

Each DENSE message comprises four components transmitted as a single Unicode string:

┌──────────┬───────────┬───────────┬────────────┐
│  HEADER  │ IDENTITY  │  PAYLOAD  │ ECC BLOCK  │
│ 8 bytes  │ variable  │ variable  │ variable   │
└──────────┴───────────┴───────────┴────────────┘

2.1 Header Format (8 bytes, fixed)

Byte(s)FieldDescription
0Version + Flags4-bit version, 4-bit flags (ECC, compression, encryption, multi-part)
1-2Action Code16-bit enumerated action identifier (65,536 possible actions)
3-4Payload Length16-bit unsigned integer
5ECC LevelError correction strength (0x00=none, 0x10=7%, 0x20=15%, 0x30=30%)
6-7SequenceFragment ID for multi-part messages

2.2 Identity Block

The identity block uses compressed Decentralized Identifiers (DIDs):

  • 1-byte identity type (did:wba, did:key, did:web, compact reference, anonymous)
  • Variable-length sender identifier with 2-byte length prefix
  • Variable-length recipient identifier with 2-byte length prefix
  • 2-byte capability flags (16 agent capabilities)

Common DID prefixes ("did:wba:", "did🔑") are stripped and encoded as single-byte type indicators.

2.3 Payload Encoding

Payloads are encoded using CBOR (Concise Binary Object Representation, RFC 8949) and optionally compressed using zstd compression. The compression flag in the header indicates whether decompression is required.

2.4 Error Correction

Reed-Solomon forward error correction is applied to the complete message, enabling recovery from partial data loss or corruption:

  • Low (7%): Recovers approximately 7% data loss
  • Medium (15%): Recovers approximately 15% data loss
  • High (30%): Recovers approximately 30% data loss

The ECC block includes a 2-byte length field followed by Reed-Solomon parity bytes.

3. Action Codebook

The protocol defines an enumerated action space of 65,536 possible operations organized into ranges:

RangeCategoryExample Actions
0x0000-0x00FFCorePING, PONG, DISCOVER, HANDSHAKE, ACK, ERROR
0x0100-0x01FFTaskTASK_CREATE, TASK_DELEGATE, TASK_UPDATE, TASK_COMPLETE
0x0200-0x02FFDataDATA_REQUEST, DATA_RESPONSE, DATA_STREAM
0x0300-0x03FFGovernancePOLICY_QUERY, ATTEST, AUDIT_LOG
0x0400-0xFFFFReservedFuture standardization and extensions

This enumerated approach contrasts with JSON-based protocols that transmit verbose action names, significantly reducing message size.

4. Transport Encoding

Binary messages are encoded to Unicode text using Base65536 encoding, which encodes 16 bits per Unicode character using carefully selected codepoints that survive platform handling (copy-paste, normalization, compression).

Platform capacities with High ECC (30% overhead):

PlatformMax CharactersUsable Payload
Twitter/X280~300 bytes
Discord2,000~2.2 KB
Telegram4,096~4.4 KB
Slack40,000~43 KB

5. Multi-Part Messages

For payloads exceeding single-message capacity:

  1. Multi-part flag set in header
  2. Sequence field encodes fragment ID and total count
  3. First fragment includes total payload size and CRC16
  4. Each fragment includes independent ECC for per-fragment recovery
  5. Receiver reassembles based on sequence IDs

6. Security Considerations

Optional security features:

  • Signing: Ed25519 signatures appended after ECC block
  • Encryption: XChaCha20-Poly1305 authenticated encryption
  • Key Exchange: X25519 via HANDSHAKE action
  • Replay Protection: Sequence numbers and payload timestamps

7. Example Implementation

A PING message from agent "steve" to agent "scout":

Wire format (29 bytes):

11 00 01 00 00 10 00 00  # Header: v1, PING, no payload, Low ECC
01 00 05 73 74 65 76 65  # Identity: did:wba, from "steve"
00 05 73 63 6F 75 74     # to "scout"
00 00                     # Capabilities: none
00 02 A7 3F              # ECC: 2-byte parity

Base65536 encoded (18 characters):

㐑㐁䐀㐀㐁𓄅驴驶㤀顳𓍯㑴㐀𢴂ᔿ

Claims Disclosed (Defensive)

The following concepts are hereby disclosed to establish prior art and prevent future patent claims:

  1. A method for encoding agent-to-agent coordination messages using high-density Unicode encoding for transmission over character-constrained social media platforms.

  2. A protocol structure comprising fixed header, compressed identity, variable payload, and forward error correction blocks optimized for hostile transport environments.

  3. An enumerated action codebook system with 65,536 possible agent operations encoded as 16-bit identifiers.

  4. A system for multi-agent coordination where complete coordination instructions, identity verification, and error recovery data are encoded within single social media messages.

  5. The combination of Base65536 encoding, CBOR serialization, zstd compression, and Reed-Solomon error correction for agent messaging over public networks.

  6. A method for DID-based agent identity compression using single-byte type indicators and prefix stripping.

  7. A capability advertisement system using 16-bit flags within agent coordination messages.

  8. A multi-part message fragmentation system with per-fragment error correction for large agent payloads.


Prior Art Acknowledgment

This disclosure builds upon existing technologies:

  • Base65536 encoding (qntm/Sam Hughes, 2015)
  • CBOR serialization (RFC 8949)
  • zstd compression (Facebook, 2016)
  • Reed-Solomon error correction (Reed & Solomon, 1960; RFC 5510)
  • Decentralized Identifiers (W3C DID Core)
  • Agent communication concepts (FIPA-ACL, KQML)

The novel contribution is the specific integration and optimization of these technologies for agent coordination over character-constrained public social media platforms.


Publication Statement

This technical disclosure is published to establish prior art under 35 U.S.C. § 102. By publishing this disclosure, DBH Ventures dedicates the described inventions to the public domain for prior art purposes, preventing the issuance of future patents on these concepts to any party, including the authors.

Published: February 8, 2026
Location: https://timespent.xyz/blog/dense-protocol-defensive-publication
Repository: https://github.com/dbhurley/carbongroup


License

This defensive publication is released under CC0 1.0 Universal (Public Domain Dedication) for prior art establishment purposes.