search

matrix-org / matrix-spec

The Matrix protocol specification
Apache License 2.0
186 stars 94 forks source link

Support arbitrary metadata on invites (SPEC-357) #160

Open matrixbot opened 8 years ago

matrixbot commented 8 years ago

A request from [~Rugvip] is to support the ability to include arbitrary metadata in invites, so that clients can perform business logic on the invite without having to accept it. The given example is:

let's say you're creating an online game on top of synapse, and you can invite users either to chat channels or to game lobbies and if a room is a game lobby or not is determined by a key in the create state You could of course do it with weird hacks in the room name, avatar, w/e or what the hell, why not just make the invite state types configurable? :D defaulting to the current ones

(Imported from https://matrix.org/jira/browse/SPEC-357)

(Reported by @ara4n)

matrixbot commented 8 years ago

Jira watchers: @dbkr @ara4n

matrixbot commented 8 years ago

Sounds like folks are happy with this idea, given we can already put arbitrary data on the events which /are/ allowed, it's not a big deal to let arbitrary events in general... as long as:

a) clients consider the info as purely informational (ie not trust it as actual data from the room, given at best it will be a stale cache thereof) b) and not rely on it for the core behaviour of the client - it would really suck if invites became fragmented and my generic matrix client couldn't meaningfully accept them without understanding random associated events.

Personally I would be much happier if we instead encouraged the invitee to peek into the invited room to inspect the real state of what they were being invited to, rather than this weird fake stale version of the state, but given that boat has already sailed I'm not sure it makes things much worse to provide the requested flexibility here and allow arbitrary events in the invite.

-- @ara4n

matrixbot commented 8 years ago

I don't see how including this information is useful really, if the client can't trust it for anything (and therefore can't reasonably display it to the user, at least not without also displaying a warning) - especially in this case which is where the user is actually making a trust decision.

Is it really too late to mandate peeking for invite metadata? There's a sensible migration path since we can continue to include the metadata in the invite in the transition period.

-- @dbkr