Dcomms.org Why Dcomms
How it works
Binaries for Windows
Binaries for Mac OS
Source code

Dcomms.org - blog


I am Aleshin Sergei Vladimirovich, software developer and entrepreneur. You can contact me via LinkedIn.


The P2P network is being always tested, since 2020-02. So far no failed test messages between simulated users. Also no memory leak, no crashes in the code. There are minor errors though, I will have to fix them.
Recently I have been working on this website. Submited the messenger app to various catalogs, this can bring some traffic and backinks. I am targeting SEO keywords "decentralized messenger", "peer to peer messenger", "open source messenger", "raspberry pi messenger", "ubuntu messenger". Now there are 2-5 website visitors per day, and I am not sure how many users of the messenger. Waiting for some feedback.

Talked to some friend via "Messenger T", so getting first users to use the messenger.

I released the very first version of "Messenger T" for Linux, Raspberry Pi and Windows, please have a try. Now preparing docs and minimal tutorials.

I designed a SQLite database, and created 2 prototype projects for the decentralized messenger:
1) "MessengerT" = "Messenger for technical people" - it is a .NET core executable, cross-platform (Windows, Linux (Ubuntu, Debian, Raspberry Pi, Nano Pi), MacOS) with a web UI. The "web UI" is accessible via browser only from localhost.
2) "MessengerA" = "Messenger for regular people, alpha version" - Xamarin Forms cross-plaform application (Android, iOS)
There will be more "types" of the messenger, using same core. I will implement some features of facebook, instagram, youtube and create a decentralized social network where people will share content without ads and without possibility of spying.
One more thing I discovered: there are cheap nano pi NEO AIR IoT devices with wifi, bluetooth, ARM CPU and Linux. My further goal will be to develop a version for "nano pi" and support voice over bluetooth. This "crypto device" will be cheaper than regular Android phone.

I develop the Dcomms project in a "test-driven-development (TDD)" way: I have "Proof of Concept" project, and it contains "DRP Tester 1...5" sub-projects. DRP = Decentralized Routing Protocol, my new crypto peer-to-peer protocol that runs over UDP. The projects simulate real-world environment, starting from easiest DRP Tester #1 (with 4 peers only and 1 message between them) to DRP Tester #5 (it is close to real mobile app, a messenger). The DRP Tester #5 sends messages to another DRP Tester #5, and waits to receive same echo message back. It measures percent of successfully delivered messages, and delay. I run DRP Tester #3 at 4 servers now (each server simulates 3..10 "entry peers", 10..20 users, 10..20 temporary peers). So it is a "sandbox" p2p network with about 120 peers at 4 servers, one Windows PC and one Android phone.
What I discovered: Few things about my development style: Next things to do: Full TODO list contains about 500 items.

Sucessfully simulated peer-to-peer routing within registrationID 8D space, got a reasonable number of hops (below 10) with 100M peers, each peer having 13 neighbors. See DrpTester4 (distance) sandbox. I had to use concept of simplex in 8D space, and sector, to avoid "torn areas" in the P2P networks. An existing approach f connecting to absolutely random peers, like in bittorrent/OpenDHT is not good. This simulation is very important, because I want to have a P2P network with a very well organized structure and static neighbors, to gain mutual trust between neighbors. The network is scalable as O(sqrt8(N));

Sucessfully sent first test message via direct channel, within DrpTester1 sandbox.

Discussion with Ilya about UserID, certificates, HSMs, root keys:

Every good developer should write good comments to his code. The comments help others to understand and verify the written code. In my project (the dcomms.org) I find that text comments are not enough and they don'e explein the system very well. So I use graphical comments, it is a set of diagrams on "draw.io". The main diagram is here, if you want to see what happens inside the "dcomms.org". We use this diagram when discussing the system with team in order to find insecure operations.
I recorded discussion with Yurii:

I am working on a big diagram of the DRP protocol. Main parts of the protocol is implemented: registration requester side and responder side. I am following "test-driven-development" strategy, and today will run first real DRP registration procedure within "CryptographyTest" project.

General overview of the system with Yurii

Recorded one more discussion with team: AES initial vector, need of signatures in REGISTER packets

Recorded one more discussion with team:

The DRP protocol is mostly defined. I recorded one of discussions with team:

The messenger will be used by people who first meet in person, exchange public keys (to avoid MITM attack) and contact each other later via the network.

After having a discussion with team and some market research, I decided to concentrate on "Distributed Routing Protocol", to create a messenger with full privacy protection. No surveillance. Main competitors are: matrix.org (vector.im), bitmessage, tox messenger, status.im. The market looks like growing and in trend. I work on a protocol whitepaper now, discuss potential attacks and solutions with (hired) cryptographer and IT security engineer, all from Russia. I find it is not easy to create a P2P network which is stable against DoS attacks, but.. we have come up to some solutions. Here is a brief summary. In my opinion the best thing to invest right now - security audits.

Recently I finished implementation of "anti-DDoS / proof of work" subsystem in my "Centralized Communications Protocol". And started to implement subsystem "Shared Key Derivation". I talked to some freelancer Ilya about the design, and got few valuable ideas on how to make the CCP more secure. I will continue hiring freelancers for security audit, it is very important to get unbiased look of the CCP at this development stage.
So I started to think about shared key derivation, using ephemeral (temporary) private keys, Elliptic Curve Cryptography Diffie-Hellman (ECCDH) key exchange procedure. I downloaded Visual Studio 2019 Community preview 6 to compile new code under .NET standard 2.1 in order to use Microsoft's implementation of ECCDH. And.. performance is awful: 1.3K operations per second. SHA256 procedure is implemented well by Microsoft, I have 400K operations per second on a single CPU core. I'd like to design a server capable to handle about 1M client-server handshakes per second on an average server, and I have to use a faster implementation of ECCDH.

Today I was thinking about "surveillance" feature in my future messenger. It conflicts with requirement that it is "open", in this exact way: 2019-06-19 UPDATE: I think I found a way to make everyone happy: the messenger will work in two modes (over 2 protocols): both decentralized (with no surveillance) and centralized (with surveillance, controlled by governments). So corporations will use "decentralized" mode, having the communications really secure within organization, for business purposes. At the same time regular people will use messenger in "centralized" mode, controlled by governments, with surveillance, legal protection and control. And there will be "gateways" between the "messenger networks", it is similar to the way how PSTN works now.

I have mostly finished design prototype for a secure protocol between client and server. I think it will be called "Centralized Communication Protocol". It will run over UDP for the first time. This protocol is a competitor to SIP, HTTP, HTTPS, TLS, SSH. How do I make it better? Also, I also got an idea of using users who use my future messenger for bitcoin mining, as proof of work. But I don't think that I will do it, because that will (probably) load user's device too much. But.. who knows.. anyway, I need to get some money from the open source messenger.

Published initial design of the secure messenger

Today I got 6 spam calls to my mobile phone. These were SPAM calls from call centers. This number increases, and I have turned on anti-spam filter to silently ignore all caller ID's that are not in my contact list.
Businesses are trying to penetrate my attention, and telcos allow them to do it. The telemarketing brings chaos into communications.
Same thing with emails, about 6 spam emails per day. Will these numbers increase? Why not? And who will build a new communication system that will automatically block spam?

2019-04 The world is complex, and the complexity is infinite:

the picture of Madelbrot fractal is taken from sciencedemos.org.uk

There are too many types of attacks on the protocols, and this list shows only top of iceberg: I am developing the new protocol(s) now, trying to make the messaging really secure. 2019-03 I research current situation of telecommunication industry. Instead or merely copying currently developed protocols, I am going to research the protocols, technologies and products to build my own understanding: 2019-02 I got an idea of creating a secure messenger. The messages will be routed via a mesh network - decentralized and redundant routing, without servers

Messenger "T" | Contact | Technical blog | Source code