Good afternoon!
I'd like to share some interesting thoughts with the community about building a self-contained decentralized email and demonstrate how one existing implementation works in practice.
Initially, the Telegraph was developed as an amateur means of communication between members of our small student community, one way or another dedicated to computing and communications.
Note: "Telegraph" - an amateur means of communication; it is quite problematic to extract practical benefits on an industrial scale, but this problem can hardly be called significant to any extent - we consider our main goal to be directly drawing attention to the development of this kind of communication systems.
We tend to believe that increasing the general interest in the development of various communication systems is a necessary and important thing, because understanding the fundamental principles of how these systems work and what these systems are based on is the main key to raising citizens' awareness of information security issues.
Achtung!To avoid possible misunderstandings, in some cases, images can be flipped:
The system is based on volunteerism and pure enthusiasm - we just love what we do. You can consider it a hobby and you will not be wrong - after all, there are still lovers of communication through the use of paper correspondence; Telegraph, in most cases, can be imagined as a digital implementation of the principles of regular mail.
"Telegraph" is a standalone analogue of e-mail, which allows you to send simple text messages without using the Internet. "Telegraph" to one degree or another can be attributed to - a way to exchange information without using a network.
Flash drives are used as mailboxes, and terminals act as post offices - computers that are a kind of access points for receiving and transmitting electronic correspondence.
Consider the simplest example of interaction with the system. We have two flash drives and one terminal available. The script itself contains the necessary global variables for subsequent interaction with the system - the terminal number, the path to the root, and so on.
If we connect a removable drive to the terminal and run the script, it will try to receive outgoing messages from the directory /mnt/Telegraph/Outbox and transfer them to your memory, then check for new messages in your memory for the current user. If there are any, write them down. /mnt/Telegraph/Inbox.
Registering new devices
It happens quite randomly. The script finds new flash drives connected to the system and tries to match their unique IDs with those present in the root. If the devices have not previously been registered, they will be formatted in accordance with the rules declared by Telegraph.
After registering a new device, the root structure takes the following form:
In the config file config.ini, located at the root of the flash drive, contains system information - a unique identifier and a secret key.
Give the people rum!
No, really, seriously! Sources can be obtained , and it is already time for us to slowly move from theory to practice.
But I have to say a few more words about how the messaging system works in practice.
First, let's figure out what an eleven-digit unique identifier consists of. Eg, 10455000001.
first digit, 1, is responsible for the country number. International code - 0, Russia in this case - 1.
Then there are four digits that are responsible for the number of the region in which the terminal is located. 0455 is the Kolomna urban district.
They are followed by two numbers, 00, β directly responsible for the terminal number.
And only then - four digits, which are the serial number of the user, which is assigned to this terminal. We have it - 0001. Also exists and 0000 - this number belongs directly to the terminal itself. You cannot send written correspondence to it, but the terminal itself uses this number to send service messages to users. For example, if the message could not be delivered for some reason.
At the root of our "mailbox" there are two directories necessary in order to receive and send text messages. When the device is connected to the terminal, outgoing messages are downloaded from the βOutboxβ directory to the server, and incoming messages are loaded into the βInboxβ directory, which is logical.
Each file, depending on the directory, is named by the number of the recipient or sender.
If we try to send a message to a non-existent recipient, the terminal will send us an error message.
However, if we decide to send a letter to an addressee located on another terminal (regardless of whether it exists or not), it will be written to the terminal's memory before the agent transfers the written correspondence from our terminal to his.
When the branch agent 10500000000 (in other words, the postman) will connect his device to our terminal, outgoing letters will be transferred to his drive. Subsequently, when he connects his device to his terminal, these letters will be dumped into the terminal's memory and will wait for the addressee to upload them to his flash drive.
Communication session
Let's try to send a message with the text "Hello!" from 10455000001 ΠΊ 10455000002.
That's all!
I will be glad to any criticism of the source code of the project and the article itself.
Thank you.
Source: habr.com