B
B
bak2013-10-13 19:07:11
open source
bak, 2013-10-13 19:07:11

Distributed messenger architecture, request for comments?

Hello. Please describe, in your opinion, the weak points of such an architecture .
So far, I see the following:
— it’s not honest p2p, there are centralized elements
— it’s safe to intercept, but it’s not designed for anonymity
— it’s just another bicycle
By the first minus — it allows you to significantly simplify the implementation and interface, leaving it the same as most popular im. Decentralization is achieved through an unlimited number of servers.
According to the second, any things that guarantee anonymity will complicate the architecture, reduce the speed of work and increase traffic. In addition, partial anonymity will still be available - when sending messages through the server, direct ip cannot be determined immediately.
On the third, XMPP has the closest architecture. The main differences are:
- message encryption, the server cannot decrypt user messages (in XMPP - by default - it is possible).
- direct connections between clients (&NAT bypass)
- google protobuff (instead of XML)
- audio & video calls built into the main protocol.
- the absence of extensions in the protocol and a ban on modifying the protocol (you cannot make a client that, for example, uses a different video codec).
I would like to hear constructive criticism.

Answer the question

In order to leave comments, you need to log in

2 answer(s)
@
@ntkt, 2013-10-13
_

I would go further and try to develop not just a distributed messenger, but a fully distributed and decentralized transport + key / value storage that satisfies the given requirements (strong mutual authentication + anonymity + non-repudiation + ... ). The task, of course, is quite ambitious, but why not?

Y
YuriiVoitenko, 2013-10-19
@YuriiVoitenko

In the classical information theory, in the part that concerns protection, there is a list of attacks on the client and the network as a whole.
I will give just a few in order to more or less direct developers in the right direction, which is science ...
1. Man-in-the-middle attack
2. Replay attack
3. Attack on the protocol, traffic analysis
4. Denial of service
Well, a number others ...
You need to read smart books - everything is said there.
The main disadvantage of the whole architecture above is that the public-private key is generated by the server!
I would suggest linking the QCA library to the client and generating keys locally, giving the public key to the server. The server would then only act as a public address book for establishing connections between clients.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question