I've wanted to support this for a long time, but had a hard time figuring out how I wanted to implement it, exactly. I prefer to add features in a generic way where lots of different use cases can fit into the same thing, to keep the overall protocol feeling clean and consistent if possible. I also try to avoid making breaking changes, which means I'd ideally do it right the first time.

Original idea

I thought about adding some sort of system specifically for chats, but that would duplicate a lot of the stuff that was already there. I thought about even having a window you could pop up that would connect to my IRC server, but that seemed silly, and would limit what kind of improvements I could make over what IRC is able to do.

I realized awhile back that, conceptually, maps are fancy chatrooms; you can visit them, see who else is there, and send messages that everyone else in that location can see. So it makes sense to build on that. So I thought it would be cool to have it where you can control multiple characters across multiple maps, and server-wide chats would involve putting a character (or a copy of a character) in a map that's agreed upon to be a chat, with other people doing the same thing.

But that feels like vastly over complicating everything and it would make clients handle a lot of tricky stuff that I don't think a client should have to support, and as cool as it would be it'd probably look clunky and confusing to people.

Simpler idea

Yesterday I realized there's a simpler solution that also builds on the concepts already there: There's a system in place for remotely listening in on events that happen on other maps, and remotely doing actions on other maps, including sending chat messages. This was originally set up with the idea that you would have a bot account sitting somewhere and it would remotely handle bot stuff in however many maps. You could technically already use this system for chats, if multiple people listened to chat on some remote map and remotely sent chat into it, but this required permissions to be set in a way that wasn't preferable, so I fixed that.

Now non-registered users can listen for events on other maps, and the maps themselves don't have to even be maps, nor do they have to exist in the database. There's a remote_chat permission you can set on entities, and with that permission, you can listen to chat messages that happen inside the entity, remotely send chat into the entity, and find out who else is listening for chat in that entity, and no potentially unwanted extra permissions. The ability to see who else is listening for chat gives you that "member list" feature of a chatroom.

Result

So the end result of this is that any entity can be a server-wide chatroom if its owner wants to opt into it being one. You can have an actual persistent entity like a user group be one (and you can set it up so that being a member of the group gives you access to join the chat), or have a map that you can visit and talk in alongside people talking remotely, or you can just make a quick temporary object that can act as a temporary party chat, or whatever really.

Now it needs support in the client, and commands for more easily working with this, like the ability to kick people from one of these remote chat setups. Those can come later.