MSC4354: Sticky Events #4354
MSC4354: Sticky Events #4354
Conversation
It wasn't particulalry useful for clients, and doesn't help equivocation much.
turt2live
added
proposal
github-project-automation
bot
moved this to Tracking for review
in Spec Core Team Workflow
Co-authored-by: Johannes Marbach <n0-0ne+github@mailbox.org>
Co-authored-by: Johannes Marbach <n0-0ne+github@mailbox.org>
richvdh
left a comment
richvdh
left a comment
There was a problem hiding this comment.
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)
| 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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
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)
|
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 |
mscbot
added
proposal-in-review
and removed
proposed-final-comment-period
turt2live
moved this from Ready for FCP ticks
to Ready for general review
in Spec Core Team Workflow
turt2live
removed
the
00-weekly-pings
turt2live
moved this from Ready for general review
to Tracking for review
in Spec Core Team Workflow
proposals/4354-sticky-events.md
Outdated
| Over Simplified Sliding Sync, Sticky Events have their own extension `sticky_events`, which has the following response shape: | ||
|
|
||
| ```js | ||
| { | ||
| "rooms": { | ||
| "!726s6s6q:example.com": { |
There was a problem hiding this comment.
Clarify which rooms show up here. All rooms or only rooms relevant to the lists/room_subscriptions
| - 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 |
There was a problem hiding this comment.
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?
reivilibre
force-pushed
the
kegan/persist-edu
branch
2 times, most recently
from
2183282 to
68581b7
Compare
reivilibre
force-pushed
the
kegan/persist-edu
branch
from
68581b7 to
331484d
Compare
17 participants
Rendered
SCT Stuff:
FCP tickyboxes
MSC checklist