Brave Chat

The ultimate open-source slack alternative.

Comment

Inspiration

We all rely on messaging applications developed by big tech giants such as Wattsapp and Slack without knowing how third parties store and manage our data. However, we can't deny that this makes us vulnerable to privacy violations. Therefore, as web developers, we should build an open-source chat platform that is the ultimate alternative to the closed-source ones. And that is how Brave Chat was born.

We believe in bringing back the power to people through open source. That's why we're building the ultimate open-source chat application for everyone. This allows a community of developers to work together to improve the software.

What it does

Brave Chat is a fully-featured real-time chat application. It's designed to become the ultimate open-source slack alternative with privacy in mind. It is user-friendly, with a clean interface that is easy to navigate.

As well as being feature-rich, Brave Chat is also fully responsive, meaning it will work seamlessly on a wide range of devices. So whether you're chatting on your desktop or mobile, you'll always have a great experience.

This chat app is built on the belief that privacy is a fundamental right. All the data should be encrypted end-to-end, so you can rest assured that your conversations are private and secure.

For detailed information about the supported features, you can refer to the official docs.

How we built it

At the start of this project, we decided to use only open-source tools because they are free and offer a high degree of flexibility. This would help keep our costs down while still providing a robust chat experience for our users. To store media files, we chose a Deta drive because it offers a free trial and easy-to-use APIs. For our message-sending needs, we selected Redis because it is fast and reliable. Redis was perfect for our needs because it allowed us to send messages to recipients in a pub/sub fashion. This meant that even if the user was unavailable, the messages would still exist and be delivered as soon as the user became available again. This ensures that no messages are lost and that our users always receive the information they need on time. More info can be found in the repos and the official documentation.

Challenges we ran into

We ran into numerous challenges related to SingleStore limitations, including but not limited to the following:

  • No support for foreign keys on COLUMNAR tables. This meant we had to use ROWSTORE tables, but fortunately joining tables still worked.

  • More than one FULLTEXT KEY is not supported by SingleStore. This necessitated writing a custom utility module to make it work as expected.

  • Writing to a reference table in a multi-statement transaction is not allowed by SingleStoreDB. In order to work around this, we used an additional SQLAlchemy engine.

  • A HAVING clause after a window function is not supported by SingleStore. Hence, manually looping through the data to group records having the same email.

Regarding deployment, we run into multiple issues documented in the readme file of the server. Thankfully, we could deploy both the server and the client on Heroku because it seems to be the only option to support WebSockets.

Accomplishments that we're proud of

We were successfully able to build a multi-node, real-time, highly scalable, deployable chat application from scratch using ReactJS, MUI, FastAPI, SQLAlchemy, WebSockets, Redis Pub/Sub, SingleStoreDB, and many more.

However, building a real-time chat application that scales horizontally can be challenging, and its complexity can take out of control. Still, it is possible to start by creating modular functions as microservices and making all the components loosely coupled. Achieving this, however, is both time-consuming and financially draining.

What we learned

We learned that relational databases are not the ultimate choice for real-time chat applications, but they are still powerful tools. We also learned that a key feature of relational databases is that they don’t give up on consistency, and data integrity. Additionally, we discovered that relational databases weren’t designed to be clustered, although it’s possible.

When building a chat application, you should take the following in mind:

Scalability: The database should be able to handle new data without performance degradation so you don't have to reconsider the solution again.

Stability: The database should be able to handle failures gracefully. Data should be replicated and backed up so that it can be recovered in the event of a failure.

Ease of use: Developers with decent experience using SQL databases should be able to use the database without needing to be database experts. The database should have an intuitive interface that is easy to use.

Low maintenance: You should look for something that is low maintenance and will just work once you set it up. This will help you keep your costs down and ensure that your database is always up and running.

Proven to work: You should look for something that has been tested in the field and proven to work.

What's next for Brave Chat

As mentioned in the readme file, Brave Chat promises the following:

  • Store message content in the database as encrypted data rather than plain text which can be accomplished through the signal protocol for instance.
  • Adding support for multimedia messages other than images such as PDFs, txt, and more.
  • Sending voice messages, voice calls, and more.

Built With

Share this project:

Updates