MSC4264: Tokens for Contacting Accounts or Joining Semi-Public Rooms

[thomasfiala]

Tokens for Contacting Accounts
about: A proposal to implement tokens that can or must be set when contacting another user to prevent spam.

Rendered

I have no affiliation with Matrix or any of its clients and created the proposal out of self-motivation.

Pull Request Checklist

• Pull request includes a sign off Signed-off-by: Thomas Fiala
• Update the title and file name of your proposal to match this PR's number (after opening).
• Pull request includes a 'Rendered' link above.
• Have a look at the MSC Checklist for guidelines on various aspects of your MSC.

[turt2live]

Implementation requirements:

• Client
• Server
• Complement tests

[spaetz]

Hi there, great ideas. Given that direct chats are noting but specific rooms, I am wondering if this MSC should not be more generic in the sense that e.g. "allowing tokens to enter a room" could solve this issue just as well and provide a more generic solution.
Let's say I have a matrix room for a University course that I teach, I could provide a "token" (essentially a password) to those students enrolled in my course. (or think zoom session passwords). It would be more liberal than invitations, but less open than "public". Is this MSC really only useful for contacting individuals?

[thomasfiala]

Hi there, great ideas. Given that direct chats are noting but specific rooms, I am wondering if this MSC should not be more generic in the sense that e.g. "allowing tokens to enter a room" could solve this issue just as well and provide a more generic solution. Let's say I have a matrix room for a University course that I teach, I could provide a "token" (essentially a password) to those students enrolled in my course. (or think zoom session passwords). It would be more liberal than invitations, but less open than "public". Is this MSC really only useful for contacting individuals?

Thank you @spaetz. I implemented your proposal into the text. Accordingly, I also updated the title. I hope that it's not confusing, though. Any idea to rephrase it is highly welcome. Possibly the idea to establish semi-public rooms is more generic and requires a separate proposal?

[turt2live]

Overall: Based on #4192, I feel as though this MSC would be best positioned as an extension to #4155 rather than being a dedicated mechanism (for the parts that aren't already covered).

[turt2live]

ie: something like allow_tokens or similar, potentially spinning the joins part out to its own MSC.

[thomasfiala]

Yes, you can definitively see it this way. I'm open to grouping/organizing this MSC in any way that makes more sense.
Just one thing to keep in mind: #4155 currently appears to be a more or less "standard" whitelist/blacklist feature. The concept of "tokens" and, subsequently, the meas of managing and displaying them, might possibly create confusion if being mixed up with #4155.