MSC4354: Sticky Events #4354

kegsay · 2025-09-16T07:37:31Z

Rendered

Client (receive/handle) [MatrixRTC] Sticky Events support (MSC4354) matrix-js-sdk#5017
Client (usage) Add sticky event support element-hq/element-call#3513
Server MSC4354: Sticky Events element-hq/synapse#18968
Complement Tests MSC4354: Sticky Events complement#806

SCT Stuff:

FCP tickyboxes

MSC checklist

It wasn't particulalry useful for clients, and doesn't help equivocation much.

proposals/4354-sticky-events.md

Co-authored-by: Johannes Marbach <n0-0ne+github@mailbox.org>

proposals/4354-sticky-events.md

richvdh

Nothing major, but I do have some minor questions, and a bunch of suggestions for making this easier to read (and hence likelier to land)

proposals/4354-sticky-events.md

richvdh · 2025-10-28T23:04:20Z

proposals/4354-sticky-events.md

+thus leak metadata. As a result, the key now falls within the encrypted `content` payload, and clients are expected to
+implement the map-like semantics should they wish to.  
+[^ttl]: Earlier designs had servers inject a new `unsigned.ttl_ms` field into the PDU to say how many milliseconds were left.
+This was problematic because it would have to be modified every time the server attempted delivery of the event to another server.


This was problematic because it would have to be modified every time the server attempted delivery of the event to another server.

Doesn't the spec require that today with the age field?

Yeah but not over federation. I mostly added this because Erik seemed to think this was a downside in his earlier proposal:

Also having a short expiry makes retries over federation annoying (as they are for events with age), since you need to mutate the contents before retrying a request

Do you want me to add anything to this?

proposals/4354-sticky-events.md

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Co-authored-by: Timo <16718859+toger5@users.noreply.github.com>

MSC: matrix-org/matrix-spec-proposals#4354 This is for policyserv so we can block sticky events in our public rooms (they aren't needed there)

turt2live · 2025-11-18T03:14:41Z

This MSC appears to still be in flux and is failing to acquire checkboxes. Because I'm the one that initially asked for FCP, I'm cancelling that request at the moment. Another SCT member can put it forward again at any time.

@mscbot fcp cancel

MadLittleMods · 2025-12-03T17:52:02Z

proposals/4354-sticky-events.md

+Over Simplified Sliding Sync, Sticky Events have their own extension `sticky_events`, which has the following response shape:
+
+```js
+{
+  "rooms": {
+      "!726s6s6q:example.com": {


Clarify which rooms show up here. All rooms or only rooms relevant to the lists/room_subscriptions

reivilibre · 2025-12-11T15:29:53Z

proposals/4354-sticky-events.md

+ - B) Persist the sticky events but wait a while before delivering them to clients.
+
+Option A means servers don't need to store sticky events in their database, protecting disk usage at the cost of more bandwidth.
+To implement this, servers MUST return a non-2xx status code from `/send` such that the sending server


suspicious: rather than saying what code you should use, it says what code you shouldn't. If we want to suggest this approach I think we should provide stronger guidance.
But the /send endpoint already has per-event statuses, so this feels a bit off as an approach. Separately, a non-2xx response will likely just cause the sending server to retry and/or mark you as down.
For this reason it's hard to recommend this approach and I'm wondering if we should recommend against it, except as a fallback when you're desperate / dealing with a highly-likely malicious case?

…pagination'

reivilibre · 2025-12-19T17:02:51Z

proposals/4354-sticky-events.md

+Sticky messages MAY be sent in the timeline section of the `/sync` response, regardless of whether
+or not they exceed the timeline limit[^ordering]. If a sticky event is in the timeline, it MAY be


This (allowing servers to exceed the limit of the existing timeline section) seems like a breaking change and I'd be uncomfortable supporting it.

reivilibre · 2025-12-19T17:03:37Z

proposals/4354-sticky-events.md

+Sticky messages MAY be sent in the timeline section of the `/sync` response, regardless of whether
+or not they exceed the timeline limit[^ordering]. If a sticky event is in the timeline, it MAY be
+omitted from the `sticky.events` section. This ensures we minimise duplication in the `/sync` response JSON.
+This proposal recommends always putting sticky events into the `sticky.events` section _except_ if


I'd like to suggest we make this MUST rather than recommendation.
I don't see any benefit in allowing divergence and it could result in clients mishandling events on some server implementations.

HarHarLinks · 2026-01-20T23:57:21Z

proposals/4354-sticky-events.md

+These messages may be combined with [MSC4140: Delayed Events](https://github.com/matrix-org/matrix-spec-proposals/pull/4140)
+to provide heartbeat semantics (e.g required for MatrixRTC). Note that the sticky duration in this proposal
+is distinct from that of delayed events. The purpose of the sticky duration in this proposal is to ensure sticky events are cleaned up,
+whereas the purpose of delayed events is to affect the send time (and thus start time for stickiness) of an event.


Sticky events is an awesome and fun name, I would even say elegant if it wasnt for the following issue. It appears to be named after an implication of what it does, but I think the metaphor isn't at all obvious. This is particularly true wrt self-destruct semantics (= inverted heartbeat) of delayed events as the apparent need for this clarifying section emphasizes.

In conversation with peers, people who have not read this MSC but only somehow heard about it are usually assuming some kind of self-destruction related to the timer. Perhaps the event "sticks around" that long. It's quite possible this is also burdened by mixup with that actual requirement as delayed events and matrixrtc as a whole remain a developing topic, and so often both being mentioned in one sentence.

My interpretation after reading is that they are sticky in a sense of sticking to the top, eager high priority sharing, similar to state events, and eventually unsticking to fall back to regular priority.

I realize I'm a bit late to complain about the name which has already been used proudly in public a bunch. We could sti consider finding a name that more intuitively fits the purpose. Priority Events, Important Events?

BillCarsonFr

I have a question regarding mixed content sticky chains (clear sticky replacing encrypted sticky)

BillCarsonFr · 2026-01-23T07:29:27Z

proposals/4354-sticky-events.md

+As such, this proposal relies somewhat on NTP to ensure clocks over federation are roughly in sync.
+As a consequence of this, the sticky duration SHOULD NOT be set to below 5 minutes.[^ttl] 
+
+### Encryption


What is the strategy regarding Mixed Content sticky chain? Like a clear event replacing an encrypted one?
Can we disable mixed content? Only an encrypted event can replace an encrypted sticked event.

Or at least having a way to discard such a sticky event?
If not it would be like allowing clear edits of encrypted messages without showing a big red warning.

FWIW there is prior art / similar rules for edits validity of replacement events

Maybe we could add similar rules? to be consistent.
Things like

The replacement and original events must have the same type

If the original event was encrypted the replacement should be too.

I guess this is referring to the 'Addendum: Implementing an ephemeral map'? I wonder if the formalisation of that addendum would be better-suited to another MSC?

reivilibre · 2026-01-26T13:24:18Z

proposals/4354-sticky-events.md

+
+When an event loses its stickiness, these properties disappear with the stickiness. Servers SHOULD NOT
+eagerly synchronise such events anymore, nor send them down `/sync`, nor re-evaluate their soft-failure status.
+Note: policy servers and other similar antispam techniques still apply to these events.


It should probably be described what this concretely means. (coming from the PR review)

From the Synapse PR that was developed alongside the MSC, I'm taking this to mean that we don't treat the events as sticky at all if our policy server is not happy with them, so we don't propagate them to other servers or clients.

Sticky Events

57ccc48

kegsay changed the title ~~Sticky Events~~ MSC4354: Sticky Events Sep 16, 2025

kegsay added 3 commits September 16, 2025 08:51

Remove prev_batch

94b1a87

It wasn't particulalry useful for clients, and doesn't help equivocation much.

Update 4354-sticky-events.md

50d76e6

Update 4354-sticky-events.md

3baf0d8

ara4n reviewed Sep 16, 2025

View reviewed changes

proposals/4354-sticky-events.md Outdated Show resolved Hide resolved

Update 4354-sticky-events.md

29e9bf7

turt2live added proposal A matrix spec change proposal client-server Client-Server API kind:core MSC which is critical to the protocol's success needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Sep 16, 2025

turt2live added this to Spec Core Team Workflow Sep 16, 2025

github-project-automation bot moved this to Tracking for review in Spec Core Team Workflow Sep 16, 2025

turt2live added the matrix-2.0 Required for Matrix 2.0 label Sep 16, 2025

turt2live reviewed Sep 16, 2025

View reviewed changes

proposals/4354-sticky-events.md Show resolved Hide resolved

turt2live reviewed Sep 16, 2025

View reviewed changes

proposals/4354-sticky-events.md Outdated Show resolved Hide resolved

Syntax

b6e8159

Johennes reviewed Sep 17, 2025

View reviewed changes

proposals/4354-sticky-events.md Show resolved Hide resolved

Johennes reviewed Sep 17, 2025

View reviewed changes

proposals/4354-sticky-events.md Show resolved Hide resolved

kegsay and others added 7 commits September 18, 2025 13:06

Update proposals/4354-sticky-events.md

33ec282

Co-authored-by: Johannes Marbach <n0-0ne+github@mailbox.org>

Update proposals/4354-sticky-events.md

7725f74

Co-authored-by: Johannes Marbach <n0-0ne+github@mailbox.org>

Update 4354-sticky-events.md

192c6b4

Update 4354-sticky-events.md

97c9c5b

Update 4354-sticky-events.md

8d101fd

Update 4354-sticky-events.md

c75e19c

Update 4354-sticky-events.md

c925a4c

ara4n reviewed Sep 19, 2025

View reviewed changes

proposals/4354-sticky-events.md Outdated Show resolved Hide resolved

kegsay added 3 commits September 22, 2025 08:11

Update 4354-sticky-events.md

6524be2

Update 4354-sticky-events.md

d14448c

Update 4354-sticky-events.md

ce37b02

MadLittleMods mentioned this pull request Oct 22, 2025

MSC4140: finalised delayed events, and more element-hq/synapse#19038

Draft

3 tasks

richvdh requested changes Oct 28, 2025

View reviewed changes

kegsay and others added 6 commits October 29, 2025 08:51

Apply suggestions from code review

0d5e4d8

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Co-authored-by: Timo <16718859+toger5@users.noreply.github.com>

Redaction and last-to-expire commentary

7e54063

vdh comments

da7c7c7

more vdh

50c1910

More vdh comments

732a72b

Pagination

e5c1635

turt2live added a commit to matrix-org/gomatrixserverlib that referenced this pull request Nov 3, 2025

Add sticky event parsing (#462)

eb14008

MSC: matrix-org/matrix-spec-proposals#4354 This is for policyserv so we can block sticky events in our public rooms (they aren't needed there)

mscbot added proposal-in-review and removed proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. disposition-merge labels Nov 18, 2025

turt2live moved this from Ready for FCP ticks to Ready for general review in Spec Core Team Workflow Nov 18, 2025

turt2live removed the 00-weekly-pings Tracking for weekly pings in the SCT office. 00 to make it first in the labels list. label Nov 18, 2025

anoadragon453 mentioned this pull request Nov 19, 2025

Consider supporting all endpoints for delayed events (MSC4140) across workers element-hq/synapse#19141

Open

turt2live moved this from Ready for general review to Tracking for review in Spec Core Team Workflow Dec 2, 2025

MadLittleMods reviewed Dec 3, 2025

View reviewed changes

reivilibre reviewed Dec 11, 2025

View reviewed changes

reivilibre force-pushed the kegan/persist-edu branch 2 times, most recently from 2183282 to 68581b7 Compare December 16, 2025 16:37

Replace 'companion endpoint pagination' with MSC3885-style 'subtoken …

331484d

…pagination'

reivilibre force-pushed the kegan/persist-edu branch from 68581b7 to 331484d Compare December 16, 2025 16:43

Describe interaction of sticky events with /sync RoomFilter

4340903

reivilibre reviewed Dec 19, 2025

View reviewed changes

HarHarLinks reviewed Jan 20, 2026

View reviewed changes

BillCarsonFr reviewed Jan 23, 2026

View reviewed changes

toger5 mentioned this pull request Jan 23, 2026

Sticky event support is missing spec matrix-org/matrix-widget-api#156

Closed

reivilibre reviewed Jan 26, 2026

View reviewed changes

MadLittleMods mentioned this pull request Jan 26, 2026

Support sending and receiving MSC4354 Sticky Event metadata. element-hq/synapse#19365

Merged

		Sticky messages MAY be sent in the timeline section of the `/sync` response, regardless of whether
		or not they exceed the timeline limit[^ordering]. If a sticky event is in the timeline, it MAY be

MSC4354: Sticky Events #4354

Are you sure you want to change the base?

MSC4354: Sticky Events #4354

Conversation

kegsay commented Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

richvdh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

turt2live commented Nov 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BillCarsonFr left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

reivilibre Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

18 participants

kegsay commented Sep 16, 2025 •

edited

Loading

reivilibre Jan 26, 2026 •

edited

Loading