stardance has been extended another month! the new deadline is october 31 :)

You are browsing as a guest. Sign up (or log in) to start making projects!

Simple Chat

  • 6 Devlogs
  • 23 Total hours

A TUI-based chat client for local networks, featuring encryption and host configuration (slightly) similar to ssh

Ship #1 Pending review

Simple Chat

A TUI-based chat client and server for local networks, featuring encryption and ssh-like host configuration.


simple-chat lets you chat with others on the same network (a LAN, a tailscale tailnet or similar) via a simple terminal UI.
It requires no classical internet connection (in the sense that you have to be able to reach the world wide web like google.com or similar), no accounts and no third-party servers. You control everything, and you’re the only one who sees the messages unencrypted.


How to get it working quickly

Begin by downloading the executable. Then, open a shell in the directory where the simple-chat or simple-chat.exe file is located (or open one via the start menu and cd into the folder where the file is). You will also need multiple shells for this; at least two (one server and one client) but I recommend testing with three to have two clients join onto one server.

First, you need to create a server:

./simple-chat server --new <name>

You will get an encryption key and a QR code. You need to copy or note down the encryption key. When scanned, the QR code also contains the encryption key.

Then, you need to register the server so the clients can connect to it:

./simple-chat client --add <name> --address localhost

<name> doesn’t need to be the same name you used in the first command, but I still strongly recommend it.

Now, we wanna start the server:

./simple-chat server <name>

You should see something like Running as server on port 42003.

Now, in a second terminal, type:

./simple-chat client <name> --name "Testuser-1"

Then, you should see the TUI pop up. If not, use the README and the docs in the GitHub repo to troubleshoot.

Note: In the above command, we’re using the explicit --name flag because if we want two clients on the same machine, they would try to load the same name from the configs. Therefore, we need to explicitly assign two different names via --name.

If you want a second client, run the following in a third terminal:

./simple-chat client <name> --name "Testuser-2"

Additional Info for the above guide

In all of the commands, you should substitute <name> with the name for the server, for example Testserver. I recommend you use the same name everywhere, although you CAN theoretically give the actual server and the client-saved server a different name.


Thanks for reading all this if you came to this part and have fun! :P

  • 6 devlogs
  • 23h
Try project → See source code →
Open comments for this post

3h 4m 37s logged

Final Touches

Simple Chat is now basically finished after some final touches. Lots of fixes have been made, along with adding more documentation.
Here’s a quick changelog:

  • Fix issue where invalid timestamps would panic all clients which received them
  • Fix key inputs being registered twice on windows
  • Check user name length properly
  • Fix multi-line message drawing logic
  • Add a timeout for the initial handshake (5s)
  • Validate chat messages and user names for control characters
  • Write the timestamp on the server-side to prevent spoofing
  • Fix CTRL+C not quitting the TUI
  • Add a TUI message backlog limit
  • Fix the TUI text input box (wide chars now work properly)
  • Update documentation
  • Fix a few other minor inconsistencies
0
0
7
Open comments for this post

3h 41m 56s logged

Packet Types

After a (way too long) pause, I’m finally working on Simple Chat again. I’ve added a packet enum, which wraps all possible kinds of data communication.


What this means

Basically, now everything that’s being sent has the same interface: serialize and deserialize. You don’t need to worry about what is in this packet, just serialize it, encrypt it and it works.

This means handshakes aren’t loose bytes being sent between client and server and held together by pure hopes and dream (im praying somebody gets the reference), but instead a proper packet, which can also now be encrypted.

Heartbeats

Previously, there was also a big design flaw. If no message was being sent, you couldn’t tell if the others were just not sending anything or had already (uncleanly) disconnected. The TCP stream looked the same in both scenarios. Because of this, I’ve added a Packet::Heartbeat type. It contains no data, and if it gets received by any party, (almost) nothing happens. It’s sole purpose is to keep the stream alive.

Now with this, lets say we’re the server: a client doesn’t send a heartbeat twice. We now know that they’ve likely crashed or not properly disconnected in some other way. Because of this, we can now kick them instead of keeping a connection live.

0
0
6
Open comments for this post

8h 30m 35s logged

Server Rewrite!

I’ve rewritten the server using Tokio instead of Threads for improved performance and less server-side overhead.

What Tokio is

It utilizes Rust’s async implementation with futures to create a much more lightweight alternative to threads. Basically, you can summon multiple tasks and instead of them being full threads with seperate 8MB stacks and so on, they have way less context switching overhead and a much smaller stack per instance.

Other Server-Side Changes

In the initial handshake, the client provides its name to the server. If the server receives a message with the wrong name from that client, it will replace the name with the originally given one.


Encryption

I’m still working on finishing up encryption for all messages and the initial handshake.

3
1
75
Open comments for this post

2h 9m 54s logged

im almost done already what

So… it kinda works????
The client AND server, the TUI, the new message structs and all of that work now.

Changelog

  • Reworked Message Struct(s) and multiple message types (Chat, System)
  • Proper connect handshake
  • Rework server to use SystemMessages to broadcast client connect/disconnect events

What’s planned

  • A config file to store your name (~/.lan-chat)
  • Encryption (between clients)
0
0
13
Open comments for this post

1h 6m 40s logged

TUI Time! :)

The TUI works now, I only need to polish it (stuff like scrolling when message box is full)


Additonally, I’m planning to add a special kind of message that the server sends on client join/leave events.

0
0
13
Open comments for this post

4h 27m 44s logged

New Project!!

This is LAN Chat, a TUI chat messenger to use in the same LAN as others.

Build using Rust with ratatui (a TUI library)


Currently, I have a working client/server system, which sends serialized message structs. Next up, I’m gonna work on getting the TUI running.

0
0
63

Delete project?

Are you sure you want to permanently delete this project? This action cannot be undone.

All devlogs, followers, and associated data will be removed.

Followers

Loading…