MSC3394: New auth rule that only allows someone to post a message in relation to another message #3394
Conversation
frandavid100
changed the title
| @@ -0,0 +1,19 @@ | |||
| # Example: new auth rule that only allows someone to post a message in relation to another message | |||
There was a problem hiding this comment.
| # Example: new auth rule that only allows someone to post a message in relation to another message | |
| # New auth rule that only allows someone to post a message in relation to another message |
|
|
||
| Matrix rooms can be used to a similar effect, if permissions are set so that regular users can't post any messages. Subscribers are fine with this most of the time, because they're usually more interested in reading new content by the room's owner than in replying to that content, or in reading what other subscribers have to say. | ||
|
|
||
| But some times they may want to give feedback, or read other people's opinions; and that can't be done today because, by definition, this kind of room prevents any type of conversation. |
There was a problem hiding this comment.
| But some times they may want to give feedback, or read other people's opinions; and that can't be done today because, by definition, this kind of room prevents any type of conversation. | |
| But sometimes they may want to give feedback, or read other people's opinions; and that can't be done today because, by definition, this kind of room prevents any type of conversation. |
|
Also, please wrap your lines after ~120 characters |
…in-relation-to-another-message.md
|
This will 100% need sign off so il just point that out. |
anoadragon453
added
client-server
|
MSCs need to spell out the details for how they will achieve their goals. e.g. in this case, what property is used in what state event to indicate who is allowed to post replies, how you determine what's top-level vs. a reply, etc. I'm going to mark this as a draft for now. |
|
Related (re: threads-as-rooms): element-hq/element-web#2349 (comment) |
turt2live
added
requires-room-version
…in-relation-to-another-message.md
…in-relation-to-another-message.md to 3394-new-auth-rule-that-only-allows-someone-to-post-a-message-in-relation-to-another-message.md
|
|
||
| Today, chat platforms are used broadly in order to broadcast information to large audiences. An example of this are [Telegram channels](https://telegram.org/tour/channels/). | ||
|
|
||
| Matrix rooms can be used to a similar effect, if permissions are set so that regular users can't post any messages. Subscribers are fine with this most of the time, because they're usually more interested in reading new content by the room's owner than in replying to that content, or in reading what other subscribers have to say. |
There was a problem hiding this comment.
please could you wrap your lines at about 80 characters, to make it easier to read and comment on them?
There was a problem hiding this comment.
Sure, I'll do that as soon as I get home.
|
|
||
| I propose a new auth rule that only allows room members to post a message if it's in relation to another message. | ||
|
|
||
| This will mean that regular users can't post top-level messages, but they can start threads and reply to them; this will allow for conversation inside the room while keeping the room clean for subscribers who just want the news; because the main timeline will only contain posts by the room's owner, and all the conversations will take place within threads. |
There was a problem hiding this comment.
please could you spell this out more precisely? What exactly does "starting a thread" mean here?
Compare with the existing auth rules (https://spec.matrix.org/latest/rooms/v7/#authorization-rules), which are very explicit.
There was a problem hiding this comment.
Sorry, I'm quite new to this. I assume this is the rule that decides if a user can send a message to the room?
"If the event type’s required power level is greater than the sender’s power level, reject."
There was a problem hiding this comment.
Hi, Rich. I just added the following to the MSC:
Based on existing auth rules, the new auth rule I'm proposing could probably look like this:
If type is m.room.message:
If the user's power level is higher than the power level for m.room.message events, allow.
Otherwise, check the new power level I want to introduce. If it's is higher than the user's power level, reject.
Otherwise, if the event doesn't have a relation, reject.
Otherwise, allow.As an example, let's say I want to set up my room so that only moderators can post top-level messages, but regular users can comment those messages inside a thread. I will set a power level of 50 for the "send messages" permission, and a power level of 0 for the new "send messages to threads" permission.
When a user tries to send a message:
If they are a moderator (PL of 50) they are allowed.
Otherwise, if they are a regular user (PL of 0) and the message is inside a thread (it has a relation) they are allowed.
Otherwise, they're not allowed.
I would like some feedback on it, and maybe a couple suggestions if you think it needs further improvements.
There was a problem hiding this comment.
As I said: sorry, I'm not able to devote any time to supporting you here, but I wish you luck! ❤️
There was a problem hiding this comment.
Thanks anyway for pointing me in the right direction.
|
|
||
| It may also be useful for additional purposes: for example a [client focused on social networking](https://matrix.org/blog/2020/12/18/introducing-cerulean) could use a room to store a user's posts, which could then be followed by other users; or a [matrix-based comment system](https://cactus.chat/) could show every post on a webpage in the same room, with all the discussions happening inside threads. | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
Changing the auth rules is a complex process (notably, it requires a new room version). Have you considered a softer solution whereby messages are blocked at the C-S API rather than at the room DAG level? (So it would still be possible for users to send messages via a non-compliant server, but you might be able to handle that with other moderator controls)
There was a problem hiding this comment.
I hadn't considered that option, and I have to admit that my knowledge of the spec is so shallow that it's hard for me to grasp the implications of using an approach instead of the other. Would there be any important advantages, besides not having to wait until a new room version is introduced?
There was a problem hiding this comment.
I believe the only advantage would be not having to wait for a new room version and requiring rooms to be upgraded to it - but it's a fairly substantial one.
The downside is, as said, users could still post top-level messages. It's just that most users' homeservers would prevent them from doing so.
There was a problem hiding this comment.
I don't think I know enough to adequately evaluate this alternative, but "users could still post top-level messages" sounds like an important drawback to me.
…in-relation-to-another-message.md
…in-relation-to-another-message.md
| @@ -0,0 +1,56 @@ | |||
| # MSC3394: new auth rule that only allows someone to post a message in relation to another message | |||
There was a problem hiding this comment.
I think before this can go back into review, you'll need to pick a (threading) MSC to build on top of, then update the proposed event auth changes with the exact details related to that MSC.
At the moment, the proposal contains phrases such as "top-level messages" and "inside a thread", but what these mean exactly need to be defined. For example, if you picked MSC3440, you could say that "a message inside a thread is defined as an m.room.message event containing an m.relates_to field with a relation type of m.thread.
Once that's all done, feel free to mark it ready for review. Otherwise it likely won't get another review until this PR comes out of draft state.
There was a problem hiding this comment.
Hi, I added the following text to the proposal:
In the context of this proposal, and based on MSC3440, a "message inside a thread" is defined as an m.room.message event containing an m.relates_to field with a relation type of m.thread and a "top-level message" is defined as an m.room.message event NOT containing such a field.
Is that enough? Thanks for your help.
There was a problem hiding this comment.
That's a great start! I would also define a name for your new m.room.power_levels field, rather than referring to it in the abstract. And note that once you do, you'll need to come up with an unstable prefixed version of it that unstable implementations can use before this MSC is merged.
See here for an example.
There was a problem hiding this comment.
Thanks again, Andrew.
What are the names of existing m.room.power_levels fields? Maybe if I could see some of them, I could define a proper name for the new one.
As for the unstable prefixed version, I have to admit that I know just enough to get the gist of that MSC after a couple reads, but not enough to use it as a model. This is a bit embarrasing, but I would need some more help.
…in-relation-to-another-message.md
| but not others) but it would also probably be more expensive.MSC3393: new auth rule that | ||
| only allows someone to post a message in relation to another messageMSC3393: new auth rule | ||
| that only allows someone to post a message in relation to another message. |
There was a problem hiding this comment.
I would also clean up these duplicated lines here.
There was a problem hiding this comment.
Thanks, I have no idea how those got in there :-(
|
|
||
| It may also be useful for additional purposes: for example a [client focused on social networking](https://matrix.org/blog/2020/12/18/introducing-cerulean) could use a room to store a user's posts, which could then be followed by other users; or a [matrix-based comment system](https://cactus.chat/) could show every post on a webpage in the same room, with all the discussions happening inside threads. | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
I believe the only advantage would be not having to wait for a new room version and requiring rooms to be upgraded to it - but it's a fairly substantial one.
The downside is, as said, users could still post top-level messages. It's just that most users' homeservers would prevent them from doing so.
|
|
||
| 1. If type is m.room.message: | ||
| 1. If the user's power level is higher than the power level for m.room.message events, allow. | ||
| 2. Otherwise, check the new power level I want to introduce. If it's is higher than the user's power level, reject. |
There was a problem hiding this comment.
| 2. Otherwise, check the new power level I want to introduce. If it's is higher than the user's power level, reject. | |
| 2. Otherwise, check the new power level I want to introduce. If it is higher than the user's power level, reject. |
| @@ -0,0 +1,56 @@ | |||
| # MSC3394: new auth rule that only allows someone to post a message in relation to another message | |||
There was a problem hiding this comment.
That's a great start! I would also define a name for your new m.room.power_levels field, rather than referring to it in the abstract. And note that once you do, you'll need to come up with an unstable prefixed version of it that unstable implementations can use before this MSC is merged.
See here for an example.
…in-relation-to-another-message.md
…in-relation-to-another-message.md
Rendered