3DN Standards Track — Informational
Category: Delta fabric / multi-agent hop language
Obsoletes: none
Updates: none

M2M: Model-to-Model Fabric Language
Version 0 (Draft)

Title

M2M — Model-to-Model Fabric Language

Version

0 (draft for implementation)

Status

Draft — published for interoperability; not an IETF RFC

Organization

3DN

Audience

Router implementers, agent authors, fabric operators

Bus context

Delta architecture: routers as the unit; human language and M2M as distinct hop payloads

Related

Delta, not river

1. Abstract

M2M is a compact fabric language for hops between software routers that host or front neural models. It is not a human natural language and not a claim of shared neural token IDs across vendors. M2M defines messages, a textual canonical form (for logs and debugging), and a binary on-wire form (for efficient hop payloads). Human languages (e.g. English) remain first-class on the fabric for desk and UI hops; seats declare preferred languages (e.g. English, M2M).

This document is published in the style of an RFC for clarity. It is a 3DN standards draft, not submitted to the IETF.

2. Conventions and terminology

The key words “MUST”, “MUST NOT”, “SHOULD”, and “MAY” are to be interpreted as described in RFC 2119 / RFC 8174 when used in uppercase.

3. Design goals

1. Heterogeneous models — Grok, Qwen, Claude, Codex, and local NNs share one hop envelope without shared tokenizer IDs.
2. High and low fabric — M2M is a generalized hop language for routers, not “another TCP/IP server API.” Version 0 ships as a TCP/IP-based router/MUX (desk seats, Delta hub, fabric peers). The same specification is intended to apply unchanged in spirit to lower layers and other media: e.g. router_sdram, router_pci, router_nvlink, on-die / bus agents, and future fabric endpoints. A router is any named hop endpoint that accepts M2M messages; the transport under the hop is an implementation detail of that router class.
3. Non-blocking fabric — submit a hop, continue work, wake on completion (no busy-wait requirement), whether the path is a socket, a queue in memory, or a device doorbell.
4. Dual representation — every field has a human-readable text form and a fixed binary encoding (suitable for both logs and tight hardware paths).
5. Start hard — normative BNF first; implementations MAY begin with the v0 compact stream subset on TCP/MUX while hardware routers catch up.
6. Observable — text form MUST be loggable; binary form MUST round-trip to text form.

4. Non-goals

• Replacing HTTP, TCP, or TLS as Internet plumbing — M2M rides transports; it does not abolish them. (Nor is M2M limited to TCP: see high and low fabric above.)
• A universal private neural code shared by all frontier vendors.
• Replacing English (or other human languages) on desk/UI hops.
• IETF standardization process (this page is intentional local SoT).

5. Core grammar (BNF)

ABNF-inspired BNF. Terminals in quotes; binary terminals described in §6.

; M2M v0 core grammar (normative intent)

m2m-document     = version-line 1*message

version-line     = "M2M" "/" version SP "CRLF"
version          = 1*DIGIT [ "." 1*DIGIT ]          ; e.g. 0 or 0.1

message          = msg-header CRLF msg-body
msg-header       = msg-type SP hop-id SP from-id SP to-id SP lang SP flags
msg-type         = "SUBMIT" / "PROGRESS" / "RESULT" / "ERROR"
                 / "CANCEL" / "WAKE" / "PING" / "PONG"
hop-id           = 16HEXDIG                         ; 64-bit id, hex
from-id          = router-token
to-id            = router-token
router-token     = 1*( ALPHA / DIGIT / "-" / "_" )
lang             = "EN" / "M2M" / 1*4ALPHA           ; short language code
flags            = 8BIT                             ; bit field, text as 8 binary digits or 0xHH

msg-body         = body-encoding SP body-length CRLF body-octets
body-encoding    = "TXT" / "BIN" / "JSON" / "C2C"
body-length      = 1*DIGIT                          ; decimal octet count
body-octets      = *OCTET                           ; exactly body-length octets

; Optional compact single-line result (v0 leaf implementations)
compact-result   = "M2M" "|" token-list "|" "score=" signed-float "|" "n=" 1*DIGIT
token-list       = token *( "," token )
token            = "t" 1*DIGIT ":" signed-float
signed-float     = [ "+" / "-" ] 1*DIGIT "." 1*DIGIT

CRLF             = %x0D.0A
SP               = %x20
HEXDIG           = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
                 / "a" / "b" / "c" / "d" / "e" / "f"

6. Lexicon: textual description and binary representation

Unless noted, multi-byte integers are network byte order (big-endian). Strings in headers are ASCII unless body-encoding says otherwise.

7. Message types

8. Wire framing

M2M messages ride on existing transport:

• TCP seat (mux agent port): optional CONTENT-LENGTH chat framing for human/English; for M2M api seats, body SHOULD be an M2M document or compact stream.
• HTTP leaf (e.g. local NN): POST /v1/forward with JSON {"prompt":…} returning {"language":"M2M","m2m":…} is a permitted v0 bridge.
• Control plane: jobs and image APIs remain HTTP; they MAY embed M2M bodies later.

Non-blocking intent: SUBMIT returns hop_id without requiring the caller to block; WAKE or RESULT is delivered to the submitter inbox when ready. Polling is allowed but not required.

9. Version 0 compact stream (implemented)

Early Delta NN leaves MAY emit a single-line compact RESULT without full headers:

compact-result = "M2M" "|" token-list "|" "score=" signed-float "|" "n=" length

This form is normative for v0 leaves and deprecated as a long-term sole format. Routers SHOULD accept it as shorthand for a RESULT message with lang=M2M and body-encoding=TXT.

10. Examples

10.1 Textual SUBMIT (English body)

M2M/0
SUBMIT 00a1b2c3d4e5f678 android01-mux delta-nn M2M 00001000
TXT 27
classify:disk pressure on edge LB

10.2 Compact M2M RESULT (v0 NN)

M2M|t0:-0.2082,t1:-0.1038,t2:-0.1741,t3:-0.0998,t4:-0.2408,t5:+0.2163,t6:+0.2386,t7:+0.2513|score=-0.0036|n=30

10.3 Binary frame sketch (hex, SUBMIT, empty body)

4D 32 4D 31          ; magic M2M1
01                   ; SUBMIT
00 A1 B2 C3 D4 E5 F6 78  ; hop_id
0B                   ; from len 11
61 6E 64 72 6F 69 64 30 31 2D 6D 75 78  ; "android01-mux" (len as configured)
08 64 65 6C 74 61 2D 6E 6E              ; to "delta-nn"
02                   ; lang M2M
08                   ; flags: wake-on-complete
01 00 00 00 00       ; TXT, length 0

11. Security considerations

• M2M does not provide authentication by itself. Deployments MUST place seats on trusted networks or terminate TLS/SSH externally.
• Body size limits and C2C references reduce amplification risk.
• ERROR bodies MUST NOT include secrets (tokens, passwords).
• Language code M2M MUST NOT be treated as executable code without a declared interpreter profile.

12. Registries (3DN local)

Delta-nn model status

Live weights on the Gaia leaf pair. Updated by POST /v1/learn and full train_m2m.py cycles. Agents MUST keep this block and the learn log in sync (skill delta-nn-retrain).

Delta-nn timeline

Newest last. Full retrain clears pending_full on all incremental facts and marks them Fully in the store + learn log.

16. Delta-nn learn log

When delta-nn is taught new M2M via POST /v1/learn, the fabric documents the outcome here. Learned is either Fully (full retrain path) or Incremental (incremental FT that passed the holdout gate). Normative rows in the tables above that shipped with this draft are marked Fully (designed into the language, not hot-patched).

Incremental rows stay Incremental until the next full training cycle absorbs them (then a timeline/log note marks them Fully). Agents MUST append a row after every successful learn (skill delta-nn-retrain / delta-mux). Do not leave silent weight promotions without a public M2M record.

17. References

• 3DN, “Delta, not river: routers as the unit…”, 2026-09.
• RFC 2119 / RFC 8174 — requirement levels.
• RFC 5234 — ABNF (style reference for the BNF above).

End of 3DN M2M Version 0 (Draft). Revisions will bump the version line and preserve dual text/binary columns.