Skip to content
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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
86 changes: 86 additions & 0 deletions proposals/4036-room-organization-by-promoting-threads.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,86 @@
# MSC436: Room organization by promoting threads

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.

Copy link
Author

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.


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`.
Copy link

Choose a reason for hiding this comment

The 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
Copy link
Member

Choose a reason for hiding this comment

The 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 m.promote_threads. State keys are a different thing, they're used for having multiple events of the same 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
Copy link

Choose a reason for hiding this comment

The 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.

Copy link
Author

Choose a reason for hiding this comment

The 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?
A possible concern is that as of now, many clients (and homeserver implementations?) still do not support threads, reducing the usefulness of rooms of such type.


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)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[MSC3088: room-subtyping](https://github.com/matrix-org/matrix-spec-proposals/blob/travis/msc/mutable-subtypes/proposals/3088-room-subtyping.md)
[MSC3088: room-subtyping](https://github.com/matrix-org/matrix-spec-proposals/pull/3088)

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Identifiers like this should be lowercase

Suggested change
the unstable `dev.coffeeco.MSC4036.promote_threads` shall be used.
the unstable `dev.coffeeco.msc4036.promote_threads` shall be used.

(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.