createRoom is only ever called for DMs (mod.rs:1186-1229); everywhere else it appears in ignored tests. There is no way to make a room or a space.
Nor to change one: m.room.topic is never read or written, and name, avatar, join rules, history visibility and encryption cannot be set. Power levels are readable and mutable only downward, via mute_member — nobody can be promoted.
Done looks like: a create-room flow in the join panel, and a room settings pane covering topic, name, avatar and power levels.
`createRoom` is only ever called for DMs (`mod.rs:1186-1229`); everywhere else it appears in ignored tests. There is no way to make a room or a space.
Nor to change one: `m.room.topic` is never read or written, and name, avatar, join rules, history visibility and encryption cannot be set. Power levels are readable and mutable only downward, via `mute_member` — nobody can be promoted.
**Done looks like:** a create-room flow in the join panel, and a room settings pane covering topic, name, avatar and power levels.
Creating.createRoom was only ever called to open a direct message, so there was no way to make a room at all. One call makes a room or a space, because a space is a room with m.space as its creation type and nothing else different — a second path would invent a distinction the protocol has not got.
Encryption is offered and defaults to off, which is the reversible choice: a room can be encrypted later and never un-encrypted. Where it is asked for it goes in as initial state, since a room encrypted from its first message has no plaintext history to leak and one turned on later always does. The new room is deliberately not selected — it arrives through the next sync with whatever name and kind the server settled on, and jumping at a buffer that does not exist yet would land on nothing.
Name and topic. Two state events with one shape, so one method. m.room.topic was previously never read or written.
Power levels moved only downwards, through mute, so nobody could be made an operator of anything from here. Setting one is the same read-modify-write mute_member already does, for the same reason: a power-levels event is a full replace, so PUTting a single user would silently wipe every other rank and threshold in the room.
Giving somebody a rank above your own is refused here rather than left to the server, whose error talks about event authorisation rather than about what was attempted. Giving somebody your own rank is allowed and deliberately not blocked — it is a real thing people do.
The member menu offers 0, 50 and 100 rather than a free-text number: those are the three Matrix's own defaults are built around, and a box wanting an integer nobody has a feel for is not a choice anybody can make well.
Not included: room avatars, join rules and history visibility. All are the same shape of state event and can follow the same path when wanted.
Finished — https://git.salastil.com/Salastil/nobilis/commit/27ce6a1 and https://git.salastil.com/Salastil/moho/commit/fb12f67
Three gaps, all in the same area.
**Creating.** `createRoom` was only ever called to open a direct message, so there was no way to make a room at all. One call makes a room or a space, because a space is a room with `m.space` as its creation type and nothing else different — a second path would invent a distinction the protocol has not got.
Encryption is offered and defaults to off, which is the *reversible* choice: a room can be encrypted later and never un-encrypted. Where it is asked for it goes in as initial state, since a room encrypted from its first message has no plaintext history to leak and one turned on later always does. The new room is deliberately not selected — it arrives through the next sync with whatever name and kind the server settled on, and jumping at a buffer that does not exist yet would land on nothing.
**Name and topic.** Two state events with one shape, so one method. `m.room.topic` was previously never read *or* written.
**Power levels** moved only downwards, through mute, so nobody could be made an operator of anything from here. Setting one is the same read-modify-write `mute_member` already does, for the same reason: a power-levels event is a full replace, so PUTting a single user would silently wipe every other rank and threshold in the room.
Giving somebody a rank above your own is refused here rather than left to the server, whose error talks about event authorisation rather than about what was attempted. Giving somebody your *own* rank is allowed and deliberately not blocked — it is a real thing people do.
The member menu offers 0, 50 and 100 rather than a free-text number: those are the three Matrix's own defaults are built around, and a box wanting an integer nobody has a feel for is not a choice anybody can make well.
Not included: room avatars, join rules and history visibility. All are the same shape of state event and can follow the same path when wanted.
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.
createRoomis only ever called for DMs (mod.rs:1186-1229); everywhere else it appears in ignored tests. There is no way to make a room or a space.Nor to change one:
m.room.topicis never read or written, and name, avatar, join rules, history visibility and encryption cannot be set. Power levels are readable and mutable only downward, viamute_member— nobody can be promoted.Done looks like: a create-room flow in the join panel, and a room settings pane covering topic, name, avatar and power levels.
Finished — https://git.salastil.com/Salastil/nobilis/commit/27ce6a1 and https://git.salastil.com/Salastil/moho/commit/fb12f67
Three gaps, all in the same area.
Creating.
createRoomwas only ever called to open a direct message, so there was no way to make a room at all. One call makes a room or a space, because a space is a room withm.spaceas its creation type and nothing else different — a second path would invent a distinction the protocol has not got.Encryption is offered and defaults to off, which is the reversible choice: a room can be encrypted later and never un-encrypted. Where it is asked for it goes in as initial state, since a room encrypted from its first message has no plaintext history to leak and one turned on later always does. The new room is deliberately not selected — it arrives through the next sync with whatever name and kind the server settled on, and jumping at a buffer that does not exist yet would land on nothing.
Name and topic. Two state events with one shape, so one method.
m.room.topicwas previously never read or written.Power levels moved only downwards, through mute, so nobody could be made an operator of anything from here. Setting one is the same read-modify-write
mute_memberalready does, for the same reason: a power-levels event is a full replace, so PUTting a single user would silently wipe every other rank and threshold in the room.Giving somebody a rank above your own is refused here rather than left to the server, whose error talks about event authorisation rather than about what was attempted. Giving somebody your own rank is allowed and deliberately not blocked — it is a real thing people do.
The member menu offers 0, 50 and 100 rather than a free-text number: those are the three Matrix's own defaults are built around, and a box wanting an integer nobody has a feel for is not a choice anybody can make well.
Not included: room avatars, join rules and history visibility. All are the same shape of state event and can follow the same path when wanted.