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

MSC2375: Appservice Invite States #2375

Open
wants to merge 4 commits into
base: master
from

Conversation

@Sorunome
Copy link
Contributor

Sorunome commented Dec 3, 2019

Rendered

Signed-off-by: Sorunome sorunome@famedly.com

@Sorunome Sorunome mentioned this pull request Dec 3, 2019
4 of 4 tasks complete
proposals/2375-appservices-invite-states.md Outdated Show resolved Hide resolved
proposals/2375-appservices-invite-states.md Outdated Show resolved Hide resolved
proposals/2375-appservices-invite-states.md Outdated Show resolved Hide resolved
proposals/2375-appservices-invite-states.md Outdated Show resolved Hide resolved
Copy link
Contributor

Half-Shot left a comment

This seems quite sensible to me.

@turt2live turt2live self-requested a review Dec 3, 2019
Sorunome added 3 commits Dec 3, 2019
@Sorunome Sorunome force-pushed the Sorunome:soru/as-invite-states branch from 60e323e to ff2c004 Dec 3, 2019
proposals/2375-appservices-invite-states.md Outdated Show resolved Hide resolved
proposals/2375-appservices-invite-states.md Outdated Show resolved Hide resolved
rooms, e.g. if a token is present and valid in the invite state.

## Proposal
This proposal is about adding `invite_room_state` to the `unsigned` block of invite events when sending

This comment has been minimized.

Copy link
@anoadragon453

anoadragon453 Dec 3, 2019

Member

Why the unsigned block?

This comment has been minimized.

Copy link
@jcgruenhage

jcgruenhage Dec 3, 2019

Member

appservices only receive invites by receiving those events alongside all other events in transactions, so putting the state into those events sounded like it would make most sense. The unsigned block inside the event was chosen to not block the path for potentially sending the federation format to ASs in the future.

This comment has been minimized.

Copy link
@Sorunome

Sorunome Dec 3, 2019

Author Contributor

Additionally, it appears that this is already the standard in the spec, as seen with the server-server invites, so creating multiple locations for the same thing seems wrong. That is also mentioned in the MSC

This way it would be in line with the Server-Server API to send invites.

This comment has been minimized.

Copy link
@jcgruenhage

jcgruenhage Dec 3, 2019

Member

That is only true for the v1 invite endpoint, the v2 invite endpoint puts the invite_room_state next to the event instead of into it

This comment has been minimized.

Copy link
@Sorunome

Sorunome Dec 3, 2019

Author Contributor

Must have slipped sorus eyes

This comment has been minimized.

Copy link
@jcgruenhage

jcgruenhage Dec 3, 2019

Member

I still think that with the current shape of the API, the unsigned block is the best position for this

This comment has been minimized.

Copy link
@Half-Shot

Half-Shot Dec 4, 2019

Contributor

Unsigned is a general dumping ground for not-event-data, so this makes sense to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.