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

MSC3464: Allow Users to Post on Behalf of Other Users #3464

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

sumnerevans
Copy link
Contributor

@sumnerevans sumnerevans commented Oct 29, 2021

Rendered

Signed-off-by: Sumner Evans me@sumnerevans.com

@turt2live turt2live changed the title MSC3462: Allow Users to Post on Behalf of Other Users MSC3464: Allow Users to Post on Behalf of Other Users Oct 29, 2021
Signed-off-by: Sumner Evans <me@sumnerevans.com>
@turt2live turt2live added kind:feature MSC for not-core and not-maintenance stuff proposal A matrix spec change proposal labels Oct 29, 2021
@turt2live turt2live added the client-server Client-Server API label Oct 29, 2021
@sumnerevans sumnerevans marked this pull request as ready for review October 29, 2021 15:57
Comment on lines +59 to +61
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.
Copy link
Contributor

Choose a reason for hiding this comment

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

Wouldn't all users be denied by default? and shouldn't then this only be an array showing who is explicitly allowed?

Copy link
Contributor Author

@sumnerevans sumnerevans Oct 29, 2021

Choose a reason for hiding this comment

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

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)

Comment on lines +94 to +97
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.
Copy link
Contributor

Choose a reason for hiding this comment

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

Related to my first comment, this can become a spam vector of sorts, i believe.

proposals/3464-allow-users-to-post-on-behalf-of-users.md Outdated Show resolved Hide resolved
@@ -0,0 +1,189 @@
# MSC3464: Allow Users to Post on Behalf of Other Users
Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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
Copy link
Contributor

@aWeinzierl aWeinzierl Nov 5, 2021

Choose a reason for hiding this comment

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

What about truly authorizing someone to use your account for specific actions, similar to Authorizing OAuth Apps at GitHub?

Copy link
Contributor

@Half-Shot Half-Shot Nov 22, 2021

Choose a reason for hiding this comment

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

+1 Moving matrix to OAuth is planned in another MSC, and having that would make something like this entirely organic.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client-server Client-Server API kind:feature MSC for not-core and not-maintenance stuff proposal A matrix spec change proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants