Repository navigation
Conversation
Signed-off-by: Igor Somov <donprusne@gmail.com>
96e3889 to
2518c94
Compare
DonPrus
changed the title
DonPrus
changed the title
| messages. | ||
| - **Storage**: Live sessions produce more events. Deployments can rely on retention policies and rate-limits. | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
Conceptually this proposal sounds similar to #3489 (live location sharing). That one uses a state event and reference relations though. Replacements strike me as a more intuitive solution though.
There was a problem hiding this comment.
I agree the concept is similar to MSC3489 in that both stream incremental state. For live text, I believe m.replace on m.room.message is the most intuitive and compatibility‑friendly primitive: older clients already understand “edits” and will converge to the final content; supporting clients can render the intermediate states seamlessly. It also avoids adding a new event type purely for live typing and reuses the well‑understood edit aggregation path (per MSC2676 / spec).
|
|
||
| ### Semantics: | ||
|
|
||
| - If absent, default is enabled (unless server policy states otherwise). |
There was a problem hiding this comment.
IIUC the enforcement can only happen on the client side. This means clients would need a way to discover such global server policy?
There was a problem hiding this comment.
In the draft I wrote “default is enabled (unless server policy states otherwise)”, which is ambiguous without a standard way to advertise that policy. I propose to clarify that the normative control here is room‑level via m.room.live_messaging; clients MUST honor it. Servers MAY reject live‑marked events in unencrypted rooms as a local policy, but there is no standardized discovery for a global ban, so it’s out of scope for this MSC. I’ll remove/adjust the “unless server policy states otherwise” wording to avoid implying a discovery mechanism that doesn’t exist
|
|
||
| - If absent, default is enabled (unless server policy states otherwise). | ||
| - If `enabled: false`, clients **MUST NOT** offer live mode in this room. | ||
| - Servers **MAY** enforce rejection of events that carry live markers in rooms where it is disabled. |
There was a problem hiding this comment.
This is only possible in unencrypted rooms because org.matrix.msc4357.live is in content which is encrypted.
There was a problem hiding this comment.
yep, feature still works end‑to‑end (supporting clients decrypt, detect the marker, and render progressively), but enforcement and special aggregation are client‑side only in E2EE. I’ll add an explicit “E2EE considerations” subsection stating that server‑side enforcement is only feasible in unencrypted rooms.
| update replaces the entire content (`m.new_content` reflects the complete current text). | ||
| - **Completion**: on explicit send or mode exit, send a final update without the live marker. After this, do not send | ||
| further updates for this session. | ||
| - **Rate limiting**: clients **MUST** avoid flooding and respect server guidance; batching is encouraged. |
There was a problem hiding this comment.
Does batching mean combining several updates into a single event replacement?
There was a problem hiding this comment.
By batching I mean coalescing local interim changes and emitting a single m.replace update at a bounded cadence (e.g. every ~2–3s or at natural boundaries like end‑of‑word), rather than sending an event per keystroke. Each update still contains the full current content in m.new_content; there’s no special “multi‑update container”. I’ll tighten the wording to make this explicit.
| - **Completion**: on explicit send or mode exit, send a final update without the live marker. After this, do not send | ||
| further updates for this session. |
There was a problem hiding this comment.
Is it allowed to transition back from completion into live mode?
There was a problem hiding this comment.
I intend completion to be terminal for that message. Once the final update (without the live marker) is sent, the live session is over. Further changes are normal edits; resuming live mode should be done by starting a new live message. Allowing a message to re‑enter live mode risks confusing clients (especially non‑supporting ones) that have already treated it as finalized. I’ll add a normative MUST‑NOT to make this explicit.
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client (sending)
- Client (receiving)
|
Shouldn't we use Sticky Events from MSC4354? It seems a perfect fit for live messages. Then on completion just send ordinary message without the edits. Otherwise users would hit into existing rate limits by constantly updating a single message. |
When the Matrix channel plugin uses `streaming: "partial"` mode, the
draft preview messages and their progressive edits now carry the
`org.matrix.msc4357.live` marker. This allows supporting Matrix clients
(e.g. Robrix) to render a streaming animation while the LLM is
generating a response, instead of showing repeated edit flashes.
Flow:
1. Initial draft message is sent with `org.matrix.msc4357.live: {}`
2. Each progressive edit also carries the live marker
3. When the stream completes, a final edit is sent WITHOUT the marker,
signaling to clients that the stream has ended
Non-supporting clients are unaffected -- they see normal message edits
as before, gracefully degrading to the existing behavior.
Ref: matrix-org/matrix-spec-proposals#4357
|
@Saiv46 Sticky events solve a different problem:
This MSC seems to be targeted so that If I am already looking at an event i can see updates. Sticky events are useful if you want a timeline item to (for at most 1h) have an impact on the room list even for gappy syncs where you are not yet actively viewing a room. |
5 participants
Summary
This MSC proposes "Live Messages": recipients see a message evolve in real time while it is being typed.
It leverages existing m.replace edits on m.room.message (no new event type), marked by an unstable
flag in content to denote a "live session". Non-supporting clients gracefully degrade to a normal edited
message; supporting clients render a smooth, streaming-like UX.
What this adds
org.matrix.mscXXXX.live: {}; subsequent updates usem.replacewith full
m.new_content; the final update omits the live flag (session complete).m.room.live_messaging(enabled: boolean) to allow room-level opt-in/out.Backwards compatibility
Old clients see "a message with edits" and always end up with the final content.
Rendered Markdown
Rendered: proposals/4357-live-messages.md
Author
Author: @DonPrus