Muting a server or a channel in the official Discord client is an account setting -
it arrives in READY as user_guild_settings, and every device the account is signed
in to respects it. moho never reads that field, so a guild somebody deliberately
silenced months ago is as loud here as anything else, and the busiest servers are the
ones people mute.
moho has a mute of its own, but it is a preference in this window
(isEffectivelyMuted, components/BufferList.tsx:238): it does not come from
Discord, does not go back to Discord, and is not there in a second window or on
another machine.
What is needed
Parse user_guild_settings in READY (and the USER_GUILD_SETTINGS_UPDATE
dispatch): per-guild muted, suppress_everyone, suppress_roles, and the
per-channel channel_overrides.
Fold it into the same place the local mute is read, so a channel muted on either
side is quiet - and say which is which, since one of them is undoable here and the
other is not.
Setting it from moho can follow later; being told is the half that matters.
Done looks like: a server muted in the Discord client is muted in moho without
being muted again.
Reference: the official Discord client.
Muting a server or a channel in the official Discord client is an account setting -
it arrives in READY as `user_guild_settings`, and every device the account is signed
in to respects it. moho never reads that field, so a guild somebody deliberately
silenced months ago is as loud here as anything else, and the busiest servers are the
ones people mute.
moho has a mute of its own, but it is a preference in this window
(`isEffectivelyMuted`, `components/BufferList.tsx:238`): it does not come from
Discord, does not go back to Discord, and is not there in a second window or on
another machine.
**What is needed**
- Parse `user_guild_settings` in READY (and the `USER_GUILD_SETTINGS_UPDATE`
dispatch): per-guild `muted`, `suppress_everyone`, `suppress_roles`, and the
per-channel `channel_overrides`.
- Fold it into the same place the local mute is read, so a channel muted on either
side is quiet - and say which is which, since one of them is undoable here and the
other is not.
- Setting it from moho can follow later; being *told* is the half that matters.
**Done looks like:** a server muted in the Discord client is muted in moho without
being muted again.
Reference: the official Discord client.
user_guild_settings is read from READY, and USER_GUILD_SETTINGS_UPDATE keeps it current - per-guild muted and the per-channel channel_overrides.
Verified against the real account rather than only against the payload shapes. Of 41 conversations, 16 came up muted: one guild entirely (a guild mute), and four of five and one of five in two others (channel overrides). Both shapes, exactly as they are set in Discord.
Three things worth recording:
Applying is its own step. The settings arrive in READY and the channels they name arrive afterwards in GUILD_CREATE, so a mute applied when read would be applied to buffers that do not exist yet. What is read is kept, and applied again whenever there is somewhere new to apply it to.
A timed mute has to be checked against the clock. "Mute for 8 hours" keeps its flag set after the eight hours are up and Discord expects the client to notice. Reading the flag alone would silence a server permanently because somebody once silenced it for an evening.
A muted guild silences everything in it, so a channel and its guild are read as an "or" rather than the channel overruling the guild - which is what Discord's own client does.
On the client half, isMutedBuffer is where this window decides a conversation is muted, so the account's own mute sits there beside the two already in it. The menu entry is the part that needed care: a mute made on the account is not this window's to undo, and an "Unmute" that quietly did nothing would be worse than no entry at all - so where there is one, the entry names the service holding it and is not a switch.
set_silenced now does both halves of what it always meant - nothing announces itself, and the buffer says so on the wire - so Matrix's push-rule mutes are drawn as mutes too, which they were not before.
Two fields deliberately left alone.suppress_everyone and suppress_roles are read by no code here because there is nothing for them to suppress: mentions_own_user counts only direct user mentions, so an @everyone or a role ping does not raise a mention in moho in the first place. Wiring them would mean inventing the behaviour they suppress. If @everyone should highlight at all, that is its own question and worth its own issue.
Setting a mute from moho is not implemented - as the issue says, being told is the half that matters.
Finished in nobilis [a0e5823](https://git.salastil.com/Salastil/nobilis/commit/a0e5823) and moho [be32f5e](https://git.salastil.com/Salastil/moho/commit/be32f5e).
`user_guild_settings` is read from READY, and `USER_GUILD_SETTINGS_UPDATE` keeps it current - per-guild `muted` and the per-channel `channel_overrides`.
**Verified against the real account rather than only against the payload shapes.** Of 41 conversations, 16 came up muted: one guild entirely (a guild mute), and four of five and one of five in two others (channel overrides). Both shapes, exactly as they are set in Discord.
Three things worth recording:
- **Applying is its own step.** The settings arrive in READY and the channels they name arrive afterwards in GUILD_CREATE, so a mute applied when read would be applied to buffers that do not exist yet. What is read is kept, and applied again whenever there is somewhere new to apply it to.
- **A timed mute has to be checked against the clock.** "Mute for 8 hours" keeps its flag set after the eight hours are up and Discord expects the client to notice. Reading the flag alone would silence a server permanently because somebody once silenced it for an evening.
- **A muted guild silences everything in it**, so a channel and its guild are read as an "or" rather than the channel overruling the guild - which is what Discord's own client does.
On the client half, `isMutedBuffer` is where this window decides a conversation is muted, so the account's own mute sits there beside the two already in it. The menu entry is the part that needed care: a mute made on the account is not this window's to undo, and an "Unmute" that quietly did nothing would be worse than no entry at all - so where there is one, the entry names the service holding it and is not a switch.
`set_silenced` now does both halves of what it always meant - nothing announces itself, *and* the buffer says so on the wire - so Matrix's push-rule mutes are drawn as mutes too, which they were not before.
**Two fields deliberately left alone.** `suppress_everyone` and `suppress_roles` are read by no code here because there is nothing for them to suppress: `mentions_own_user` counts only direct user mentions, so an `@everyone` or a role ping does not raise a mention in moho in the first place. Wiring them would mean inventing the behaviour they suppress. If @everyone should highlight at all, that is its own question and worth its own issue.
Setting a mute *from* moho is not implemented - as the issue says, being told is the half that matters.
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.
Muting a server or a channel in the official Discord client is an account setting -
it arrives in READY as
user_guild_settings, and every device the account is signedin to respects it. moho never reads that field, so a guild somebody deliberately
silenced months ago is as loud here as anything else, and the busiest servers are the
ones people mute.
moho has a mute of its own, but it is a preference in this window
(
isEffectivelyMuted,components/BufferList.tsx:238): it does not come fromDiscord, does not go back to Discord, and is not there in a second window or on
another machine.
What is needed
user_guild_settingsin READY (and theUSER_GUILD_SETTINGS_UPDATEdispatch): per-guild
muted,suppress_everyone,suppress_roles, and theper-channel
channel_overrides.side is quiet - and say which is which, since one of them is undoable here and the
other is not.
Done looks like: a server muted in the Discord client is muted in moho without
being muted again.
Reference: the official Discord client.
Finished in nobilis a0e5823 and moho be32f5e.
user_guild_settingsis read from READY, andUSER_GUILD_SETTINGS_UPDATEkeeps it current - per-guildmutedand the per-channelchannel_overrides.Verified against the real account rather than only against the payload shapes. Of 41 conversations, 16 came up muted: one guild entirely (a guild mute), and four of five and one of five in two others (channel overrides). Both shapes, exactly as they are set in Discord.
Three things worth recording:
On the client half,
isMutedBufferis where this window decides a conversation is muted, so the account's own mute sits there beside the two already in it. The menu entry is the part that needed care: a mute made on the account is not this window's to undo, and an "Unmute" that quietly did nothing would be worse than no entry at all - so where there is one, the entry names the service holding it and is not a switch.set_silencednow does both halves of what it always meant - nothing announces itself, and the buffer says so on the wire - so Matrix's push-rule mutes are drawn as mutes too, which they were not before.Two fields deliberately left alone.
suppress_everyoneandsuppress_rolesare read by no code here because there is nothing for them to suppress:mentions_own_usercounts only direct user mentions, so an@everyoneor a role ping does not raise a mention in moho in the first place. Wiring them would mean inventing the behaviour they suppress. If @everyone should highlight at all, that is its own question and worth its own issue.Setting a mute from moho is not implemented - as the issue says, being told is the half that matters.