-
Notifications
You must be signed in to change notification settings - Fork 385
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC4036: Room organization by promoting threads #4036
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -0,0 +1,86 @@ | ||||||
# MSC436: Room organization by promoting threads | ||||||
|
||||||
Sometimes, having a discussion in a busy room can be difficult. | ||||||
People are often simply replying with a message event which is technically not related (`m.relates_to`) using replies (`m.in_reply_to`) or threads (`m.thread`) with the previous messages of the conversation making separation of one conversation from others difficult. | ||||||
C0ffeeCode marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
||||||
The functionality of threads is often unused, | ||||||
considerably because simply typing in a reply is just simpler/faster and the lack of support by clients although a fallback mechanism exists. | ||||||
|
||||||
This MSC solely proposes client-side behavior. | ||||||
|
||||||
## Proposal | ||||||
|
||||||
Standardize a room state `m.promote_threads` (`dev.coffeeco.MSC4036.promote_threads` for non-finalized implementations of this MSC) with a Boolean value or an object, defaulting to `false`. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This sounds more like a use case for msc3088 (room subtyping) than making a new state event. |
||||||
|
||||||
The value SHOULD NOT be set to an object | ||||||
but clients MUST consider an object as implicating a value of `true` (possibly with additional behavior changes) | ||||||
for the purpose of forwards compatibility. | ||||||
Comment on lines
+13
to
+17
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Event content must be an object. Even if it didn't have to be, varying types like this are not nice for statically typed languages, and should usually be avoided. Also, the MSC doesn't explicitly say what it's proposing. This section talks about "a room state" and the unstable prefix says "state key", which is not the same as an event type. You should probably use "room state event" and "event type" respectively, assuming you're proposing a new state event with type |
||||||
|
||||||
If set to `false` or unset, | ||||||
clients behavior MAY NOT alter their behavior. | ||||||
|
||||||
If set to `true` or some object, | ||||||
clients should alter their user experience to guide the user to reply using threads with the following proposed changes: | ||||||
|
||||||
- On messages without a relation (`m.relates_to`), | ||||||
functionality to reply in a thread may be promoted, | ||||||
e.g. by displaying an enlarged button, | ||||||
making it more accessible than the `m.in_reply_to` functionality. | ||||||
|
||||||
- In the scope of the room, outside of a thread, | ||||||
clients may chose to minimize the message input functionality | ||||||
or hide it behind a button (e.g. "Start new conversation") | ||||||
to indicate that a room prefers replies in threads. | ||||||
|
||||||
- For messages which are others are related to in a `m.thread`-relation, | ||||||
clients may choose to show a selection of the messages related to that message as a preview. | ||||||
|
||||||
## Potential issues | ||||||
|
||||||
This MSC may be considered to have a too specific way how clients work and behave in mind. | ||||||
Hence, this MSC only proposes behavior. | ||||||
|
||||||
A potential issue may be that clients without support for threads or not following the proposed behavior will continue to reply as before, | ||||||
which may cause conversations in threads (as promoted by this MSC) to disappear faster due to new messages and replies of conversations not using threads. | ||||||
This may create difficulties with translations. | ||||||
|
||||||
Also, it may be considered to add the possibility to select specific behavior changes specified above. | ||||||
However, this might cause a too broad variation of the user interface, making it harder to understand and less predictable. | ||||||
|
||||||
## Alternatives | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Stumbled across this again, I think it would be a good idea to turn this from "promote threads" to "thread only rooms", and introduce a new room type. A big problem in rooms is when some clients support threads and some don't. Having a separate room type would be semantically better and could cause clients that don't support threads to not show thread-only rooms in the ui. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So the thought is to specify clients not supporting threads not to show the room? |
||||||
|
||||||
Instead of `m.promote_threads` being a value of `true` or `false`, | ||||||
it may be considerable that the value also may be an object. | ||||||
If the value is an object, it must be treated equally with a value of `true` with the following additions: | ||||||
The object may contain a strings, | ||||||
for example to specify the label of the button to access the message input box outside the scope of a thread | ||||||
(e.g. "Ask a new question", "Open a new issue"). | ||||||
|
||||||
[MSC3088: room-subtyping](https://github.com/matrix-org/matrix-spec-proposals/blob/travis/msc/mutable-subtypes/proposals/3088-room-subtyping.md) | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
proposes specification for room purposes, | ||||||
e.g. data-driven spaces or DM rooms. | ||||||
The proposed behavior of this MSC could be applied to a further room purpose, a `m.discussions` (or `dev.coffeeco.MSC4036.discussions`). | ||||||
E.g. like: | ||||||
```json | ||||||
{ | ||||||
"type": "m.room.purpose", | ||||||
"state_key": "m.discussions", | ||||||
"content": { | ||||||
"m.promote_threads": true | ||||||
} | ||||||
} | ||||||
``` | ||||||
|
||||||
## Security considerations | ||||||
|
||||||
Not applicable | ||||||
|
||||||
## Unstable prefix | ||||||
|
||||||
For the proposed `m.promote_threads` state key, | ||||||
the unstable `dev.coffeeco.MSC4036.promote_threads` shall be used. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Identifiers like this should be lowercase
Suggested change
(needs to be fixed in a few other places in the MSC too, but you could also just remove them: mentioning unstable prefixes in the main MSC text is not necessary) |
||||||
|
||||||
## Dependencies | ||||||
|
||||||
Potentially [MSC3088: room-subtyping](https://github.com/matrix-org/matrix-spec-proposals/blob/travis/msc/mutable-subtypes/proposals/3088-room-subtyping.md), | ||||||
if seen as an extension of it as depicted in the alternatives section. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a good addition to this would be a power level rule regulating who can post messages in the main thread. The use case would be an announcement kind of room where regular users would only be allowed to comment in threads to reduce noise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great idea.
But I think it would make more sense to propose it in a separate MSC as the ideas do not depend on each other.