MSC3464: Allow Users to Post on Behalf of Other Users #3464
Conversation
turt2live
changed the title
Signed-off-by: Sumner Evans <me@sumnerevans.com>
turt2live
added
kind:feature
sumnerevans
force-pushed
the
post-on-behalf-of
branch
from
2a797f3
to
a2feb65
Compare
| The content of the state event MUST have two fields (`allow` and `deny`; both | ||
| lists MUST be a list of MXIDs) indicating which MXIDs are allowed or denied the | ||
| ability to be rendered as posting on the users behalf. |
There was a problem hiding this comment.
Wouldn't all users be denied by default? and shouldn't then this only be an array showing who is explicitly allowed?
There was a problem hiding this comment.
Yes, but the idea is that you can also explicitly deny certain accounts the ability to post on your behalf. But, to your point below, maybe it is better to make users explicitly go in and give users permission to post on their behalf, and not prompt them to allow/deny that ability.
There are some UX challenges with that, though. In the example of the standupbot, I'm trying to think a users first-time interaction with the bot:
- use DM with bot to create standup post
- bot posts in standup room for you
- user now has to go and find the standupbot in the standup room, and allow it to post on their behalf (yes, this can be smoothed over by some instructions from the bot in the DM room, but not ideal)
| When a user (Bob) sends a message on behalf of another user (Alice), and there | ||
| is no entry for Bob in Alice's allow/deny lists, then the client MUST prompt | ||
| Alice to confirm whether she wants Bob to be able to post on her behalf in the | ||
| room. |
There was a problem hiding this comment.
Related to my first comment, this can become a spam vector of sorts, i believe.
| @@ -0,0 +1,189 @@ | |||
| # MSC3464: Allow Users to Post on Behalf of Other Users | |||
There was a problem hiding this comment.
This is similar to what is requested in https://github.com/matrix-org/matrix-doc/issues/3222, but doesn't really solve it since it requires the target user to confirm permissions for relaying (which of course implies that the target user is a real user, which AIUI is not the case in that issue). It might be interesting to see if this mechanism can be adapted to also solve that issue too.
There was a problem hiding this comment.
I considered making the list of users allowed to post on others' behalf a per-room thing. But I thought it would probably put too much power in the hands of admins. Also, under my proposal, only users who are in the room could be posted on behalf of, so that would have to be changed as well.
One scenario that I was thinking about with both of these issues is if some admin could post on behalf of another user that isn't even in the room, they could make it look like the other person said something they didn't say.
Clarified that clients must display the message as from the sender if the sender is in the user's deny list (even if the sender is in the allow list as well). Clarified the text to be a lot more readable.
|
|
||
| ## Potential issues | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
What about truly authorizing someone to use your account for specific actions, similar to Authorizing OAuth Apps at GitHub?
There was a problem hiding this comment.
+1 Moving matrix to OAuth is planned in another MSC, and having that would make something like this entirely organic.
There was a problem hiding this comment.
Should I just wait for OAuth to get merged? It doesn't seem like that's a high priority, so I feel like it would delay this functionality significantly.
|
The obligatory mention of RELAYMSG matrix-org/matrix-spec#840 |
|
Closing in favor of #4144 |
turt2live
added
abandoned
Rendered
Signed-off-by: Sumner Evans me@sumnerevans.com