mirror of
https://mau.dev/maunium/synapse.git
synced 2024-12-13 21:53:49 +01:00
Add more information to TODOs. Explain m.room.join_rules.
This commit is contained in:
parent
1aa5cc9178
commit
7e1437c6b1
1 changed files with 21 additions and 12 deletions
|
@ -847,9 +847,8 @@ defined in the following state events:
|
|||
|
||||
Joining rooms
|
||||
-------------
|
||||
.. TODO-doc kegan
|
||||
- TODO: What does the home server have to do to join a user to a room?
|
||||
See SPEC-30.
|
||||
.. TODO-doc What does the home server have to do to join a user to a room?
|
||||
- See SPEC-30.
|
||||
|
||||
Users need to join a room in order to send and receive events in that room. A
|
||||
user can join a room by making a request to |/join/<room_alias_or_id>|_ with::
|
||||
|
@ -886,20 +885,21 @@ received an invite.
|
|||
|
||||
Inviting users
|
||||
--------------
|
||||
.. TODO-doc kegan
|
||||
- Can invite users to a room if the room config key TODO is set to TODO. Must have required power level.
|
||||
.. TODO-doc Invite-join dance
|
||||
- Outline invite join dance. What is it? Why is it required? How does it work?
|
||||
- What does the home server have to do?
|
||||
- TODO: In what circumstances will direct member editing NOT be equivalent to ``/invite``?
|
||||
|
||||
The purpose of inviting users to a room is to notify them that the room exists
|
||||
so they can choose to become a member of that room. Some rooms require that all
|
||||
users who join a room are previously invited to it (an "invite-only" room).
|
||||
Whether a given room is an "invite-only" room is determined by the room config
|
||||
key ``TODO``. It can have one of the following values:
|
||||
key ``m.room.join_rules``. It can have one of the following values:
|
||||
|
||||
- TODO Room config invite only value explanation
|
||||
- TODO Room config free-to-join value explanation
|
||||
``public``
|
||||
This room is free for anyone to join without an invite.
|
||||
|
||||
``invite``
|
||||
This room can only be joined if you were invited.
|
||||
|
||||
Only users who have a membership state of ``join`` in a room can invite new
|
||||
users to said room. The person being invited must not be in the ``join`` state
|
||||
|
@ -924,9 +924,14 @@ See the `Room events`_ section for more information on ``m.room.member``.
|
|||
|
||||
Leaving rooms
|
||||
-------------
|
||||
.. TODO-spec kegan
|
||||
- TODO: Grace period before deletion?
|
||||
- TODO: Under what conditions should a room NOT be purged?
|
||||
.. TODO-spec - HS deleting rooms they are no longer a part of. Not implemented.
|
||||
- This is actually Very Tricky. If all clients a HS is serving leave a room,
|
||||
the HS will no longer get any new events for that room, because the servers
|
||||
who get the events are determined on the *membership list*. There should
|
||||
probably be a way for a HS to lurk on a room even if there are 0 of their
|
||||
members in the room.
|
||||
- Grace period before deletion?
|
||||
- Under what conditions should a room NOT be purged?
|
||||
|
||||
|
||||
A user can leave a room to stop receiving events for that room. A user must
|
||||
|
@ -1078,6 +1083,10 @@ presence events will also be returned. There are two APIs provided:
|
|||
.. TODO-doc kegan
|
||||
- TODO: JSON response format for both types
|
||||
- TODO: when would you use global? when would you use scoped?
|
||||
- Room-scoped initial sync is Very Tricky because typically people would
|
||||
want to sync the room then listen for any new content from that point
|
||||
onwards. The event stream cannot do this for a single room currently.
|
||||
Not sure if room-scoped initial sync should be included at this time.
|
||||
|
||||
Getting events for a room
|
||||
-------------------------
|
||||
|
|
Loading…
Reference in a new issue