Dear Finxter community,
Most of you will not know me, so I’ll give you a quick introduction.
About Me
My name is Tom, and for the last 6 months, I’ve been teaching myself programming. Primarily Python with some web frameworks (Flask, FastAPI, Streamlit) thrown in for good measure. I’ve found I love the way you can create something new from an idea or even a stray thought. That fact is also what drove me to start learning programming in the first place.
Every one of us knows the feeling that a certain solution for a certain problem doesn’t quite cover all its bases. If only you could adapt or change a few things… That feeling, that urge to solve the issue, is what drives me. And as I grow more adept in this, I admit that the satisfaction gained from it keeps growing also.
It is the drive to learn that brought me to the Finxter blog and academy. I had been scouring the web, looking for learning platforms, tutorials, etc. After opening the site for the first time and having a quick read, the community aspect immediately appealed to me. The way it both has a thriving community while also being driven by it kind of puts it in its own category. I am quite certain that is why I decided to join the mailing list, looking back.
Fast forward to the start of 2023. Chris sent out the first of his 100 programming challenges for the new year. I jumped on the first challenge to create an interactive web app. I was learning Streamlit at the time, and my application made the shortlist. The email that contained that shortlist also first mentioned the idea for an application created by the community. I got hooked on that idea immediately. I shot off a quick email to Chris saying I would like to take part in this very much, whatever it turned out to be. Little did I know what I had gotten myself into 🙂.
The PeerBrain Vision – A Decentralized P2P Social Brain Network
It was a couple of weeks later when Finxter sent out the update email with the idea for Peerbrain/Brainwaves. A decentralized P2P application for sharing messages/tweets. An application without possible interference from governments or companies. I loved it!
The only problem was I had no idea in hell how to go about it. So I started researching existing applications or frameworks that were trying to achieve this. The Matrix project is the biggest one. I dove into the documentation and came out knowing two things. The guys who designed this are very good at what they do. The other thing was that I did not even understand half of what I would need if I was to try and use it. I also did not like using something that was already far along in development if I look back now. I wanted to be able to go through the entire process and see how every part of it worked.
After this, I decided that I could not find something that suited the needs I felt the project had. So I started designing and developing it myself. When brainstorming about how the application should work, I realized we had a problem. An application used by thousands or more people needs an always online component. There needs to be a sort of “base” that will make sure everyone that wants to connect to someone else can do so.
Finding Inspiration in Torrents
I found a lot of inspiration in how torrents work. The torrent tracker is a server that facilitates communication. It is an intermediate between the users (peers) who want to share files with one another. The actual sharing of those files is a P2P process. But the process would not be possible without the help of the trackers.
I transferred this concept to the current project. It meant we needed a server that would allow users to communicate with each other. As Python is my programming language of choice, I needed something that could do this. After some more research, I found the FastAPI framework. It fit all my requirements for a server, and I decided to give it a go. As I had never used it before, more research became my next goal. I am sure some of you will spot a trend by now😀.
After a few days of coding, and some emails back and forth between Chris and myself, I started to realize some things.
The first was that this project would be way more complex than I ever imagined. I didn’t and still don’t really feel comfortable trying to build it. I do find that solving certain problems keeps giving me the motivation to continue. As long as this is the case, I will find the motivation to step over my impostor syndrome.
Another thing, and this one is more important, is that the P2P model would not work. Or at least not the part of storing the messages on local machines and not in the cloud. We live in a time when people log in somewhere with certain expectations. They want all their settings already in place, their contacts synced, and their data ready to consume. Storing everything locally would be a huge step back in their eyes. And I am quite sure that if we want this to succeed, we’ll need a lot of people! So it was back to the drawing board to change the application logic to consider this.
Where to Store Messages?
The first thing I am focusing on is the possibility of creating messages/tweets that your friends can read. The solution I found was that storing the messages locally to avoid tampering with them was not viable. Because of this, the messages themselves needed to be protected. If the messages exist on a server, we need to take this into account. This means making sure that even someone who controls the server could not read the contents. This means encryption and, more specifically, end-to-end encryption.
Let me tell you all, encryption is complicated.
I’m sure I am still only skimming the surface of it, but I found a working solution. I got inspiration from how both Apple and Owncloud encrypt user data. In short, the application will use both an RSA keypair and a symmetric key to ensure the security of the messages. The original idea was to only use one API server but this started to pose many problems almost immediately. Messages need to be always available. And new friends want to read messages created before they become friends with the user who created them.
So the solution for this was to split the functionality.
The main API server will store the encrypted messages and user objects. Within those objects, we define the user parameters and the friend relationships. It will handle authentication and user creation.
The second server will hold an object per user that contains the following: a username, a user password hash, their public key and their unencrypted symmetric key. This key is what gets used to encrypt any message the user creates.
Once a user has requested an encrypted copy of a friend’s symmetric key, this will also live within the object, to make future requests more efficient. Otherwise, the second server would need to re-encrypt that key every time a request comes through.
And it is at the end of this very long explanation that my question comes to you, dear Finxter community.
We, a few developers who have already joined, need your help. To develop this further, we need people who can test. And more important, people that break the application! We need to iron out the bugs and test it under load.
Clone the GitHub & Join Discord 👇
That is why we would appreciate it if you clone the Github repo and try to run the client application. We need people to register an account, add friends and create and read messages.
🧑💻 GitHub: https://github.com/shandralor/PeerBrain
If you feel like this applies to you, please join the discord server! You can find all the resources there. You can also ask any question that you have.
I would like to thank you all for reading this and helping us out if you want to!
Sincerely,
Team Peerbrain