> You just present a delivery token, which proves you are authorised to send messages to this recipient, and your encrypted message addressed to the recipient.
And how do you get it?
> Signal doesn't learn who sent it nor do they care, the recipient's client figures out who sent it after decrypting it.
I don’t know Signal internals but it could work like this:
First message without sealed sender from A to B: Signal knows the recipient. This messages includes a token that A wants to receive B’s messages with sealed sender, that is, a payload signed with A’s private key
B accepts message and also sends back proof that it wants to received further messages from A with sealed sender (again something signed by B). This message can be sent via sealed sender as well because B now has A’s token
Signal Server only allows sealed sender if token is valid (i.e. is signed by the recipient)
E: Just realised I have made a mistake when typing, sorry.
In the first message Signal knows the sender. Signal always knows the recipient (otherwise it couldn’t deliver). From then on Signal doesn’t know the senders because of Sealed Sender.
Also: “a token that A wants” should have been “a token indicating that A wants”
And how do you get it?
> Signal doesn't learn who sent it nor do they care, the recipient's client figures out who sent it after decrypting it.
which doesn't mean they couldn't