Bundle in some room state in invites.

[erikjohnston]

Changes:

• When an invite is sent to someone, bundle in the state of the room at the time under unsigned.invite_room_state. In v1 C-S API this is copied to a top level key of invite_room_state.
• Include the invite event in initialSync.

The state events that are included are:

• Room name
• Room avatar
• Canonical Alias
• Join rules

The fields of the events that are included:

• type
• state_key
• content

This is not a particularly nice way of getting this done, but to do it any nicer would probably involve changing the federation API in a non backwards compatible way.

[ara4n]

by putting this in unsigned does it make it vulnerable to spoofing and phishing?

[NegativeMjark]

• Does the unsigned key make it into the C-S APIs? In particular does it make it into initialSync?
• Is this added to the specification?
• Do we have tests in sytest for it?

[erikjohnston]

by putting this in unsigned does it make it vulnerable to spoofing and phishing?

@ara4n: Nope. The event is sent directly to the server, and so is protected bySSL and requestsigning

• Does the unsigned key make it into the C-S APIs? In particular does it make it into initialSync?

Yes. In particular: "In v1 C-S API this is copied to a top level key of invite_room_state." And the event has been added to initialSync.

• Is this added to the specification?
• Do we have tests in sytest for it?

No.

[ara4n]

Is this added to the specification?
Do we have tests in sytest for it?
No.

Changes to serverside APIs need to be documented in the spec, even if they are a stopgap until a v2 API (and marked as such), as otherwise client developers (internal or external) have no hope of implementing them consistently. We should never expect client developers to read the synapse source code or comments on PRs to understand an API.

Less important, but we should certainly be adding tests whenever we add an API.

Please can this PR get finished, given it's been hanging around for over two weeks, so that client developers can get on and implement the functionality clientside? The point of these serverside quick fixes is to unblock clientside features; not to cut corners.

Please correct me if I'm reading this wrong.

[erikjohnston]

So do you want me to spec this before landing the PR?

[ara4n]

I suggest waiting until the spec patch has landed to merge this PR in case spec review shows up anything, although it doesn't matter that much either way. My point was more that we shouldn't consider the job complete until it's specced. Also, having spec to refer to might help review of this PR.

[erikjohnston]

Spec has landed, any objections to me landing this?

[ara4n]

lgtm

[NegativeMjark]

LGTM.

[erikjohnston]

matrix-org/matrix-spec-proposals#64