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

knock_room_state is used in an example, but never explained properly #1212

Open
jplatte opened this issue Aug 17, 2022 · 2 comments
Open

knock_room_state is used in an example, but never explained properly #1212

jplatte opened this issue Aug 17, 2022 · 2 comments
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit

Comments

@jplatte
Copy link
Contributor

jplatte commented Aug 17, 2022

Link to problem area: https://spec.matrix.org/v1.3/client-server-api/#mroommember

Issue

One of the examples for m.room.member contains a knock_room_state field in unsigned, but this is not mentioned anywhere else. It seems similar to invite_room_state which is also only explained very briefly (not listed in one of the tables, just mentioned in the text), if it actually exists rather than just being an artifact that was never meant to enter the spec.

@jplatte jplatte added the clarification An area where the expected behaviour is understood, but the spec could do with being more explicit label Aug 17, 2022
@anoadragon453
Copy link
Member

I believe that it's an error that invite_room_state should be known to the client, see #848.

The examples for invite_room_state and knock_room_state should be removed from the CS API spec. The linked issue covers invite_room_state, whereas this issue covers knock_room_state.

Note: invite_room_state is only included in the unsigned field of a m.room.member event when using the v1 Federation invite endpoint: https://spec.matrix.org/v1.4/server-server-api/#put_matrixfederationv1inviteroomideventid

In v2, stripped invite state has moved to a field in the request body.

Still, it doesn't belong in the CS API.

@zecakeh
Copy link
Contributor

zecakeh commented Apr 26, 2024

For some follow up here, it seems that the fields are actually present for appservices, and it was decided in #1273 (comment) that an MSC should be created to move the fields from the CS API to the AS API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit
Projects
None yet
3 participants