Clarify that read markers are fully read markers
This commit is contained in:
parent
679ddabb53
commit
2e8151999e
1 changed files with 15 additions and 18 deletions
|
@ -12,42 +12,39 @@
|
|||
.. See the License for the specific language governing permissions and
|
||||
.. limitations under the License.
|
||||
|
||||
Read Markers
|
||||
============
|
||||
Fully read markers
|
||||
==================
|
||||
|
||||
.. _module:read-markers:
|
||||
|
||||
A "read marker" is a bookmark in the room's history where the user has last
|
||||
read a message. Read receipts cover the most recently read message, and have
|
||||
slightly different semantics where they are to be sent when the user has most
|
||||
likely seen the message, but not necessarily read it. A read marker tracks
|
||||
the user's last read message, therefore making the messages between the read
|
||||
marker and read receipt "potentially read" and messages before the read marker
|
||||
as "read". Messages after the read receipt should be considered as "unread",
|
||||
therefore the read marker should always be earlier or equal to the location of
|
||||
the read receipt.
|
||||
The history for a given room may be split into three sections: messages the
|
||||
user has read (or indicated they aren't interested in them), messages the user
|
||||
might have read some but not others, and messages the user hasn't seen yet.
|
||||
The "fully read marker" (also known as a "read marker") marks the last event
|
||||
of the first section, whereas the user's read receipt marks the last event of
|
||||
the second section.
|
||||
|
||||
Events
|
||||
------
|
||||
The user's read marker is kept as an event in the room's `account data`_. The
|
||||
event may be read to determine the user's current read marker location in the
|
||||
room, and just like other account data events the event will be pushed down
|
||||
The user's fully read marker is kept as an event in the room's `account data`_.
|
||||
The event may be read to determine the user's current fully read marker location
|
||||
in the room, and just like other account data events the event will be pushed down
|
||||
the event stream when updated.
|
||||
|
||||
The read marker is kept under an ``m.fully_read`` event. If the event does
|
||||
not exist on the user's account data, the read marker should be considered
|
||||
The fully read marker is kept under an ``m.fully_read`` event. If the event does
|
||||
not exist on the user's account data, the fully read marker should be considered
|
||||
to be the user's read receipt location.
|
||||
|
||||
{{m_fully_read_event}}
|
||||
|
||||
Client behaviour
|
||||
----------------
|
||||
The client cannot update read markers by directly modifying the ``m.fully_read``
|
||||
The client cannot update fully read markers by directly modifying the ``m.fully_read``
|
||||
account data event. Instead, the client must make use of the read markers API
|
||||
to change the values.
|
||||
|
||||
The read markers API can additionally update the user's read receipt (``m.read``)
|
||||
location in the same operation as setting the read marker location. This is
|
||||
location in the same operation as setting the fully read marker location. This is
|
||||
because read receipts and read markers are commonly updated at the same time,
|
||||
and therefore the client might wish to save an extra HTTP call. Providing an
|
||||
``m.read`` location performs the same task as a request to ``/receipts/m.read/$event:domain.com``.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue