jdev - 2026-08-14

last message correction obviously says that clients should only requests corrections to a message if the user sending that correction is the same person that sent the original message. i assume that clients also compare occupant ID in order to prevent against nick takeover attacks. but what are you supposed to do if a room has no support for occupant IDs?

> last message correction obviously says that clients should only requests corrections to a message if the user sending that correction is the same person that sent the original message. i assume that clients also compare occupant ID in order to prevent against nick takeover attacks. but what are you supposed to do if a room has no support for occupant IDs? > in MUCs and MUC-PMs the correction's full-JID must match the original full-JID, and the recipient needs to ensure that the real bare JID of the sending occupant didn't change in between, e.g. by keeping track of leave/join presences > When used in a Multi-User Chat (XEP-0045) [3] context, corrections must not be allowed (by the receiver) for messages received before the sender joined the room - particularly a full JID leaving the room then rejoining and correcting a message SHOULD be disallowed, as the entity behind the full JID in the MUC may have changed. i assume these are the relevant bits ↺

Sunglocto: don't check it, or do not allow corrections

Or track joins ans leaves

But to be honest, LMC has great fallback ✏

I would simply not allow corrections in such a room, and only implement occupant id