Hi, @liebus!
May be you could try to think of the behavior of the application:
For example:

• messages are stored in the Chat.Server
• users can read them from there
• users can join the Chat.Server and then they will get “notified” about new messages
• users could store a number of unread messages associated with a chat

Then model the interface first.. (without implementation.. just as in TDD)

For example:
Say Chat.Server holds the list of users and the list of messages.

{:ok, chat} = Chat.Server.start_link()   # chat is a pid of Chat.Server

{:ok, alice} = User.new(name: "Alice") # alice and bob are pids of Users
{:ok, bob} = User.new(name: "Bob")

:ok = Chat.Server.join(chat, alice)
:ok = Chat.Server.join(chat, bob)

# check the list of users
users = Chat.Server.list_users(chat)

# assure that both Alice and Bob are there
alice in users == true
bob in users == true

# send a message from Alice
Chat.Server.send_message(chat, "Hi, there", from: alice)

# check that Bob got an unread message
%{chat => 1} = User.unread_messages(bob)

So Chat.Server’s initial state might look like %{users: [], messages: []}
Chat.Server.join/2 would update that state adding user to the list.
every Chat.Server.send_message/3 will add message to the list and also broadcast a “notification” to all users, except the user that message came from.

User is also represented as a process that holds a map with chats and the number of unread messages. So that when it receives a notification from a Chat.Server it increments it.

BTW, it would be good if you convert that example to ExUnit test case and keep adding your testing examples and just run mix test to make sure it all works as expected =)

In more realistic scenario when multiple users interact with single Chat.Server fetching the list of users and the list of messages - you would want to move those lists to the DB that provides with concurrent access and keep Chat.Server as an interface to that DB. I think that might be a good example to learn a little bit of :ets