-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Remove undocumented room_alias
key from /createRoom
response
#10321
Comments
I've labelled this as an omission, although I'm not convinced that's the right direction for this particular issue. |
This commit does a number of things: * Minor formatting/alignment changes * Document the room_alias response key. This could be deprecated now, or forfeited, if needed. * Remove the guest_can_join parameter - it is not actually supported * Document the previously undocumented power_level_content_override parameter * Clarify that the room_id is required on the response * More clearly spell out which events are created as part of the request * Clarify how the room alias becomes the canonical alias * Clarify how the `visibility` may be used to determine a default preset to apply * Document the `m.federate` creation content parameter, adding an option for the homeserver to define a default value References: * Preset being inferred by the visibility: https://github.com/matrix-org/synapse/blob/cd32c19a604549b4518d748c07149d140bc9e063/synapse/handlers/room.py#L172-L177 * Power level content overrides: * https://github.com/matrix-org/synapse/blob/master/synapse/handlers/room.py#L198 * https://github.com/matrix-org/synapse/blob/master/synapse/handlers/room.py#L335-L359 * Aliases becoming canonical: https://github.com/matrix-org/synapse/blob/master/synapse/handlers/room.py#L366-L370 * `m.federate` landing in the create event: https://github.com/matrix-org/synapse/blob/master/synapse/handlers/room.py#L311-L315 Fixes https://github.com/matrix-org/matrix-doc/issues/1243 Fixes matrix-org#1471 Inspired by matrix-org#1213
synapse still returns this unspecced field. |
The referenced PR has a bit of a troubled history on this. What are you seeing as an end goal for this issue? |
IMHO we should stop synapse returning the unspecced field. |
Will that break clients which probably depend on this behaviour? Do such clients exist? |
yes, of course.
well, that is the $1M question... |
OH. Github mobile said this issue got transferred from synapse to matrix-doc, but on web it's clearly the other way around. This makes sense. |
I have asked the client developers' room here if this is known to be in use.
|
|
@DMRobertson I cannot edit your message but for Element Android (actually Android SDK), this is only using As iOS, we only use the roomId. |
No known clients seem to use this field. I think we should remove it. |
room_alias
key from /createRoom
response
To fix this:
synapse/synapse/handlers/room.py Lines 1019 to 1021 in 84ddcd7
|
@clokep can you merge the PR? |
It is in the review queue and will get reviewed by a member of the team. |
we should either spec this or remove it.
Presumably it exists to save clients the bother of having to construct their own fully-qualified aliases, but given we don't do the same for other endpoints which create aliases, I'm not convinced it is worthwhile.
I'd therefore be in favour of removing it, but it's worth noting that sytest currently uses it in a non-trivial number of places
The text was updated successfully, but these errors were encountered: