From e4339fd68755344527cce85895ac131ee8618e6e Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Fri, 7 Jun 2019 09:01:14 -0600 Subject: [PATCH] More clarity --- specification/client_server_api.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/specification/client_server_api.rst b/specification/client_server_api.rst index 5290ec200..c62740d47 100644 --- a/specification/client_server_api.rst +++ b/specification/client_server_api.rst @@ -1276,12 +1276,12 @@ effort to reduce the number of resources used, clients can enable "lazy-loading" for room members. By doing this, servers will only ever send membership events which are relevant to the client. -In terms of filters, this means enabling ``lazy_load_members`` on a ``StateFilter`` -or ``RoomEventFilter``. When enabled, lazy-loading aware endpoints (see below) -will only include membership events for the ``sender`` of events being included -in the response. For example, if a client makes a ``/sync`` request with lazy-loading -enabled, the server will only return membership events for the ``sender`` of events -in the timeline, not all members of a room. +In terms of filters, this means enabling ``lazy_load_members`` on a ``RoomEventFilter`` +(or a ``StateFilter`` in the case of ``/sync`` only). When enabled, lazy-loading +aware endpoints (see below) will only include membership events for the ``sender`` +of events being included in the response. For example, if a client makes a ``/sync`` +request with lazy-loading enabled, the server will only return membership events +for the ``sender`` of events in the timeline, not all members of a room. Repeated calls to lazy-loading aware endpoints will result in redundant membership events being excluded by default. Clients often track which membership events they