June 18, 2025
Worked on the style of the chat windows: added chat bubbles.
The colors are based on a username ash, so the same username will always have the same color on all clients without needing to transmit additional data.
If you like, take a look at the subtle color gradients: what looks like gray/black isn't!
Now i will style the text input, for now I'll put it at the bottom, then I'd like to put it inside the bubble I'm writing in (maybe).
Now you can create and join rooms all with QRCODES!
(You can see a demo with real phones in the video attached)
Also i'm starting doing some graphical stuff.
This version still doesn't include encryption. When i will put the encryption the QRCODE part will be in both way: i want to use a hybrid encryption.
There are still lot's of other improvements to do but i can say that this is the first really usable version of the client!
I decided to deploy the client. Easy, right? But no, because I decided to do something cool and not include the file name in the URL, so I'd get client.chatinrealtime.com/chatlist and not client.chatinrealtime.com/chatlist/index.html. But there was a problem: when I was working with the local live server, the scripts were served correctly (as I intended), but when I used render, the ./ from client.chatinrealtime.com/chat_list was the root and not /chat, so the script always needed to be in the root.
After about thirty minutes of debugging and four merges on GitHub, I figured out what the problem was and fixed it.
As you may have read, I registered the subdomain where I host the client if you want to use the hosted client and not a local one or your own.
You can reach him at client.chatinrealtime.com
I hope to implement message storage in the client soon so I can then focus on:
1. encryption
2. graphics
3. improved UX (I'll work on the QR code join later)
I'm sorry it only shows 6 minutes of work, but that's the time I spent writing code, not all the rest of the time I spent debugging :(
Incapsulated the chat code in a class
Now the web client can send and recieve messages (typing and finish)
The next things will be:
1. proper visualization of messages outgoing and ingoing
2. memorization in local db of messages, rooms and users
3. encrypting and decrypting of message payload
Started writing the socket client.
Now the client can connect to the server websocket and and authenticate by sending as first message the api key.
I will incapsulate things in a class as next thing to better manage the code.
The next steps will be:
- refactor the current socket code in a class
- write and recieve messages
- store messages in a local database
bye for today :)
Started writing the Web App to use my previously written API for real-time chat.
Before i wanted to write an Androdi Client but the Android ecosystem was too demanding.
This first part of the web app allows you to create your own user account and create a room.
The next thing I'll work on is joining a room, and then I'll start working on the page that allows you to write and receive messages within a room.
For now, the web app will be as graphically simple as possible: I want to focus on creating a deployable version as quickly as possible.
Changed the hashing algorithm that enables the program to understand whether a video has already been transferred or not:
now the program only looks at the file lenght and the modified time and not make an hash of the file content. In this way scanning new videos is way faster.
Also fixed things about HW acceleration and deinterlacing (now using CPU for deinterlacing and GPU for transcoding) and added HW acclration also for H265 with CRF.
The next thing to do is to crate a way to store information about the transferred videos like codecs and pathnames for each version to enable further elaboration and visualization.
The goal of RealTime is to see what is being written character by character: you can almost double the speed of communication! RT wants to go beyond this and make you feel in front of your interlocutor. Thanks to its human-centered design, animations and its "organic interface". RealTime doesn’t aim to replace existing and widely used messaging systems but rather to be an extension to them. Features: 1. Real-time typing 2. Physical proximity for contact 3. Open source and well documented Coming features: 1. Live voice messages 2. Live images 3. E2E encryption 4. Export JSON and nice PDF
This was widely regarded as a great move by everyone.