Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


The server maintains a little bit of unencrypted user information: their name, mobile number and a reference to their public message box. The other information is encrypted with the key that is stored on in the secure storage of the device (e.g. Android non-exported content provider). This encrypted data includes the buddy relationships, the defined goals and two private keys to access the two message boxes. Writing into the message boxes can be done through the public key (not depicted, to prevent confusion). For reading, the private key is required, which is part of the encrypted data of the user. The message box for direct messages is linked from the public data of the user, so given a user, it is possible to find the direct message box. The sole purpose of the direct message box is to be able to send an buddy connect request to a user.

The anonymous message box is linked from the private data of the user, so only the user "knows" their anonymous message box. Besides this, the anonymous message box is also linked to the accessor objectso-called user-anonymized entity, which carries the same ID as the VPN user name. Thus the analysis engine (see below) knows where to post messages when a goal conflict is detected for a given VPN account.  Once the buddy relationship is established, all inter-buddy messages go through the anonymous message box.

Layered architecture

The Yona server has a simple layered architecture:


  • Orange: encrypted with the Yona password stored on the device
  • Magenta: encrypted through public/private key encryption
  • Black: not encrypted. Grey: used to denote conceptual relationships that are in directly programmed this wayThis holds anonymous informaiton that cannot be related to identified users, but users can find the data that belongs to them, by decrypting the associations.

User with buddies and goals