MSC4036: Room organization by promoting threads #4036
Conversation
C0ffeeCode
changed the title
turt2live
added
proposal
|
@C0ffeeCode please sign off on your changes so it is eligible for acceptance later in the process. |
| @@ -0,0 +1,86 @@ | |||
| # MSC436: Room organization by promoting threads | |||
There was a problem hiding this comment.
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.
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.
Private sign off has been recieved. |
C0ffeeCode
force-pushed
the
room-organization-by-promoting-threads
branch
from
d3339b9
to
1f0c1c4
Compare
C0ffeeCode
force-pushed
the
room-organization-by-promoting-threads
branch
from
1f0c1c4
to
cb34d5f
Compare
| 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`. | ||
|
|
||
| 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. |
There was a problem hiding this comment.
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.
| ## 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.
Identifiers like this should be lowercase
| 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)
| 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.
| [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) |
|
|
||
| ## 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.
This sounds more like a use case for msc3088 (room subtyping) than making a new state event.
| 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.
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.
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.
Rendered
This MSC proposes standardization of a room state key to request clients to promote threads
for the purpose of organizing room discussions using threads.