Index Switzerland Zürich Italy Music BottleMD DebloatProxy Outdoor phone Outdoor baby bbs2000 Shell usage Simple Web

A new messenger

I want to write a new messenger. Nothing fulfils the requirements that I have:

Why not one of the existing?

I see major drawbacks to all common platforms or concepts. Right now, I see four major ways in which messaging networks are working, explained below: Centralized, peer-to-peer, local-discovery, federated.

Centralized

This is the systems where one central provider runs the platform, as e.g. Signal, Threema, Whatsapp, ICQ, Facebook, etc. All your messages are exchanged with the provider's servers and from there communicated with the other participants.

This is pretty much all commercial messengers and they on various levels fail almost all requirements I have. Censorship is an issue as well as a silicon-valley-based moderation, often requiring you to identify to log in and having proprietary protocols, being easy to block or take down.

Peer-to-peer

Peer-to-peer (p2p) networks are networks where there is one big network that you connect to. Then, there are various methods to establish a communication with the other participants. Examples which use Tor are Tox and Briar (which uses Tor amongst others). The communication itself happens directly between the participants, without the rest of the network (or any central authority) involved.

It should be noted that this does not have to be only one network, but it can be multiple ones. E.g., any bittorrent tracker runs its own network. In the same way, any blockchain-based communication has the same concept.

However, an often overlooked component is the servers which are needed for the initial communication, in bittorrent-jargon, the trackers. When trackers are blocked, act maliciously or go down, the whole network is impacted. This can be seen e.g. by Tor being blocked by China.

Local discovery

These are mentioned just for completeness. There are messengers which do local discovery, i.e., they use methods in the local network to discover other network participants. This obviously does not scale globally. A glorious example of this kind of communication is again Briar, which uses different networks for global communication.

Federated networks

Federated networks are the classical decentralized systems, like e-mail, Jabber/XMPP, Delta, Diaspora, Mastodon.

I am a proponent of federated systems, however, all those on the market right now have one drawback: They use your home server for communication. E.g., when a participant wants to communicate with you, they address their server so that server sends a message to your server and then that server sends the message to you. This can lead to strong concentrations in the network, like with Google and Microsoft in case of e-mail or jabber.ccc.de for Jabber/XMPP. Furthermore, when one provider decides that they do not federate anymore, you are cut off. This has been the case with Google and Jabber/XMPP.

My proposal

My proposal is oriented towards bulletin board systems (BBSs). These were single message hubs to which you would connect to directly (via land-line, not internet) to talk to certain people. When one BBS went down or banned you or was otherwise inacceptable for you, you would not be able to talk to people from only that BBS anymore. But you could still talk to anyone else on the network in other BBSs. The power was in the client - your phonebook.

How to translate this to modern messaging networks? Instead of requiring two participants to be connected to their own servers to establish communication, it suffices when only one has one. The participant with a server will create a communication channel on his server that allows the other participant to contact him directly, without having to go through his own server. So in a normal case - two participants with servers each - even if your own server becomes inavailable, there will still be the other participant's server to communicate.

The central idea of this proposal is to not have a list of communication partners with whom to communicate, but to have a list of communications happening. While every endpoint is authorized, this authorization is not granted from another federation partner, but provided by other means (e.g., personally knowing each other).

Drawbacks

I stated my goals in the introduction, and I think it will fulfil all these goals. So let's talk about the drawbacks.

End-to-end encryption

I did not discuss end-to-end encryption (e2e) so far because it has been implemented in most messengers, regardless of the network structure behind. Therefore, I do not consider this an issue for my proposal, but rather an implementation detail.

Initial contact/spam protection

To prevent spam, the only known-to-work methods so far have been authentication. This is gmail or outlook being ever more restrictive in from whom they accept e-mails and what you need to register, or whatsapp etc. requiring a phone number for sign-up, etc.

I do not intend to solve this issue. My proposed messenger is not there to establish anonymous communication, but enable those who know each other to communicate. Therefore, a communication signal must be established easily, e.g. by scanning a QR code on the phone or handing out individual one-time keys.

Laymen usage

Federated networks are generally criticized that it needs professional knowledge to run a server. I want to have a server software that is as easy as possible to be setup. In this case, it shall be a simple CGI that can be hosted as easily as the famous Wordpress. Shared hosting shall be possible so that anyone can invest a tiny amount of money and run his own instance.

A new standard does not help anyone.

Yes. That's part of the deal with all these things.

Implementation

It is obviously a big endeavour. I have been working on this on a smaller level for some time now, but with my coding effectiveness it will be a long time. This page is primarily a structured way to present the idea and maybe find people who are motivated to join.

There are already systems which are similar, in a way. One of them is fossil, a version control system, that has also many features integrated. However, it is primarily a version control system, and the functionality of the wiki and forum are limited. Another one is Solid. This one represents a lot of my ideas. qaul seems also interesting, working on meshed networks, if required. The project that is probably closest to my ideas, is nostr. Further investigation is required inhowfar these projects can be a basis for the proposed plan here. However, I want something that can be set up and hacked easily. Solid is way more professional than what I intend. I want something that can be as easily modified as e.g. IRC.