# Merging NT Chat Client and NT Messenger

We currently have two ways to send IC chat messages in the game: The old school way of sending messages directly to people (or sending a message to everyone), and the newer albeit less used way of creating chat rooms and sending messages through those.
Both really just fulfill the same purpose of sending messages to another user, even though they differ in the actual uses and implementation details.

We don't need two apps that basically do the same thing, it's just bloat.
So, here's a document to note down some ways to change that.

## The problem with just killing one off and keeping the other

Even though it's tempting to remove one messenger along with its features from the game for the other, you have to consider that each side fulfills a certain purpose.

For example, the direct messenger is your obvious private direct communication with another member on the station. It's very helpful if you need to talk with one person one-on-one to either get their attention or when you need a little privacy at a distance.

The chat client on the other hand allows for something else: Inter-departmental communication. The game adds a cargo chatroom by default, but realistically we can establish communication with other departments. What stops departments from creating official lines of communication to report problems to eachother?
The potential for this feature is not really as insignificant as it might seem at first. And people do use the chat client to communicate in groups, for roleplay and mechanical reasons. It'd be a shame to completely get rid of that.

So, killing each side off would not only be giving in, it would also be wasting a lot of potential.

## The problems with merging both together

Problems that we have to find a solution for, ranked from most important to least important.

### Account clutter

Merging both has one big issue: Account cluttering. We have established that the direct messenger list is for real crewmembers, and that's been like this for a long time and it shouldn't change. However, the chat client allows people to create arbitrary accounts for a legitimate reason. It's what lets you create department accounts and communicate by non-direct means. If we merge both clients though, we run into the problem of letting players create useless accounts that bloat the list.

This really is the big one that has to be addressed before we can merge both together. Here's a few solutions:

#### Every account is tied to a crewmember's ID, period

The idea here is to restrict accounts to physical IDs, and not letting people just create accounts out of the blue. This would mean that we have a department account that's tied to a type of ID (ie. you would need a head of staff ID to identify as that department).

This would limit definitely limit accounts while keeping up the departmental accounts. It won't allow for much else though. This idea would accomondate for what the code "intends" to do at the moment, but nothing more than that.

#### Accounts can be made freely, but are restricted in their ability

The idea here is to keep the ability to make arbitrary accounts, but don't allow them to interact with "real" accounts directly.

They can still exist in group chats, and can talk in there with real accounts, but they are not able to interact with them in other ways. This means we keep the messenger list clean, and we keep the gimmick accounts people come up with.

#### Accounts can only be made by one person in charge of the client

Have a person on the station be responsible for account creation. This ***does not*** solve the issue of people spamming accounts constantly, but it restricts how much they can spam, and lets administration pin the problem down more easily.

This is still arguably the worst solution, however, since it does not stop a clown from gaining access to the entire system and causing command or even the admin team some serious neck pain.

### Group chats superseding radio channels

Not really an issue, but still worth mentioning, is that we can replace radios with group chats.

However, radios are a lot simpler to use than group chats since you can use channel prefixes and such, which is a lot more important in high-stress scenarios. Additionally, not everyone has their PDA up all the time, while everyone in the game has a radio on at all times.

You can always place a restriction on how many people can be in a group chat.

### Choosing between two backend systems that serve the same purpose

Currently we have two systems: The NT Chat Client system which exists beyond telecommunications in the NT Relay, and the messaging server which holds responsibility over receiving, logging and delivering direct messages. One system definitely has to bite the bullet for this change. I would personally get rid of the one that exists beyond telecommunications.

One could also redesign NTNet to work through the telecomms machines (finally), and keep messaging going through telecomms.

### Picking an "admin" for managing group chats and communications

Curators and HoPs can strike down newscaster stories, so why can't a designated person do so with group chats too? However, do we retire the monitor key for an ID access, or do we give it to the RD or HoP or do we do none of these things and keep the job where it is at the moment?

Personally speaking, I like the idea of having a password that only one person can know, and I like the idea of splitting the responsibility into two different jobs, one side maintaining the system and the other side moderating everything inside the system.

## The proposal for a "merged" chat client

This is still a work in progress.

Features:

- Messenger/Chat Client available on all machines
- Users need to authenticate with their ID card but can do so at any machine
- Add two types of accounts: Verified and unverified accounts
- Verified accounts are your accounts created by having an ID card, and receive all features, being able to send everyone messages, creating joining groupchats, sending and receiving direct messages, with a requirement that you need to log into a machine with a physical ID card and having no choice over your username
- Unverified accounts are directly ported from the chat client. They can be used as a default account at any machine, but have the restriction of not being able to send and receive direct messages, only being able to talk in group chats they joined and only owning one group chat. However, they can freely choose a name at the accounts creation
- Unverified accounts are only available at modular consoles, and are tied to the machine when they are created. They can delete their account to reset their name, but this removes them from all group chats, and deletes the group chat they own
- Add group chats, either with limited space or no member limit
- Create default group chats to carry the cargobus over
- Add the ability to create new group chats that are not visible by default, but that can be entered with an invite code
- Merge both backend systems together to one physical machine in telecommunications
- Put a designated job in charge (ie RD, HoP) over moderating and reviewing messages and group chats
- More to come