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

Support rejecting invites with a reason #1416

Closed
turt2live opened this issue Jul 13, 2018 · 4 comments
Closed

Support rejecting invites with a reason #1416

turt2live opened this issue Jul 13, 2018 · 4 comments
Labels
client-server Client-Server API improvement A suggestion for a relatively simple improvement to the protocol

Comments

@turt2live
Copy link
Member

Proposal: Tell clients that they can reject an invite with an optional reason on the m.room.member. Copying from kicks/bans.

Use case: A user may wish to reject an invite to say "no, I don't want to talk to you". The homeserver may also be able to enhance the ignored users stuff by auto-rejecting with "This user has ignored you" or something. Another use case would be potentially a bridge/appservice/bot refusing to participate in a room due to some condition.

@turt2live turt2live added the improvement A suggestion for a relatively simple improvement to the protocol label Jul 13, 2018
@turt2live turt2live added the client-server Client-Server API label Sep 6, 2018
@erikjohnston
Copy link
Member

MSC2367 allows adding reasons to rejecting invites, amongst other things.

@aaronraimist
Copy link
Contributor

The homeserver may also be able to enhance the ignored users stuff by auto-rejecting with "This user has ignored you" or something.

I don't want a user to be able to tell that I ignored them so hopefully this would be optional

@turt2live
Copy link
Member Author

I would hope it is optional.

@Half-Shot
Copy link
Contributor

Can this be closed now that MSC2367 is merged?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client-server Client-Server API improvement A suggestion for a relatively simple improvement to the protocol
Projects
None yet
Development

No branches or pull requests

4 participants