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

Invites need to convey a better summary of the room they describe. #380

Open
ara4n opened this issue Sep 18, 2018 · 3 comments
Open

Invites need to convey a better summary of the room they describe. #380

ara4n opened this issue Sep 18, 2018 · 3 comments
Labels
A-Client-Server Issues affecting the CS API enhancement A suggestion for a relatively simple improvement to the protocol

Comments

@ara4n
Copy link
Member

ara4n commented Sep 18, 2018

Currently we allow a subset of state events through in an invite.

This isn't enough to correctly calculate the name & avatar of a room based on matrix-org/matrix-spec-proposals#688.

Either we need to somehow include enough state in the invite (e.g. a hypothetical m.room.summary event, plus a bunch of m.room.members for the heroes), or we need to change things so that invitees can peek into the live DAG of an invited room and draw their own conclusions.

If we supported invitees peeking into the live DAG of an invited room this would also solve things like the problems around supporting encryption for invited users before they join a room - c.f. element-hq/element-web#2713 (comment)

@bwindels
Copy link
Contributor

An alternative could be that the server includes a room summary under the same conditions as for joined rooms (no name or avatar set...), and if the summary needs to have heroes, augment the invite_state with the member events for the heroes.

Allowing invitees to have access to the DAG might be useful, but I think we'd still need a room summary, because you wouldn't want to have to load all the members to give an accurate name and avatar for a room you got invited to.

@ara4n
Copy link
Member Author

ara4n commented Sep 18, 2018

An alternative could be that the server includes a room summary under the same conditions as for joined rooms (no name or avatar set...), and if the summary needs to have heroes, augment the invite_state with the member events for the heroes.

Yup, this is what i was trying to suggest in the first option in the original comment:

Either we need to somehow include enough state in the invite (e.g. a hypothetical m.room.summary event, plus a bunch of m.room.members for the heroes)

@ara4n
Copy link
Member Author

ara4n commented Sep 18, 2018

If we were allowing direct access to the DAG, then we'd get the room summary for free, i think, as it'd probably look like a joined room, so the same rules would apply for calculating the /sync details for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Client-Server Issues affecting the CS API enhancement A suggestion for a relatively simple improvement to the protocol
Projects
None yet
Development

No branches or pull requests

3 participants