CHANNEL_RECIPIENT_ADD and CHANNEL_RECIPIENT_REMOVE are not handled - neither appears
anywhere in the Discord backend.
The asymmetry is what makes this a defect rather than a missing feature: moho can change group DM membership itself, through addToDiscordGroupDm and removeFromDiscordGroupDm. It just never hears about a change made anywhere else.
So a group DM's member list is correct only for the changes made from this window. Add
somebody from the phone and they are absent here, with their messages arriving from a
person who is not in the list, until the client reconnects and refetches.
`CHANNEL_RECIPIENT_ADD` and `CHANNEL_RECIPIENT_REMOVE` are not handled - neither appears
anywhere in the Discord backend.
The asymmetry is what makes this a defect rather than a missing feature: moho can
*change* group DM membership itself, through `addToDiscordGroupDm` and
`removeFromDiscordGroupDm`. It just never hears about a change made anywhere else.
So a group DM's member list is correct only for the changes made from this window. Add
somebody from the phone and they are absent here, with their messages arriving from a
person who is not in the list, until the client reconnects and refetches.
Salastil
added the bug label 2026-09-11 22:25:59 -04:00
CHANNEL_RECIPIENT_ADD and CHANNEL_RECIPIENT_REMOVE are handled, so a group message's member list now follows changes made anywhere - from a phone, or by another person in the group.
The roster on screen is edited rather than rebuilt: the event carries one user and not the channel, so there is no recipients array to re-derive from, and asking Discord for one would be a request per membership change to learn what the event already said.
The arithmetic is a pure function with its own tests, because it is the part that fails quietly - a list that grows a duplicate, loses somebody, or stops being sorted all look like a working member list until somebody counts. Removal runs on both paths for that reason: Discord can deliver a second ADD for somebody already there, and appending blindly shows them twice.
Somebody who joins arrives offline until PRESENCE_UPDATE says otherwise, which is how everybody else in that list arrived.
Verified offline only. This is receive-side, and the account that may send is in lockdown until the 15th.
Finished in [`e15b964`](https://git.salastil.com/Salastil/moho/commit/e15b964) (nobilis).
`CHANNEL_RECIPIENT_ADD` and `CHANNEL_RECIPIENT_REMOVE` are handled, so a group message's member list now follows changes made anywhere - from a phone, or by another person in the group.
The roster on screen is edited rather than rebuilt: the event carries one user and not the channel, so there is no `recipients` array to re-derive from, and asking Discord for one would be a request per membership change to learn what the event already said.
The arithmetic is a pure function with its own tests, because it is the part that fails quietly - a list that grows a duplicate, loses somebody, or stops being sorted all look like a working member list until somebody counts. Removal runs on both paths for that reason: Discord can deliver a second ADD for somebody already there, and appending blindly shows them twice.
Somebody who joins arrives offline until `PRESENCE_UPDATE` says otherwise, which is how everybody else in that list arrived.
Verified offline only. This is receive-side, and the account that may send is in lockdown until the 15th.
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.
CHANNEL_RECIPIENT_ADDandCHANNEL_RECIPIENT_REMOVEare not handled - neither appearsanywhere in the Discord backend.
The asymmetry is what makes this a defect rather than a missing feature: moho can
change group DM membership itself, through
addToDiscordGroupDmandremoveFromDiscordGroupDm. It just never hears about a change made anywhere else.So a group DM's member list is correct only for the changes made from this window. Add
somebody from the phone and they are absent here, with their messages arriving from a
person who is not in the list, until the client reconnects and refetches.
Finished in
e15b964(nobilis).CHANNEL_RECIPIENT_ADDandCHANNEL_RECIPIENT_REMOVEare handled, so a group message's member list now follows changes made anywhere - from a phone, or by another person in the group.The roster on screen is edited rather than rebuilt: the event carries one user and not the channel, so there is no
recipientsarray to re-derive from, and asking Discord for one would be a request per membership change to learn what the event already said.The arithmetic is a pure function with its own tests, because it is the part that fails quietly - a list that grows a duplicate, loses somebody, or stops being sorted all look like a working member list until somebody counts. Removal runs on both paths for that reason: Discord can deliver a second ADD for somebody already there, and appending blindly shows them twice.
Somebody who joins arrives offline until
PRESENCE_UPDATEsays otherwise, which is how everybody else in that list arrived.Verified offline only. This is receive-side, and the account that may send is in lockdown until the 15th.