From the protocol audit (P1). Every rich message carries BOTH the plain content fallback and parts[] (protocol principle 4 — Telegram-class frontends read content). For parts-capable clients this is duplicated payload on every rich frame.
Since #102 the auth handshake carries client capabilities (parts" is already declared by the web client and stored per-connection in SocketData). **Plan:** when every attached client on a connection declared parts", omit/empty the content field on rich frames for that connection (per-connection shaping happens at the AttachedClient.send boundary; scrollback stores stay complete). Needs care: scrollback replay frames are shared chunk arrays — shaping must be per-connection serialization, not mutation of the stored message. Measure before building: % of frame bytes that are fallback content in a typical tool-heavy session.
From the protocol audit (P1). Every rich message carries BOTH the plain
contentfallback andparts[](protocol principle 4 — Telegram-class frontends readcontent). For parts-capable clients this is duplicated payload on every rich frame.Since #102 the auth handshake carries client capabilities (
parts" is already declared by the web client and stored per-connection inSocketData). **Plan:** when every attached client on a connection declaredparts", omit/empty thecontentfield on rich frames for that connection (per-connection shaping happens at theAttachedClient.sendboundary; scrollback stores stay complete). Needs care: scrollback replay frames are shared chunk arrays — shaping must be per-connection serialization, not mutation of the stored message. Measure before building: % of frame bytes that are fallback content in a typical tool-heavy session.