Neither GET /_matrix/client/versions nor GET /_matrix/client/v3/capabilities is
called anywhere in nobilis/src/backend/matrix/. So which spec versions a homeserver
speaks, which room versions it will create, and whether it allows a display-name or
password change are all discovered by trying and failing.
The failures are the confusing kind: creating a room with an unsupported version
answers with a 400 that names the version rather than saying "this server does not do
that", and a display-name change on a locked-down homeserver simply does not take.
What is needed
Read both on connect and keep them beside the account.
Use m.room_versions when creating a room rather than letting the server default,
and gate the profile-change entries on m.set_displayname / m.set_avatar_url.
Done looks like: the client knows what the server will refuse before it asks.
Neither `GET /_matrix/client/versions` nor `GET /_matrix/client/v3/capabilities` is
called anywhere in `nobilis/src/backend/matrix/`. So which spec versions a homeserver
speaks, which room versions it will create, and whether it allows a display-name or
password change are all discovered by trying and failing.
The failures are the confusing kind: creating a room with an unsupported version
answers with a 400 that names the version rather than saying "this server does not do
that", and a display-name change on a locked-down homeserver simply does not take.
**What is needed**
- Read both on connect and keep them beside the account.
- Use `m.room_versions` when creating a room rather than letting the server default,
and gate the profile-change entries on `m.set_displayname` / `m.set_avatar_url`.
**Done looks like:** the client knows what the server will refuse before it asks.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Neither
GET /_matrix/client/versionsnorGET /_matrix/client/v3/capabilitiesiscalled anywhere in
nobilis/src/backend/matrix/. So which spec versions a homeserverspeaks, which room versions it will create, and whether it allows a display-name or
password change are all discovered by trying and failing.
The failures are the confusing kind: creating a room with an unsupported version
answers with a 400 that names the version rather than saying "this server does not do
that", and a display-name change on a locked-down homeserver simply does not take.
What is needed
m.room_versionswhen creating a room rather than letting the server default,and gate the profile-change entries on
m.set_displayname/m.set_avatar_url.Done looks like: the client knows what the server will refuse before it asks.