Multicast BEEF Object Frame Format

Abstract

This BRC specifies the three wire forms of the BRC-148 BEEF object plane: the multicast object frame (FrameVer 0x09, assigned here), which carries one BEEF-family transaction object on the plane's domain-tagged shard groups; the submission record, the unicast envelope a publisher sends to operator ingress naming one object to one or more overlay topics; and the delivery record, the unicast envelope a delivery edge streams to a subscriber. The frame reuses the BRC-124 92-byte header layout at identical offsets, so existing classifiers, retransmission, and fragmentation infrastructure require no changes. The records exist because BEEF bytes are not self-delimiting without a full structural parse — which the fabric never performs — so unlike the BRC-143/BRC-144 push lanes, BEEF lanes carry an explicit length-carrying envelope.

Copyright

This BRC is licensed under the Open BSV License.

Motivation

BRC-148 allocates the BEEF object plane (domain 0x1), defines its topical sharding, filtering, and coordination, and constrains the header fields that addressing, retransmission, and filtering depend on — but, following the convention that frame formats are specified separately from addressing (BRC-124 vs BRC-129; BRC-143/BRC-144 vs their carriage rules), it defers the concrete formats to this BRC. This BRC assigns the frame version and fixes the byte layouts: the fabric frame, and the two unicast record forms that carry BEEF objects between participants and operator infrastructure.

Specification

BEEF object frame (FrameVer 0x09) — 92-byte header + payload

FrameVer 0x09 is assigned to the BEEF object frame (the next code after BRC-142's 0x08).

Object leading bytes — BEEF version word

The object is the record's Object field, or the whole payload when the payload is a bare object.

The version word is the BRC-148 version filter's input — an encoding-capability gate only, never an overlay namespace. Intentionally absent from the header: the subject TxID (consumer-level semantics inside the payload) and any per-format sub-type byte (the marker is self-identifying at a fixed offset).

Fragmentation

Objects exceeding the path MTU are carried as BRC-130 fragments (FrameVer 0x03, OrigFrameVer = 0x09) with bytes 0–91 layout-identical to the table above, so ContentID, TopicID and DeliverCount appear in every fragment; ContentID is the reassembly verification hash. Reassembly MUST key slots on the (ContentID, TopicID) pair. The record's field order puts the topic list before the object, so fragment 0 carries the whole list and an edge may discard a non-matching object before reassembling it; that order is fixed for this reason. The interaction with filtering is specified in BRC-148 §Frame carriage.

Submission record (ingress)

A publisher submits the pair (topic list, BEEF object) as one record:

Offset  Size  Field
  0       2   Tag         (uint16 BE = 0xBEEF — record discriminator on shared ports)
  2       1   RecordVer   (0x01)
  3       1   TopicCount  (1..15)
  4       …   Topics      (TopicCount × { uint8 NameLen (1..64) ∥ NameLen bytes UTF-8 topic name })
  …       4   ObjectLen   (uint32 BE, ≥ 1; operators bound the maximum accepted size)
  …       …   Object      (the BEEF object; leading marker per the version-word table)

The ingress emits the record as one FrameVer 0x09 frame at any topic count: the payload is the record verbatim, TopicID = SHA-256(topics[0]), ContentID is over the record, and the frame goes to the first topic's group. Ingress duplicate suppression keys on the (ContentID, TopicID) pair per BRC-148. A record whose object does not lead with a marker from the version-word table, whose lengths violate the bounds above, or whose object exceeds the operator's size bound MUST be rejected. A malformed record desynchronises its stream; the receiver MUST close the connection.

Deliverable topics and labels

A record names 1..15 topics on every path and is never rejected for its count. What the ingress path decides is how many of the leading names are deliverable — matched by delivery edges against subscribers' elections — and it writes that number into DeliverCount. Every further name is a label: it reaches every subscriber the object reaches, inside the payload, and is never matched on, so a subscriber electing only a label topic does not receive the object.

• Open / public / anonymous ingress MUST set DeliverCount = 1. One deliverable topic per anonymous record is what keeps the free door free of amplification: a record costs one frame and reaches one topic's subscribers however many names it carries.
• Authenticated / consumer-tunnel ingress MAY set DeliverCount up to the operator's cap, which is at most 15 and is operator policy. The operator's fan-out exposure is bounded by that cap, not by TopicCount.

DeliverCount is the ingress's to set. An ingress accepting a pre-framed FrameVer 0x09 MUST overwrite it from its own policy for that source, and MUST reject a pre-framed record whose header TopicID is not the hash of its first topic. There is no per-topic charge on either path: nothing beyond the deliverable prefix is delivered, so nothing beyond it is priced, and a subscriber's cost stays what its lane carried.

A subscriber that elected more than one of a frame's deliverable topics receives the object once, under the first elected topic in record order; the delivery record below names that topic.

Detection on shared ports

BEEF submission records MAY ride the open transaction port alongside the existing grammars, distinguished by leading bytes — network magic 0xE3E1F3E8 selects a framed datagram, the 0xBEEF tag selects a submission record, and anything else is a bare transaction (BRC-12 raw / BRC-30 Extended Format, whose little-endian version byte at offset 1 is 0x00 — the three forms cannot collide). Over TCP the grammar is committed once per connection; over UDP it is detected per datagram, and a record must fit one datagram (larger objects submit over a stream transport). Operators MAY additionally expose a dedicated single-record-grammar port for flow separation; it carries no additional admission semantics.

Delivery record (egress)

A delivery edge streaming BEEF objects to a subscriber over a unicast lane emits, per delivered object:

Offset  Size  Field
  0      32   TopicID     (the identifier of the elected topic that matched)
 32       4   PayloadLen  (uint32 BE, ≥ 1)
 36       …   Payload     (the frame payload verbatim: the submission record, or a bare object)

The TopicID is the one of the subscriber's elected topics that the edge matched, which need not be the frame's header TopicID. The payload is the frame payload verbatim, so when the publisher submitted a record the subscriber receives every topic name it wrote, deliverable and label alike, and can map the matched identifier back to one of them; a subscriber that receives a bare object maps the identifier back from its own election. The subscriber tells the two forms apart by the payload's leading bytes exactly as the frame does. Subscribers taking whole FrameVer 0x09 frames instead of a stripped lane need no record; the frame already carries the identifiers and the payload.

References

• BRC-12: Raw Transaction Format — bare-transaction grammar sharing the open port
• BRC-30: Extended Format Transaction — bare-transaction grammar sharing the open port
• BRC-62: Background Evaluation Extended Format (BEEF) Transactions — BEEF encoding and version word
• BRC-95: Atomic BEEF Transactions — explicit-subject BEEF encoding
• BRC-96: BEEF V2 Txid Only Extension — TXID-only BEEF encoding
• BRC-124: Multicast Transaction Frame Format — the 92-byte header layout this frame reuses
• BRC-126: Multicast Transaction NACK Retransmission Protocol — retransmission machinery operating on HashKey/SeqNum
• BRC-130: Multicast Transaction Frame Fragmentation — fragmentation for large objects
• BRC-143 / BRC-144 (Multicast Subtree Data / Block Push Frame Formats) — push-lane format precedent
• BRC-148: Multicast Shard Domain Partitioning and the BEEF Object Plane — the plane, sharding, filtering, and coordination this format serves