From d4ca80375cc2f2780f3a2980420638d94c293ff5 Mon Sep 17 00:00:00 2001 From: kegsay <7190048+kegsay@users.noreply.github.com> Date: Fri, 16 Feb 2024 09:54:15 +0000 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Benjamin Bouvier --- proposals/4103-threaded-read-receipt-sync-filter.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/4103-threaded-read-receipt-sync-filter.md b/proposals/4103-threaded-read-receipt-sync-filter.md index be21a3ea0..47358cc75 100644 --- a/proposals/4103-threaded-read-receipt-sync-filter.md +++ b/proposals/4103-threaded-read-receipt-sync-filter.md @@ -9,9 +9,9 @@ read receipts are interpreted as unthreaded ones. For instance, let's assume Alice is logged in on two clients: a desktop client which is thread aware, and a mobile client which is not. - * Alice has a bunch of unread msgs on her main timeline and a bunch of unread threads. + * Alice has a bunch of unread messages on her main timeline and a bunch of unread threads. * The threads are newer than the main timeline msgs. - * She reads a the most recently active thread on desktop, which sends a threaded RR. + * She reads the most recently active thread on desktop, which sends a threaded RR. * Mobile interprets this as a normal RR, and so marks the room as read (despite she hasn't read main timeline msgs) * Desktop however correctly shows the room as still unread. @@ -32,7 +32,7 @@ Another way of thinking of it which may or may not be helpful: ## Proposal -Non-threade-aware clients should only act on unthreaded RRs. +Non-thread-aware clients should only act on unthreaded RRs. Prior to this MSC, there is no way for non-thread-aware clients to determine which RRs are unthreaded, other than seeing if the `thread_id` field is missing on the RR or present and equal to `main`.