Currently there's a try statement in the client to detect whether a message payload is pure JSON (i.e. a message from SYSTEM) or is an encrypted blob (a standard message).
The problem with this is it's possible for an arbitrary client to push a cleartext message (it won't display as being from SYSTEM but is still a concern).
So, SYSTEM should really use some form of E2E encryption.
The problem with this is the server does not (and should not) know the room key, so we cannot encrypt with the same key as standard messages use. Even if we could, we probably shouldn't.
Needs some thought, but my initial suggestion is that at room creation, the server generate a key for SYSTEM to use and store it in the rooms table.
When a user joins the room, they should be passed the SYSTEM key.
When returning messages in pollMsg there should be a flag to indicate whether the message is a system message or not. If the flag is 1, then the SYSTEM key should be used, if not the standard room key should be used.
This offers limited protection if someone takes a memory dump on the server - the key will also be in memory, though they won't immediately get a plaintext dump of SYSTEM messages. It's aim is purely to remove a potential loophole/vulnerability in the client.
Client's will, of course, have access to the SYSTEM key, but should be entirely unable to affect the flag returned in pollMsg to trigger it's use when decrypting their message. As a precaution though, the flag should only ever be used to select the decryption key, and not to identify whether it's a SYSTEM message or not.