Good day!
I would like to share interesting thoughts with the community on creating offline decentralized email and demonstrate the practical work of an already existing implementation.
Originally, Telegraph was developed as an amateur communication tool between members of our small student community, which devoted its activities to computing and communications in one way or another.
Nota Bene: Telegraph is an amateur communication tool; extracting practical benefits on an industrial scale appears quite problematic, however, this issue can hardly be considered significant β primarily, our main goal is to draw attention to the development of such communication systems.
We tend to believe that increasing overall interest in the development of various communication systems is necessary and quite important, as understanding the fundamental principles of how these systems work and what they are based on is the key to raising public awareness on information security.
Attention!To avoid possible misunderstandings β in some cases, images can be scrolled:
The system operates on a voluntary basis and pure enthusiasm β we simply enjoy what we do. You could consider this a hobby and you would not be wrong β as there are still enthusiasts of communication through paper correspondence; Telegraph can be viewed mostly as a digital realization of the principles of traditional mail.
Telegraph is an offline equivalent of email that allows the transmission of simple text messages without using the internet. Telegraph can be somewhat related to β a method for exchanging information without using a network.
Flash drives are used as mailboxes, while terminals β computers, act as postal offices, serving as access points for receiving and sending electronic correspondence.
Let's consider a simple example of interaction with the system. We have two flash drives and one terminal available. The script contains the necessary global variables for subsequent interaction with the system β terminal number, path to the root, and so on.
If we connect a removable storage device to the terminal and run the script, it will attempt to retrieve outgoing messages from the directory /mnt/Telegraph/Outbox and transfer them to its memory, after which it will check for the presence of new messages in its memory for the current user. If there are any β it will write them to /mnt/Telegraph/Inbox.
Registration of new devices
occurs in a rather mundane manner. The script finds new flash drives connected to the system and attempts to match their unique identifiers with those presented at the root. If the devices have not been registered before, they will be formatted according to the rules stated by the 'Telegraph.'
After registering a new device, the root structure takes the following form:
In the configuration file config.ini, located at the root of the flash drive, there is system information β a unique identifier and a secret key.
Give people rum!
Really, I'm serious! The source code can be obtained , and it's about time we moved from theory to practice.
But I must say a few more words about how the messaging system works in practice.
First, let's analyze what a twelve-digit unique identifier consists of. For example, 10455000001.
The first digit, 1, represents the country code. The international code β 0, in this case Russia β is 1.
Next are four digits representing the region number where the terminal is located. 0455 β this is the Kolomna urban district.
Following them are two digits, β 00, β which correspond directly to the terminal number.
And then there are four digits that represent the sequential number of the user assigned to this terminal. For us, this is β 0001. There is also a 0000 β this number belongs directly to the terminal itself. It cannot receive written correspondence, but the terminal uses this number to send administrative messages to users. For example, if a message could not be delivered for any reason.
At the root of our 'mailbox' are two directories needed to send and receive text messages. When a device is connected to the terminal, outgoing messages are dispatched from the 'Outbox' directory to the server, and incoming messages are logically loaded into the 'Inbox' directory.
Each file is named according to the recipient's or sender's number, depending on the directory.
If we attempt to send a message to a non-existent address, the terminal will send us an error message.
However, if we decide to send a letter to a recipient on another terminal (regardless of whether that terminal exists or not), it will be recorded in the terminal's memory until the agent transfers the written correspondence from our terminal to theirs.
When the branch agent 10500000000 (in other words β the postman) connects their device to our terminal, the outgoing letters will be sent to their storage. Later, when they connect their device to their terminal, these letters will be dropped into the terminalβs memory and will wait for the recipient to download them to their flash drive.
Communication session
Letβs try to send a message with the text 'Hello!' from 10455000001 to 10455000002.
Thatβs all!
I welcome any criticism regarding the project's source code and the article itself.
Thank you for your attention.
Source: habr.com
