1. 19
  1.  

  2. 4

    It seems like they just took what networks already do(allowing diff paths between send and receive, switches just doing store and forward of messages) and brought it directly to the application(s). Does that mean we will get routing protocols to fix the server outage issues?

    I like the twist where the message queues are the ones that hold the unique identifier, along with encryption. Of course if I can figure out the unique identifier I can, in theory just slurp the messages from the queue faster than the person you are chatting with and hide message delivery.

    Anyways, interesting take on messaging, and it will be neat to see how this develops as it matures!

    1. 3

      To deliver mesages, instead of user IDs used by all other platforms, SimpleX has identifiers for message queues, separate for each of your contacts. In the current version of the protocol each queue is used until the contact is deleted. Later this year we plan to add queue rotation to the client protocol, so that even conversations don’t have long term identifiers visible to the network. This design prevents leaking any users metadata on the application level.

      You define which server(s) to use to receive the messages, your contacts – the servers you use to send the messages to them. It means that every conversation is likely to use two different servers - one for each message direction.

      Only client devices store user profiles, contacts, groups, and messages sent with 2-layer end-to-end encryption.