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

MSC3288: Add room type to /_matrix/identity/v2/store-invite API #3288

Merged
69 changes: 69 additions & 0 deletions proposals/3288-pass_room_type_in_3pid_invite.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
# MSC3288: Add room type to `/_matrix/identity/v2/store-invite` API

Currently when inviting via 3pid, the Identity Server receives some information about the room,
like for example the room name and avatar as well as the inviter name.
This allows the identity server to generate a rich email to the invitee.

Now that the matrix spec supports spaces, it would be nice to also provide this information to the identity server
so that the email invite could be customized for spaces. The current implementation would say wrongly that
you are invited to a room when the room is actually a space.

The goal of this proposal is to make 3pid invites space aware.


## Proposal

Homeservers should also send the `room_type` to the identity server when performing a third party invite (__Invitation storage__).


__Proposed change:__

Add a new `room_type` field in json body of [`POST /_matrix/identity/v2/store-invite`](https://matrix.org/docs/spec/identity_service/r0.3.0#post-matrix-identity-v2-store-invite):

| Parameter | Type | Description |
|--|--|--|
| room_type | string | The room type for the room to which the user is invited. This should be retrieved from the value of `type` in the `m.room.create` event's `content`. Do not include parameter if `type` is not present in `m.room.create`.

````
POST /_matrix/identity/v2/store-invite HTTP/1.1
Content-Type: application/json

{
"medium": "email",
"address": "foo@example.com",
"room_id": "!something:example.org",
"sender": "@bob:example.com",
"room_alias": "#somewhere:exmaple.org",
"room_avatar_url": "mxc://example.org/s0meM3dia",
"room_join_rules": "public",
"room_name": "The Bob Project",
"room_type": "m.space",
"sender_display_name": "Bob Smith",
"sender_avatar_url": "mxc://example.org/an0th3rM3dia"
}
````

The identity server could then use room type to customize the email depending on the room type.

__Email Generation__

The link in the generated email should also pass over the `room_type` to clients ( like it is doing for
`inviter_name`, `room_name`, `room_avatar`)
Comment on lines +50 to +51
Copy link
Member

Choose a reason for hiding this comment

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

I don't think any of this bit is specced currently...

Copy link
Member Author

Choose a reason for hiding this comment

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

Should I create a new PR to add them to the spec?

Copy link
Member

Choose a reason for hiding this comment

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

I think the intent of this MSC is clear enough. Would count the missing three as a spec omission.


## Potential issues

None.


## Security considerations

None.
BillCarsonFr marked this conversation as resolved.
Show resolved Hide resolved

## Unstable prefix

The following mapping will be used for identifiers in this MSC during development:


Proposed final identifier | Purpose | Development identifier
------------------------------- | ------- | ----
`room_type` | POST body | `org.matrix.msc3288.room_type`