-
Notifications
You must be signed in to change notification settings - Fork 388
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
Deprecate several fields on /createRoom #1326
Conversation
Signed-off-by: Travis Ralston <[email protected]>
Signed-off-by: Travis Ralston <[email protected]>
Note: this is something that isn't a spec omission but seems to qualify for #1308 |
Spec: matrix-org/matrix-spec-proposals#1326 Signed-off-by: Travis Ralston <[email protected]>
Creating rooms with avatars is under a proposal at the time of writing. Spec: matrix-org/matrix-spec-proposals#1326 Synapse: matrix-org/synapse#3417 Signed-off-by: Travis Ralston <[email protected]>
Signed-off-by: Travis Ralston <[email protected]>
Community feedback is that this should actually be turned the other way: |
This is preferred over adding an avatar field. Clients are expected to use the initial_state going forward. For more information, see matrix-org#1326 Signed-off-by: Travis Ralston <[email protected]>
The original spec proposal (matrix-org/matrix-spec-proposals#1326) has instead gone the route of deprecating the name and topic. The avatar test is not needed. Signed-off-by: Travis Ralston <[email protected]>
Clients are instead encouraged to set the m.room.guest_access state event. Signed-off-by: Travis Ralston <[email protected]>
I'd like to see this in a gdoc just because I expect there will be some contention, but fwiw I'm strongly in favour of initial state over random keys. |
There wasn't any contention when it was discussed, although now that it has been asked, I'll write the very short doc. |
Proposal created as requested as MSC1330 |
For the record - I'm fine with this one. I might probably consider two separate "call signatures" - a simpler one (name/topic/can.alias), to ease life for inexperienced client authors, and a more comprehensive one (just initial_state, with all the freedom, subject to server validation) but for now, let's at least have one that allows to do everything necessary without parameters overlapping. |
Closing this while it's in the proposal stage. See: https://github.com/matrix-org/matrix-doc/issues/1330 |
Originally this PR was to add an
avatar
field, however after discussion with the community it was determined that deprecating the parameters would be better than adding a third. Clients can useinitial_state
to set the name, avatar, and topic.