Decentralized P2P Social Nets
When I saw the Finxter announcement about trying to create a decentralized P2P social network, I knew I had to take part.
My interest peaked as it had seldom been before. I love the idea of a social network that can function without interference from companies or governments. It feels like something the world needs.
On why someone did not build it yet, I don’t have a definitive answer. The only thing that occurs to me is that there is no real demand for it (yet). There might actually be some active pushback from major players in the field.
From Matrix to FastAPI
From a financial and monetization point of view, such an application is not very interesting. It would be very difficult to push ads on people as there would be no central control over the network. Which suits me fine :-).
To be honest, there are some standards that are very well developed and so far along that they are production worthy. I’m thinking of the Matrix API.
The problem, at least as far as I am concerned, is that it is difficult to get working. I spent a couple of hours trying to get through the documentation. In the end, I was not sure I understood it better than at the start. So complexity is a definite issue; I’ll have to keep that in mind.
After some emails going back and forth between Chris and myself, we arrived at the following conclusion.
The basic idea for an initial version of the app is a web-based, decentralized tweeting application. So far, so good. Now I needed to do (a lot of ) brainstorming on how to set this up.
As you might have gleaned from my previous articles, Python is my language of choice. I like HTML and CSS too, but not at the same level. So I continued my search for something that could both supply the functionality needed and still allow me to use Python.
The result of that search is the FastAPI framework.
This framework immediately piqued my interest immediately. I’ve been delving ever deeper into its uses, and I am convinced it will work well. The more I learn, the more I am reassured this could be the reliable server-side for the P2P social network we need!
The Role of Servers in P2P Systems
The next question now is: how I can go about doing that?
I discussed this with Chris some more. He posed the justified question of why we need a server for a P2P application.
The problem with P2P at the moment is that we are all still using IPv4. The problem with IPv4 is that we only have a limited amount of addresses available. To address this, there are certain workarounds used everywhere.
NATs and rotating public IPs are the default way of “solving” this problem of scarcity. NATs and their private IP address ranges do pose problems.
When clients want to connect to each other, they need to traverse those NATs. Connecting to the outside from within the NAT is not a problem. Finding someone else behind their NAT is something else.
Added to this comes the fact that providers also rotate IP addresses. So, in the end, you are never certain where to find someone exactly 🙂.
Relay Servers in P2P Systems
This is where the “relay” server becomes important. It can be hosted on a server with a static IP, which means it will stay in one place, so to speak. By adding the option to our application to enter an IP or domain name, we will be able to connect to it. Once the connection is active and client details exchanged, we could, in theory, cut out the server.
Direct contact between the two clients would then become possible. It is an approach I will look into more in the future. But for now, I find it to still have too many uncertainties to get it to function reliably. A great article about this can be found here.
So, how to solve this problem?
Let us look back to what we wanted to build. The purpose of this project in its first iteration is the following. We want some version of a “decentralized P2P application that would allow some form of tweeting”.
A Word on Torrents
When I hear P2P, I can’t help but think of torrents. A vital part of torrents is the tracker. According to our good friend ChatGPT, a torrent tracker is:
💬 Definition: A torrent tracker is a server that helps in the communication between peers using the BitTorrent file sharing protocol. It keeps track of the peers participating in a specific torrent “swarm” (a group of peers sharing a particular file. This facilitates the distribution of the file and allows peers to find each other.
It’s important to note that torrent trackers do not host any files themselves. Nor do they guarantee the availability of a particular file. They ease communication between peers and provide information about the location of seeds and peers.
This is the point where I am of two minds.
Implementing the application as a true P2P torrent equivalent could certainly work well. It would, however depend on the app running constantly. This is because it needs to serve its “tweets” or messages when requested by other interested clients. It would also need a constant network connection.
The other idea I am playing with is finding a way that would allow for the storing of messages on the relay server.
They would need to be encrypted, so it would be impossible for someone who had or gained control of the server to read them.
For this to work, a cryptographic key must be exchanged when you “befriend” someone on the system. This key would allow for the decoding of those messages when you request them from the server. After decoding, you could then read them.
To me, the second approach feels more reliable to put in place. Especially when considering that it will allow for a proof of concept to be developed easier and faster.
Reliability is a big factor in that. Having decided this, I know what I have to do!
The second article in this series will focus on coding out both the basic server and CLI client. See you soon!
You can also check out the next tutorial on the Finxter blog about how I chose a server for the P2P project.
💡 Recommended: BrainWaves P2P Social Network – How I Created a Basic Server