MSC4489: Per-room contact state event#4489
Conversation
…contact_state_event.md renamed file
turt2live
changed the title
There was a problem hiding this comment.
Implementation requirements:
- Client (setting)
- Client (reading/using)
turt2live
added
proposal
turt2live
left a comment
turt2live
left a comment
There was a problem hiding this comment.
Early partial review of MSC
| state event — which is independently useful to existing members and to bots | ||
| that are in the room — is not blocked on federation/client changes. | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
Specifically for appeals, the Reporting v2 thought is currently #4468 fwiw
Co-authored-by: Travis Ralston <travpc@gmail.com>
| `""` as its state key; a room has at most one such event. It is ordinary room | ||
| state and requires no new room version. | ||
|
|
||
| Its `content` reuses the `contacts` and `support_page` fields, with the same |
There was a problem hiding this comment.
As a room admin, I would be worried about these values becoming stale and needing to roll out new values to all of my rooms whenever these change. I wonder about the potential merits of a "support_via": "matrix.org" field that would "redirect" users to the /.well-known/matrix/support of a given server name?
There was a problem hiding this comment.
i dont understand the issue. In that case you might wish to just populate the support_page and nothing else
| { | ||
| "matrix_id": "@alice:example.org", | ||
| "email_address": "security@example.org", | ||
| "role": "m.role.security" |
There was a problem hiding this comment.
What would a security contact on a room actually be responsible for?
There was a problem hiding this comment.
The examples were made based on the currently available options in the m.role.* namespace, they don't necessarily all have a real world use case today, though that doesnt mean there wont be someone finding a use for it eventually. This proposal also hopes to inspire new proposals to expand the options available to the m.role.* namespace like MSC4121 already does.
|
|
||
| ### Event definition | ||
|
|
||
| A new state event type `m.room.contact` is defined. It uses the empty string |
There was a problem hiding this comment.
Low temperature: Since this is meant to be complementary to .well-known/matrix/support, maybe it could be m.room.support to keep the terminology on par?
|
|
||
| The following constraints apply: | ||
|
|
||
| - At least one of `contacts` or `support_page` SHOULD be present. |
There was a problem hiding this comment.
This would allow sending the event with neither which feels slightly pointless. Maybe using the event itself is a MAY but if you use it, you MUST fill in either contacts or support_page. That would also match the rules for /.well-known/matrix/support.
There was a problem hiding this comment.
State events cannot be deleted, so if a room desires to no longer list contacts, an empty object is the best manner of doing so.
There was a problem hiding this comment.
Ah, true. Maybe this could be clarified in the proposal.
| [`/.well-known/matrix/support`](https://spec.matrix.org/latest/client-server-api/#getwell-knownmatrixsupport); | ||
| this proposal does not define its own roles. The set is open: consumers MUST | ||
| gracefully handle role values they do not recognise (for example, by displaying | ||
| the contact with no role label), and new `m.role.*` values defined by other |
There was a problem hiding this comment.
Maybe this should be generalised to unknown roles that follow the common namespaced identifier syntax (as in /.well-known/matrix/support). MSC implementations and custom roles won't use the m. prefix.
4 participants
Signed-off-by: Sky sky@codestorm.net
rendered