If SimpleX donesn't work with ID's, how can it be sure to deliver the messages at the right person ?

I'll give a verbal explanation a try.

I have a message for Ms. Brown. She has shared with me her current queue ID on her preferred relay, ABC. Connecting to my own relay XYZ, I send a message into my ephemeral queue ID for her on XYZ that is addressed to her ephemeral message queue on ABC that is unique to Ms. Brown and me.

XYZ can only see that I am requesting a forward to ABC. It can't read the message contents or her queue info. Only Ms. Brown can read the message, and only ABC can read the queue information.

XYZ forwards the message from my unique queue to ABC, which decrypts the header and delivers it to her message queue. Ms. Brown, who is connected to ABC and watching her queue, sees a new message, downloads it and decrypts it.

Once delivered to Ms. Brown, her queue on ABC is discarded, and her client creates a new queue for our next message.

XYZ only knows my queue ID and the relay ABC. ABC only knows XYZ and Ms. Brown's queue ID, which has been discarded. Ms. Brown knows about XYZ and my message queue, and both queues are recycled at an unknown (to me) interval.

I am only somewhat confident in this description. I don't know how often queues are torn down and rebuilt.

Not sure which docs you are looking at, but my preferred description for this part is SMP

• https://github.com/simplex-chat/simplexmq/blob/stable/protocol/simplex-messaging.md
• https://github.com/simplex-chat/simplexmq/blob/stable/protocol/simplex-messaging.md#smp-procedure

The previous message already pointed out the main point - communication happens via queues our clients knows to belong to the destination, and these queues are temporary. This means even if an attacker determines the queue belongs to a specific person it can be changed and even then it does not reveal who is the other contact using the queue.

A few more bits to consider:

1. queues are unidirectional (so you need at least 2 for a contact) and you only create the ones you use to receive messages
2. the server holds two identifiers for a queue - one for the sender one for the receiver
3. the queue also has two keys - which allow the server to recognize the sender and receiver respectively i.e. only the sender can send and only the receiver can collect msgs (SMP server should reject otherwise)
4. all the keys/ids i mentioned so far a created anew per queue
5. finally the messages that are placed in the queue are encrypted between sender and receiver (DH) but is beyond SMP

So there are IDs but hopefully they are not useful for an attacker.

Now to answer your question. There are IDs but for a message to be delivered to the wrong person the following would need to happen

1. you would have to send it to a server with the wrong ID and encrypted with wrong key
2. the SMP server would need to allow this by decrypting it with the wrong key too (unlikely but not impossible I think - if we assume some magic to break point 3. from before)
3. the message would then be picked up by the receiver (which would try to decrypt it but it would fail)

Caveats - the client app must be well implemented and NEVER reuse keys. Likewise the server must not reuse queue IDs.

I think I got my assumptions right. When in doubt check the 2nd link for a long step by step description of the protocol