MSC4279: Server notice rooms#4279
Conversation
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client
- Server
| to an implementation-specific definition of "administrators". When the server encounters the room | ||
| type over federation, the server SHOULD either strip the room type before serving the room to the | ||
| client, or refuse to participate. Stripping the room type prevents clients from getting confused | ||
| about how 'official' the notice is, though leads to subpar user experience. |
There was a problem hiding this comment.
What would be a use case for allowing server notice rooms to federate? So far, I had thought these notices to be local by nature. If that is the case we could just disallow them to federate entirely.
If we do have a use case for federating these rooms, why would a remote client not want to know that this is a server notice room? I think they could still differentiate the room from local notice rooms via the sender on m.room.create.
| enforced by the server. | ||
| 4. Clients SHOULD render the user's current Notice Rooms in a dedicated section of their UI rather | ||
| than part of a room list. | ||
| 5. Notice rooms SHOULD be created with suitable encryption enabled. |
There was a problem hiding this comment.
What does "suitable" mean here?
Co-authored-by: Johannes Marbach <n0-0ne+github@mailbox.org>
| 6. Servers SHOULD NOT allow notice rooms to be created without the use of the presets defined by this | ||
| proposal. This is to force developers to *really *think about whether they need to override the | ||
| default properties and change the behaviour of the room. They can still set things like `name`, | ||
| `power_level_content_override`, etc. |
There was a problem hiding this comment.
For clarity, this means servers SHOULD reject /createRoom requests with type = m.server_notice in creation_content unless preset is set to either notice or notice_readonly? But if one of the presets is set, clients can override all aspects of the preset via the parameters of /createRoom?
| 7. When a user leaves a notice room, the notice is considered "archived". Archived notices may be | ||
| [forgotten](https://spec.matrix.org/v1.13/client-server-api/#post_matrixclientv3roomsroomidforget) | ||
| to "delete" them. |
There was a problem hiding this comment.
I think this works the same way for any room type already?
There was a problem hiding this comment.
Seems to me like it's provisionary for making rooms forgotten on leave by default, ie. as per MSC #4267
| 8. If the client the user is leaving the notice room through doesn't support archived notices, the | ||
| client SHOULD automatically [forget](https://spec.matrix.org/v1.13/client-server-api/#post_matrixclientv3roomsroomidforget) | ||
| the room too. |
There was a problem hiding this comment.
Possibly outside the scope of this proposal: Would it be worthwhile to apply this to all room types?
| SHOULD NOT send typing notifications, either. | ||
| 12. With respect to read receipts, clients SHOULD NOT show read receipts for any other user than the | ||
| one that is logged in. Clients SHOULD send read receipts, if the user's settings permit it. | ||
| 13. Clients SHOULD disable slash commands and sending threaded messages in notice rooms. |
There was a problem hiding this comment.
The spec doesn't currently define slash commands which makes it a bid odd to prohibit them. I'm also not sure how these relate to threaded messages?
There was a problem hiding this comment.
Yeah, this seems like an odd requirement. Why would you not use threads when reporting abuse? And slash commands can do a lot of things like joining or switching rooms. That sounds rather odd as a requirement.
There was a problem hiding this comment.
This also sounds like a dangerous thing for accessibility. I can see 2 cases where this may be a problem:
- Clients where slash commands are the primary way to manage rooms (ie. gomuks-cli)
- Users who use slash commands as a replacement for UI elements (ie. vision-impaired users who may wish to use /part etc)
Co-authored-by: Johannes Marbach <n0-0ne+github@mailbox.org>
| Mentioned above, servers cannot allow a user to leave the room until the creator (or realistically, | ||
| anyone with suitable power level) allows it. To do this, the creator sends an `m.room.leave_rules` | ||
| state event with an empty string for a state key. This is a new event type. The `content` would be | ||
| very similar to the join rules event: | ||
|
|
||
| The `leave_rule` may be either `allow` or `deny`, and has a different default depending on the room | ||
| type. For `m.server_notice` rooms, the default is `deny`. For all other rooms, the default is `allow`. | ||
| The leave rule is *not *enforced by auth rules and therefore does not require a new room version. A | ||
| future MSC may change this. | ||
|
|
||
| Once the leave rule is set to `allow`, the user may be permitted to leave the room. |
There was a problem hiding this comment.
Since the alternatives section is blank: How does this compare to adding leave in m.room.power_levels?
| * The `is_direct` flag on [`/createRoom`](https://spec.matrix.org/v1.13/client-server-api/#post_matrixclientv3createroom) | ||
| defaults to `true`. |
There was a problem hiding this comment.
Is this actually needed given that clients are also encouraged to render these rooms outside the room list?
| though without federated trust. | ||
|
|
||
|
|
||
| ## Potential issues |
There was a problem hiding this comment.
This proposal is adding more complexity to /createRoom. I personally find this to be one of the most complicated endpoints in the spec already today due to the multitude of parameters and the different ways in which they interact or override each other.
| 1. As already mentioned, the server sends a regular room invite to the user, which looks a lot like | ||
| a phishing attempt. Users have no indication that they can trust that the invite is valid. | ||
| 2. Despite being an invite, Synapse's implementation doesn't allow the user to reject it. Users get | ||
| confusing/annoying error messages which build some trust in the invite, but erode trust in the | ||
| server/admin/protocol's ability to function. |
There was a problem hiding this comment.
Wouldn't it be better to just spec, that the server should autojoin the users? Why do we need invites for server notice rooms?
| A new `m.server_notice` [room type](https://spec.matrix.org/v1.13/client-server-api/#types) is | ||
| established, denoting a room as "Notice Room". Servers SHOULD limit creation of server notice rooms | ||
| to an implementation-specific definition of "administrators". When the server encounters the room | ||
| type over federation, the server SHOULD either strip the room type before serving the room to the | ||
| client, or refuse to participate. Stripping the room type prevents clients from getting confused | ||
| about how 'official' the notice is, though leads to subpar user experience. |
There was a problem hiding this comment.
Wouldn't it be better to keep the current tag mechanism? Tags can't be set by anyone but the server admin or the user. As such it is harder to abuse. Currently I can create a room with a server notice room type and invite users into it. As such there is no way for clients to trust the server, that the room is actually a server notice room, if we rely on the room type. Relying on the room type would require a rather long migration period.
The tag otoh could be manually set by an admin or the user itself, but that would only lead to the user or admin phishing the user, which would be possible anyway. What is the reason behind using a room type? It seems a lot less reliable at first glance.
4 participants
Rendered
Disclosure: I am Director of Standards Development at The Matrix.org Foundation C.I.C., Matrix Spec Core Team (SCT) member, employed by Element, and operate the t2bot.io service. This proposal is written and published as a Trust & Safety team member allocated in full to the Foundation.