We were very happy about the article on our project in the current issue of c't magazine. For the authors, Dr. Christoph Wegener and Dario Carluccio, some questions remained unsanswered. We would like to take this opportunity to go into further detail.
The code posted on GitHub (C/C++ client side, Node.js and Python on the server side) are prototypes. Over a period of a few months, our team has tested many ideas . Every day we made slight changes, tackled conceptual questions, discarded and wrote new code. This lead to not integrating every functionality into a library that would have made sense.
In the treatment of drop and storage server, we proceeded in the same manner. To test our ideas on feasibility, we can not simply rely on ready-made solutions. On closer inspection, however, one notices also that, for example, the Python and Node.js implementations are not "comprehensive". There, we cannot use existing high-level libraries.
Of course, our long-term plan is to use and support already existing solutions - for example, no one will favour a ZFS file system as a prerequisite for the storage server. Many (distributed) file and database systems are conceivable here. The current storage server is a minimal test. Proven and used solutions such as S3 and some others are already scheduled.
In addition, we must avoid license incompatibilities. The interaction of the GPL with specially designed licenses such as our proprietary QaPL is known to be difficult.
The fact alone that Qabel follows a decentralized approach, accomplishes a lot when it comes to metadata concealment.
In the future, we will publish tests concerning the metadata concealment. Here, we consider parameters such as the amount of the required communication overheads and the minimum number of required users to ensure a certain degree of anonymity.
The fact that the messaging server does not perform any accounting, is a further advantage for user anonymity. In return, we need to accept certain problems coming with it – a "proof of work" concept to stabilize the communication is already planned. Other systems (such as Bitcoin) have mastered this challenge in this manner, too.
Ideally, the Qabel client is also connected to several Qabel servers. A regular automatic server change happens in the background of the application.
When designing a complex system, it is a normal procedure to accept certain aspects as given. This was done here for the first contact ("key exchange"). This situation is not acceptable for an end-user-friendly system - that is absolutely clear to us, especially because Qabel aims to combine the benefits of systems like PGP with better usability. A method for easier and safer first contact already exists and is currently being tested. Very roughly , we are working on a "browser" component. The core idea is a component comparable to PGP keyservers. In addition, the "out of band" contact is thereby simplified. We do not transmit any key out of band, but just the first contact and fingerprints (we are currently thinking of a fingerprint or a QR code - for example on a business card). The contact details and key are then loaded and compared to the OOB fingerprint. This is not only very comfortable, OOB also offers additional security.
The scalability of Qabel is a solvable challenge. Currently, we are determining which would be the ideal number of users per server or provider to optimize the straddle between anonymity and usability. The system "e-mail" has basically the same problem – and it works through the same decentralization that is sought for Qabel as well.
Last but not least a reminder: Qabel is Alpha. We need a concept like Qabel that faces the challenges on both the technical and economic level. Qabel is an ecosystem that invites people to colonize it. Questions, constructive criticism and ideas are more than welcome – many messages giving wonderful impulses reach the Qabel team every day. Thanks for that. Please do not stop!