/kick, /ban, /op, /deop, /voice, /devoice all exist (backend/irc.rs:1197-1203), but the member-list context menu routes kick/ban/mute exclusively to the Matrix RPCs (NickList.tsx:36-37, :121-127; same in MessageRow.tsx:637). So IRC moderation works only if you know the command and type it into the composer.
The comment at irc.rs:1155-1161 claims the frontend gates these behind the userlist menu when you hold op. That is now factually wrong and should go either way.
Done looks like: the userlist menu offers the IRC ops on an IRC account, gated on the local user's rank, which emit_presence already tracks.
`/kick`, `/ban`, `/op`, `/deop`, `/voice`, `/devoice` all exist (`backend/irc.rs:1197-1203`), but the member-list context menu routes kick/ban/mute exclusively to the Matrix RPCs (`NickList.tsx:36-37`, `:121-127`; same in `MessageRow.tsx:637`). So IRC moderation works only if you know the command and type it into the composer.
The comment at `irc.rs:1155-1161` claims the frontend gates these behind the userlist menu when you hold op. That is now factually wrong and should go either way.
**Done looks like:** the userlist menu offers the IRC ops on an IRC account, gated on the local user's rank, which `emit_presence` already tracks.
Kick, ban and mute routed unconditionally to kickMatrixMember/banMatrixMember/muteMatrixMember, so on IRC the entries never appeared at all — and the commands that do exist were reachable only by typing them into the composer, which is precisely what the menu exists to save.
The two protocols answer "may I" differently and now do so separately. Matrix asks the server, where its power levels live. IRC's answer was already on screen: the member list carries every nick's prefix including the local user's, so what we may do is whatever our own prefix says. Both are advisory — the server re-checks and refuses if we were wrong, exactly as it would any other client.
That needed one thing the daemon was not reporting: which nick the account is actually using. A session that landed on the alt nick is using that until GHOST reclaims the real one, so the configured nick is not an answer to "which of these rows is me". Account.currentNick now says.
Also added, since the rank information was right there: give and take operator, give and take voice. Separate entries rather than one toggle, chosen by the member's own prefix — a toggle that guessed wrong would take op from somebody by accident. "Mute" resolves to devoice on IRC, which is what muting means in a moderated channel.
Deliberately generous at the halfop boundary: networks disagree about what a halfop may do, and offering an action the server then refuses is a better failure than hiding one it would have allowed.
The stale comment at irc.rs:1155-1161, which claimed the frontend already did this, went with it.
Finished — https://git.salastil.com/Salastil/moho/commit/fa47a67 and https://git.salastil.com/Salastil/nobilis/commit/cc26500
Kick, ban and mute routed unconditionally to `kickMatrixMember`/`banMatrixMember`/`muteMatrixMember`, so on IRC the entries never appeared at all — and the commands that do exist were reachable only by typing them into the composer, which is precisely what the menu exists to save.
The two protocols answer "may I" differently and now do so separately. Matrix asks the server, where its power levels live. IRC's answer was already on screen: the member list carries every nick's prefix including the local user's, so what we may do is whatever our own prefix says. Both are advisory — the server re-checks and refuses if we were wrong, exactly as it would any other client.
That needed one thing the daemon was not reporting: which nick the account is actually using. A session that landed on the alt nick is using that until GHOST reclaims the real one, so the configured nick is not an answer to "which of these rows is me". `Account.currentNick` now says.
Also added, since the rank information was right there: give and take operator, give and take voice. Separate entries rather than one toggle, chosen by the member's own prefix — a toggle that guessed wrong would take op from somebody by accident. "Mute" resolves to devoice on IRC, which is what muting means in a moderated channel.
Deliberately generous at the halfop boundary: networks disagree about what a halfop may do, and offering an action the server then refuses is a better failure than hiding one it would have allowed.
The stale comment at `irc.rs:1155-1161`, which claimed the frontend already did this, went with it.
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.
/kick,/ban,/op,/deop,/voice,/devoiceall exist (backend/irc.rs:1197-1203), but the member-list context menu routes kick/ban/mute exclusively to the Matrix RPCs (NickList.tsx:36-37,:121-127; same inMessageRow.tsx:637). So IRC moderation works only if you know the command and type it into the composer.The comment at
irc.rs:1155-1161claims the frontend gates these behind the userlist menu when you hold op. That is now factually wrong and should go either way.Done looks like: the userlist menu offers the IRC ops on an IRC account, gated on the local user's rank, which
emit_presencealready tracks.Finished — https://git.salastil.com/Salastil/moho/commit/fa47a67 and https://git.salastil.com/Salastil/nobilis/commit/cc26500
Kick, ban and mute routed unconditionally to
kickMatrixMember/banMatrixMember/muteMatrixMember, so on IRC the entries never appeared at all — and the commands that do exist were reachable only by typing them into the composer, which is precisely what the menu exists to save.The two protocols answer "may I" differently and now do so separately. Matrix asks the server, where its power levels live. IRC's answer was already on screen: the member list carries every nick's prefix including the local user's, so what we may do is whatever our own prefix says. Both are advisory — the server re-checks and refuses if we were wrong, exactly as it would any other client.
That needed one thing the daemon was not reporting: which nick the account is actually using. A session that landed on the alt nick is using that until GHOST reclaims the real one, so the configured nick is not an answer to "which of these rows is me".
Account.currentNicknow says.Also added, since the rank information was right there: give and take operator, give and take voice. Separate entries rather than one toggle, chosen by the member's own prefix — a toggle that guessed wrong would take op from somebody by accident. "Mute" resolves to devoice on IRC, which is what muting means in a moderated channel.
Deliberately generous at the halfop boundary: networks disagree about what a halfop may do, and offering an action the server then refuses is a better failure than hiding one it would have allowed.
The stale comment at
irc.rs:1155-1161, which claimed the frontend already did this, went with it.