MSC4354: Sticky Events

[kegsay]

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

[HarHarLinks]

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]

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.

[BillCarsonFr]

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.

[reivilibre]

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]

I think sticky events in this situation will never come down the timeline section of sliding sync, but I need to confirm that.
In the Synapse implementation it looks like Sliding Sync only shows events since you joined the room.

[reivilibre]

No mention of max number of sticky events in the response, or how the client can configure such a limit.

[benkuly]

What is the use case of having sticky state events? Isn't there already a delivery guarantee for state events? Additionally in the section above the wording is "Message events", which does not contain state events, does it?

[benkuly]

A more general thought: I understand, that putting the sticky_key and original type into the decrypted content prevents server side metadata. On the other side, the server isn't able to filter out old sticky events with the same sticky_key, that is still valid or the type via sync filter. This problem is also present for "normal" encrypted message events, but this MSC adds additionally cases, because due to the delivery guarantee the client in enforced to receive and decrypt events, that he might not be interested in.

E. g. MSC4362 puts the type:state_key still unencrypted on top level of the encrypted event, which could allow at least client side filters but theoretically server side filters too.

[reivilibre]

If a room is newly-joined, is the server meant to send down all the pre-existing sticky events?
(If so, that is going to get fiddly because we need to track that backlog in the sync token so we can send pages of 50 sticky events down at a time)

This question also applies to the equivalent sliding sync extension.

[kegsay]

All unexpired sticky events for that room, yes. It should be functionally the same as how we send all pre-existing room state to the client when they join a room, so the transition to join should:

• inspect the sync token to see its event stream position
• load all unexpired sticky events in that room < that stream position
• include them in the response

Am I missing something here?

[reivilibre]

The trouble is that it's difficult to paginate to include only (e.g.) 50 sticky events in one response, if we do it directly like that.

What happens if there are 1000 active sticky events?

We can decide to send them all down to the client at once, no matter what, but I don't know if that's reasonable or not.

[kegsay]

I would personally use "It should be functionally the same as how we send all pre-existing room state to the client when they join a room" as a guide here. When you join a room with 1000 current state events, do we paginate it? No. So why should we do this with sticky events?

[reivilibre]

I guess I'm happy to go along with that, though I suppose a difference is that for state events, only users with PL ≥ 50 can send new ones by default (other than their membership, where only one can be active at a time), whereas sticky events can be sent by anyone.

We possibly want to consider the abuse considerations a bit more (...should we have an 'Abuse Considerations' section alongside the Security Considerations one?).

If some user decides to spam my room with 1k, 10k, 100k, 1M or more sticky events and we have to push this down the pipe to clients, should I have any tooling to deal with that?

For example,

• Make sticky events become un-sticky if the sender leaves|gets banned|gets kicked (?)?
• Make sticky events become un-sticky when redacted?

[kegsay]

The point of treating it semantically the same as room state is to piggyback off any existing protections, rather than having a patchwork of protections. A malicious actor can join 100k users to the same room today. We protect against this by rate limiting, policy servers, and setting the join rules to invite. Sticky events would benefit from the same protection measures (they are rate limited using the same mechanism, checked by policy servers in the same way, and the act of stopping bad users from joining stops them being able to send sticky events in the first place).

Do we really need an extra safeguard here?

As an aside, we must also consider the whole protocol not parts in isolation. For example, we do not rate limit messages. When considered in part, this is fine as each /sync response is bounded by timeline_limit. In practice though, the whole app behaviour is not really any different because most apps automatically and repeatedly ask for older /messages if the viewport is not full, allowing a similar amount of bandwidth to be consumed by just sending 100k junk events.

[reivilibre]

Hm, I find it hard to resonate with that: the main protection against state event spam is that users can't actually bloat the state space with PL0. (This doesn't apply to sticky events, right?)

I don't think policy servers currently have any protection mechanism against either state nor sticky events; once a policy server rule had been written it would be too late to enforce it for the room that was already polluted. (With a slight benefit for sticky events given that they expire, so the storm would 'blow over' so to speak.)

We don't send the full state set down to syncing clients; see for example lazy-loading room memberships where we only include 'relevant' state. This is another aspect that's new with sticky events: clients don't get any control and the server is actually being required to send the entire set down.

Applying rate limits to sticky event (or indeed, any kind of event) spam over federation is difficult.

However the protection for timeline events is that clients don't have to see them all; typical clients only request enough history to fill the visible client window and the federation protocol doesn't require you to have all of the timeline. This is again a situation that changes with sticky events (in fact, that's the motivating reason for them to exist).

I am finding it hard to know what the right course is here fwiw (and trusting our existing safeguards might indeed be the right call), but it does feel to me that sticky events can be a potential unprivileged abuse vector with novel repercussions in several of these axes.

[kegsay]

users can't actually bloat the state space with PL0.

..but they can, by joining new users they control.

We don't send the full state set down to syncing clients; see for example lazy-loading room memberships where we only include 'relevant' state.

..but we do. We explicitly send all membership deltas between two sync tokens even with lazy loading enabled.

once a policy server rule had been written it would be too late to enforce it for the room that was already polluted

..which is true in basically all "reactive" scenarios, e.g. changing the join rule to invite-only, banning users, etc.

---

I don't dispute that it allows more bandwidth to be consumed over the CS link. I don't think adding a patchwork of bandwidth protections is the right call: it just further reinforces the whole "whoops, the protocol grew organically, so there's one way to do this, another way to do that, and this thing isn't possible because it was done before we did things this way". If we are serious about having bandwidth control on the CS link then we should.. have an MSC that talks about it. The fact we don't is perhaps the biggest indication that this isn't a problem in practice. Having a holistic view allows us to address other elephants in the room (to-device messages, device lists, invites, etc all of which are unbounded and attacker controlled, in addition to the whole-protocol-view that apps typically do follow-up requests which can also consume lots of bandwidth (e.g. threaded operations which defer to thread specific endpoints, /messages and backfill).

I'm also fairly bullish on this because of the 1 hour limit on sticky events. This means you need a continuous active attack for it to consume lots of bandwidth, which is a high bar compared to.. basically every other payload in the CS link :S so I do find it quite bizarre to focus on bandwidth concerns quite so much for this MSC, yet neglect it in all the others (see: organic growth).

[MadLittleMods]

(cross-linking another conversation about shotgun bandwidth optimizations vs holistic approach, #4186 (comment))

[benkuly]

Just a note: Trixnity does implement this MSC with (as usual) high test coverage here: https://gitlab.com/connect2x/trixnity/trixnity/-/merge_requests/687

This does not mean, that I like how the MSC is right now (see my review).

[Saiv46]

This proposal should supercede #4357