BEC - What is these data and entities

2. What is these datas and entities

There are a lot of datas and a lot of entities that are involved in this chat. It's probably not as many as you are expecting when I say that. But it is still a lot.

A. Parasite (User)

This is the user entity. It's called a parasite because that's what a user is doing. Leeching all of the server resources in order to participate in digital social interaction.

A parasite has several attributes:

id: Traditional "username"/"user id". utf8 string, varchar(128) in db. must be unique
password: duh
username: This is used as a "display name". This must be unique, except that it can match this parasite's id.
email: ya
last_active: Timestamp of the last known activity for this parasite. This is used to filter parasites for display on the client.
typing: This is set to TRUE via a socket message. TRUE means a typing indicator should be displayed on the client.
status: One of: [offline/active/idle]. Set via socket message.

A parasite also has some optional settings, which are included in the parasite entity:

faction: Very important, it is the icon to use for this parasite's status in the user list. It shows when they are active. It is beautiful. Values correspond directly to font awesome 5 star wars icons. while any string is "valid", the ones that will actually work are: ['first-order', 'first-order-alt', 'empire', 'galactic-republic', 'galactic-senate', 'jedi-order', 'mandalorian', 'old-republic', 'rebel', 'sith', 'trade-federation']
color: Hex value of the color to display this parasite has chosen for their chat messages. There is no server side validation for the colors, but the web client displays a color picker with the following options that are relatively legible on a white background: ['#555555', '#ff5555', '#ee7733', '#0fba0f', '#10b1c9', '#5555ff', '#bc84e0', '#f27e95', '#775634', '#991111', '#aa3300', '#118822', '#186f7d', '#18187d', '#663388', '#b51ba6']
soundSet: Parasites can choose between AIM sounds and MSN sounds straight out of the year 2000. Therefore, valid values are ['AIM', 'MSN']. If an different value is set, the client should default to AIM. This is not negotiable. AIM is the default. Client code will not be merged into main if it is not using AIM as the default.
volume: Default client volume level. This is set whenever a clients volume changes. Clients can have local overrides for this value, but a connection from a new client will use this value initially.

B. Message

A message is the thing that makes this a chat. This is different from a "Socket Message" (see Section 3), which is what goes between the client and the server.

Messages are ONLY saved in memory. Server restarts clear ALL messages from ALL places.

Messages are partially sanitized by the server before sending out to clients. A preprocessing function is run on every message to do the following:

Find urls in the message body and wrap in <a>
Convert emoji shortcodes to unicode characters
Convert ascii emoticons to unicode characters
Escape any xhtml in the message if any unacceptable usages are found [script, audio, video, iframe, img]

There are three types of messages - 'chat message', 'private message', and 'image'.

i. Chat Message

Chat messages are what live in Rooms (see section 2.c). They have several attributes:

username: The display name of the parasite who sent them message. Not the id! The client doesn't have to figure it out. This preserves display name changes in the history.
room id: ID of the room the message was sent to. if this is not set, it means the message is "global", and goes to all rooms
message: Contents of the message
time: unix timestamp when server received message
color: color to use when displaying this message, based on the parasite's settings at the time the server received the message.

NOTE: Chat Messages that contain only an image URL will automatically be converted to Image messages, and vice versa.

ii. Private Message

Private messages are what live in Threads (see section 2.d).

A Private Message has the following attributes different from a Chat Message:

room id: A Private Message does not need a room id
sender id: there are two users in a thread, and knowing who sent or received is important
recipient id: same as sender id

iii. Image

Image messages contain ONLY media content. These messages can live in either Rooms OR Threads.

An Image message's attributes vary depending on the destination. Image messages going to a Room look like a chat message, and Image messages going to a Thread look like a private message.

NOTE: Chat Messages that contain only an image URL will automatically be converted to Image messages, and vice versa.

message: There is no message content, only image
image url: The original URL of the image. For image uploads, this will be the same as the image src url.
image src url: The URL used to display the image in the client. This is generally a URL pointing to the s3 bucket serving as the best evar image cache.
nsfw flag: If this is TRUE, the image should be hidden by default in the client (collapsed) and marked as NSFW.

C. Room

A room is a bucket of messages to which 1+ parasite have access. A room is created by a parasite, the "owner", who can also delete the room. Other parasites can be invited to the room, and can "Leave" if they join it. But only the original owner can delete it. The only room that cannot be joined, left, or deleted is room id 0, "General". This room has no owner and everyone is stuck in it forever. This forces public interaction.

A room has several attributes:

id: Every room has an unique id.
name: room names don't have to be unique. you can confuse the shit out of everyone.
owner: this is a parasite id. every room except "General" has a non-null owner.
members: A Set of the ids of parasites in the room. For room id 0, this is just everyone.
history: a deque of messages sent to the room, limited to the MAX_DEQUE_LENGTH (this is 200, but one day might be configurable). this always comes from the server sorted by time.

i. Invitations

Invitations are sent between clients to offer parasites to join a room. An invitation is sent from the server to the invitee's client An invitation is persistent - if a parasite is offline, the invitation will appear when they are next online, and will remain available until removed from the server by accepting to declining.

D. Thread

A Thread is used for Private Messages between two Parasites ONLY. The two parasites in a thread can never change. A unique thread is created as soon as the first Private Message is sent from either parasite.

A Thread has a few attributes, which are returned from the server in the context of the currently authenticated parasite:

messages: same as a room, this is a deque of messages sent to the room, limited to the MAX_DEQUE_LENGTH (this is 200, but one day might be configurable). this always comes from the server sorted by time.
recipient id: the parasite id of the OTHER parasite in this thread.

E. Alerts

Alerts are messages that are meant to be treated as "global" on the client. They are not meant for any room or thread, and come only from the server or client itself. Three types of alerts are defined by the server: ['fade', 'dismiss', 'permanent']. Other types of alerts, or differing alert behaviors, are client specific and not related to capital-A Alerts.

NOTE: Alerts are different from chat messages with no Room. Alerts should not be displayed in the message log, but in some other part of the client UI.

i. 'fade' type

Fade type alerts should display on the client when the parasite is actively using the client. The alert should fade after a resonable amount of time (web default is 3500ms).

ii. 'dismiss' type

Dismiss type alerts should stay visible on the client until dismissed.

This is not the same as an actionable alert. The web clients use these to display invitations and in the socket reconnect flow, but that is client specific implementation. Dismiss type alerts only have a 'Dismiss' action, and are for messages deemed more important from the server.

iii. 'permanent' type

Permanent type alerts should remain visible on the client until the client has taken whatever action is necessary to clear them. For example, a web client version being out of sync with the server results in the server sending a Permanent type alert to that client, which suggests that the client be reloaded. Permanent alerts should only be displayed when sent from the server or otherwise necessary for proper client functioning (e.g. the client is disconnected from the server)