From 15a7312273a11deb825e1661aa7ca464b704038d Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Tue, 2 Sep 2014 09:34:28 +0100 Subject: [PATCH] Added section on banning users, currently in flux as the API changes / is implemented. --- docs/specification.rst | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/docs/specification.rst b/docs/specification.rst index f039d90d7..adf5bc721 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -391,6 +391,32 @@ If all members in a room leave, that room becomes eligible for deletion. - TODO: Grace period before deletion? - TODO: Under what conditions should a room NOT be purged? +Banning users in a room +----------------------- +- TODO : Needs impl! +- TODO : How do we expose the ban list? A room state event? How do we handle + racing with updating the list? Scoped state_key to user? + E.g. /state/m.room.member.banlist/@user:domain { reason: foo } +- TODO: Any safeguards to prevent everyone banning everyone and locking out the + room? Or relying on decaying nature of power levels? +- Should the membership enum be "kick" instead and then use the banlist as "you've + actually been banned."? + +A user may decide to ban another user in a room. 'Banning' forces the target user +to leave the room and prevents them from re-joining the room. In order to ban +someone, the user performing the ban MUST have the required power level. To ban +a user, a request should be made to ``/rooms//ban`` with:: + + { + "user_id": "" + } + +Banning a user adjusts the banned member's membership state and adds their user ID to +a ban list. The ban list state event is stored at TODO and looks like TODO. Like with +other membership changes, a user can directly adjust the target member's state, but +unless their name is added to the ban list, they will be able to re-join the room. + Events in a room ---------------- Room events can be split into two categories: