setMatrixIgnored and listMatrixIgnored (#99) gave Matrix a proper ignore list -
server-side, so it follows the account. No other service has anything: not Discord,
which has blocking; not IRC, where an ignore list is a client's own job and every
client has one; not Kick; not Sneedchat.
So the menu on a person offers to ignore them on one service out of five, and on the
other four the answer to somebody being tiresome is to leave.
What is needed, per service, because the shape genuinely differs
Discord: blocking is a relationship - PUT /users/@me/relationships/{id} with
type 2 - and it is account-wide and visible to Discord. RELATIONSHIP_ADD is
already handled (#79) so the state arrives already.
IRC: no server has this. A local list, matched on nick and host mask the way
every IRC client does it, held per account beside the autojoin list.
Kick and Sneedchat: local, same as IRC. Kick's own site has a block; whether it
is reachable from the endpoints moho already uses should be checked before assuming
either way.
One list in the client's mind, however it is stored: the person doing the ignoring
does not care which half is the server's.
Done looks like: the entry in the member list menu works on every service, and
says which ones the other person's server is told about - being blocked on Discord is
visible to them, and an IRC ignore is not.
Reference: Element, the Discord client, HexChat's /ignore. Follows #99.
`setMatrixIgnored` and `listMatrixIgnored` (#99) gave Matrix a proper ignore list -
server-side, so it follows the account. No other service has anything: not Discord,
which has blocking; not IRC, where an ignore list is a client's own job and every
client has one; not Kick; not Sneedchat.
So the menu on a person offers to ignore them on one service out of five, and on the
other four the answer to somebody being tiresome is to leave.
**What is needed, per service, because the shape genuinely differs**
- **Discord**: blocking is a relationship - `PUT /users/@me/relationships/{id}` with
type 2 - and it is account-wide and visible to Discord. `RELATIONSHIP_ADD` is
already handled (#79) so the state arrives already.
- **IRC**: no server has this. A local list, matched on nick and host mask the way
every IRC client does it, held per account beside the autojoin list.
- **Kick and Sneedchat**: local, same as IRC. Kick's own site has a block; whether it
is reachable from the endpoints moho already uses should be checked before assuming
either way.
- One list in the client's mind, however it is stored: the person doing the ignoring
does not care which half is the server's.
**Done looks like:** the entry in the member list menu works on every service, and
says which ones the other person's server is told about - being blocked on Discord is
visible to them, and an IRC ignore is not.
Reference: Element, the Discord client, HexChat's `/ignore`. Follows #99.
One request, answered differently by each service and honest about which:
Matrix keeps its list on the homeserver, as before.
Discord gets a real block (relationship type 2) and a local entry — its gateway goes on delivering what a blocked person says, so this client is what has to stop showing it.
IRC, Kick, Sneedchat have nobody to tell, so the list is kept in the daemon.
The answer says which, and the toast repeats it: "Ignoring X" versus "Ignoring X here".
Applied in record_message_at, where every message already passes — a window can hide a line and cannot stop it counting as unread, notifying, or going into the log. That also replaces the old "Block" in the member list, which was a preference in one window that did exactly that hiding and nothing more.
/ignore and /unignore are the same thing typed, on every service — including Sneedchat, where the daemon acts on the line and returns before anything is sent, so nothing reaches a site that reads messages for commands.
Verified live. IRC: a scratch client sent one message before the ignore and one after; the first is in the log, the second never arrived on screen though the server delivered it. /unignore and a bare /ignore both answered in the server buffer. Matrix: ignoring and un-ignoring a test id went to the homeserver's own list and came back out of it.
Not verified: the Discord block. Blocking is a real, visible action against a real account and I did not want to press it on somebody to prove a code path — the endpoint is the documented PUT/DELETE /users/@me/relationships/{id}, and it goes through the same write pacing as everything else Discord.
Known limit, stated rather than papered over: on IRC a nick is a rented name, and somebody who changes it walks straight back through. That hole is as old as IRC ignore itself and is not closed here; patterns take a *, which is what catches a family of bots.
Finished — https://git.salastil.com/Salastil/nobilis/commit/c04d211 and https://git.salastil.com/Salastil/moho/commit/f4d7b21
One request, answered differently by each service and honest about which:
- **Matrix** keeps its list on the homeserver, as before.
- **Discord** gets a real block (relationship type 2) *and* a local entry — its gateway goes on delivering what a blocked person says, so this client is what has to stop showing it.
- **IRC, Kick, Sneedchat** have nobody to tell, so the list is kept in the daemon.
The answer says which, and the toast repeats it: "Ignoring X" versus "Ignoring X here".
Applied in `record_message_at`, where every message already passes — a window can hide a line and cannot stop it counting as unread, notifying, or going into the log. That also replaces the old "Block" in the member list, which was a preference in one window that did exactly that hiding and nothing more.
`/ignore` and `/unignore` are the same thing typed, on every service — including Sneedchat, where the daemon acts on the line and returns before anything is sent, so nothing reaches a site that reads messages for commands.
**Verified live.** IRC: a scratch client sent one message before the ignore and one after; the first is in the log, the second never arrived on screen though the server delivered it. `/unignore` and a bare `/ignore` both answered in the server buffer. Matrix: ignoring and un-ignoring a test id went to the homeserver's own list and came back out of it.
**Not verified:** the Discord block. Blocking is a real, visible action against a real account and I did not want to press it on somebody to prove a code path — the endpoint is the documented `PUT/DELETE /users/@me/relationships/{id}`, and it goes through the same write pacing as everything else Discord.
**Known limit, stated rather than papered over:** on IRC a nick is a rented name, and somebody who changes it walks straight back through. That hole is as old as IRC ignore itself and is not closed here; patterns take a `*`, which is what catches a family of bots.
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.
setMatrixIgnoredandlistMatrixIgnored(#99) gave Matrix a proper ignore list -server-side, so it follows the account. No other service has anything: not Discord,
which has blocking; not IRC, where an ignore list is a client's own job and every
client has one; not Kick; not Sneedchat.
So the menu on a person offers to ignore them on one service out of five, and on the
other four the answer to somebody being tiresome is to leave.
What is needed, per service, because the shape genuinely differs
PUT /users/@me/relationships/{id}withtype 2 - and it is account-wide and visible to Discord.
RELATIONSHIP_ADDisalready handled (#79) so the state arrives already.
every IRC client does it, held per account beside the autojoin list.
is reachable from the endpoints moho already uses should be checked before assuming
either way.
does not care which half is the server's.
Done looks like: the entry in the member list menu works on every service, and
says which ones the other person's server is told about - being blocked on Discord is
visible to them, and an IRC ignore is not.
Reference: Element, the Discord client, HexChat's
/ignore. Follows #99.Finished — https://git.salastil.com/Salastil/nobilis/commit/c04d211 and https://git.salastil.com/Salastil/moho/commit/f4d7b21
One request, answered differently by each service and honest about which:
The answer says which, and the toast repeats it: "Ignoring X" versus "Ignoring X here".
Applied in
record_message_at, where every message already passes — a window can hide a line and cannot stop it counting as unread, notifying, or going into the log. That also replaces the old "Block" in the member list, which was a preference in one window that did exactly that hiding and nothing more./ignoreand/unignoreare the same thing typed, on every service — including Sneedchat, where the daemon acts on the line and returns before anything is sent, so nothing reaches a site that reads messages for commands.Verified live. IRC: a scratch client sent one message before the ignore and one after; the first is in the log, the second never arrived on screen though the server delivered it.
/unignoreand a bare/ignoreboth answered in the server buffer. Matrix: ignoring and un-ignoring a test id went to the homeserver's own list and came back out of it.Not verified: the Discord block. Blocking is a real, visible action against a real account and I did not want to press it on somebody to prove a code path — the endpoint is the documented
PUT/DELETE /users/@me/relationships/{id}, and it goes through the same write pacing as everything else Discord.Known limit, stated rather than papered over: on IRC a nick is a rented name, and somebody who changes it walks straight back through. That hole is as old as IRC ignore itself and is not closed here; patterns take a
*, which is what catches a family of bots.