Every inbound message is authenticated, and credentials are stored somewhere. Correct me if I am wrong, but I'm betting that it's with the same credential/channel as for logging-in a user (aka "sender").

Also, wasn't "sealed sender" broken (again) earlier this year by a group of researchers?

No, sealed sender messages are not authenticated. The sender's client uploads two things: 1) an encrypted message (with sender id encrypted), and 2) a zero-knowledge proof that the sender's client knows the recipient's delivery token.

There is no authentication by the sender, and the sender does not upload any credentials.

I guess I have to rephrase myself: the API calls are authenticated, because the API endpoints will not consume anonymous requests. I'd be glad if you could point me to documentation proving that the messaging API uses completely different credentials than those for user login, and that the two are also disassociated.

This doesn't prove anything, but:

> Without authenticating, hand the encrypted envelope to the service along with the recipient’s delivery token.

Source: https://signal.org/blog/sealed-sender/#:~:text=Without%20aut...

The sender's client sends a certificate derived from the recipient's profile key.

This certificate is sent to the server as the header "Unidentified-Access-Key" - you can see how this header is derived from the Signal clients' source.

So yes, these API calls are authenticated, but not using the sender's credentials in any way.

Good luck finding documentation about the protocols and APIs used by signal. While every random cryptocurrency has a cryptography whitepaper, it seems that Signal does not.

Signal published detailed specifications of the protocol with reference implementations since at least Feb 2017 (group messaging protocol was added later on): https://signal.org/docs/

The server and clients are open source: https://github.com/signalapp