1f349/dendrite
4
0
Fork 0
mirror of https://github.com/1f349/dendrite.git synced 2024-12-27 18:46:29 +00:00
Code Issues Packages Projects Releases Wiki Activity
135b5e264f
dendrite/docs/peeking.md
Matthew Hodgson 39507bacc3
Peeking via MSC2753 (#1370) 
Initial implementation of MSC2753, as tested by https://github.com/matrix-org/sytest/pull/944.
Doesn't yet handle unpeeks, peeked EDUs, or history viz changing during a peek - these will follow.
https://github.com/matrix-org/dendrite/pull/1370 has full details.
2020-09-10 14:39:18 +01:00

1.5 KiB
Raw Blame History

Peeking

Peeking is implemented as per MSC2753.

Implementationwise, this means:

  • Users call /peek and /unpeek on the clientapi from a given device.
  • The clientapi delegates these via HTTP to the roomserver, which coordinates peeking in general for a given room
  • The roomserver writes an NewPeek event into the kafka log headed to the syncserver
  • The syncserver tracks the existence of the local peek in its DB, and then starts waking up the peeking devices for the room in question, putting it in the peek section of the /sync response.

Questions (given this is my first time hacking on Dendrite):

  • The whole clientapi -> roomserver -> syncapi flow to initiate a peek seems very indirect. Is there a reason not to just let syncapi itself host the implementation of /peek?

In future, peeking over federation will be added as per MSC2444.

  • The roomserver will kick the federationsender much as it does for a federated /join in order to trigger a federated /peek
  • The federationsender tracks the existence of the remote peek in question
  • The federationsender regularly renews the remote peek as long as there are still peeking devices syncing for it.
  • TBD: how do we tell if there are no devices currently syncing for a given peeked room? The syncserver needs to tell the roomserver somehow who then needs to warn the federationsender.