Depends on what you mean by "secure", being very loose with the definitions, we have
- end to end confidentiality (i.e. only you and the intended destination can see the message contents)
- privacy (only the destination knows i'm sending messages to them)
- anonymity (no one can find out who you are, where you live, i.e. metadata/identity/etc)
My personal preference is Simplex.
Reasoning for a few:
- Email: even if you use PGP to encrypt messages the server(s) in the delivery path have access to all metadata (sender, receiver, etc, etc). If no encryption is in use, they see everything. Encryption protocols in e-mail only protect the communication between client and server (or hop by hop for server to server)
- XMPP: similar reasoning to email. i.e. the server knows what you send to who. I should note that XMPP has more options for confidentiality of message content (PGP, OMEMO, others). So I find it preferable to email - but architecturally not too different.
- IRC: Again similar reasoning to email - even if your IRC server supports TLS, there is no end to end encryption to protect message contents. There were some solutions for message encryption/signing, but I've never seen them in the wild.
- Signal: Good protocol (privacy, confidentiality, etc). Dependency on phone number is a privacy concern for me. I think there are 3rd party servers/apps without the use of phone numbers.
- Simplex: Probably the strongest privacy protection you can find, but definitely not easy in terms of usability. The assumption is that we do not trust the intermediate server at all (and expose nothing to it), we just leave our encrypted messages there for the receiver to pick up later. It also does some funny stuff like padding messages with garbage.
- Matrix: In theory it supports end to end encryption in various scenarios, but my experience with it has been so bad (UX, broken encrypted sessions) I only use it for public groups.
Some more food for though though; these protocols support both group communication and 1-1 messaging - privacy expectations for these two are very different. For example I don't care too much about confidentiality in a group chat if there are 3000 people in there. It might be more concerned with concealing my phone/name/metadata.
In general I consider large group chats "public", I can try to be anonymous, but have no other expectations. e.g. some people use some protocols over ToR because they do not trust the service (or even the destination) but they try to protect their anonymity.
On a technical note: I don't think there is any protocol that supports multi-device without some kind of vulnerability in the past. So I would temper my expectations if using these protocols across devices.
I'm not familiar with the other ones that were mentioned in comments or in the spreadsheet.
I can't offer a comparison with Session, since I'm not familiar w/ it. At a glance messages seem to be routed through some nodes that belong to a pool of service nodes that run some cryptocurrency stake (but I don't know what this means in practice). It does seem seem to do multi hop routing which means its more resilient to privacy attacks (but this says nothing about resiliency to being blocked).
On the SimpleX side, anyone can operate a SimpleX SMP server - that is the server that holds messages while in transit from the source to the destination (each server has a number of queues, each is one-way from a sender to a receiver ).
Each user defines the servers/queues he uses to receive messages, but not to send (those are the defined by the user you are sending messages to). So resilience to blocking means both users need to diversify the servers they use.
The folks running SimpleX host a handful of servers - and I expect those are the ones most people use. In that sense they are a point of failure for someone to block communication. If you check the source you will see an incomplete list of servers there, and in the app settings there are more (and you can add your own).
As for blocking the protocol, the following approaches seem standard for a state operator:
(This is as far as my knowledge of SimpleX goes - the rest is slightly hand wavy assumptions I never checked)
I don't recall how the SimpleX app manages those server queue(s?). Taking a peek at the app right I only see one receive/send queue when I select a contact. But in theory it should be possible for it to have multiple queues per contact. The documentation does mention this in some comments (newQueueMsg: maybe it is not implemented?)
Finally the android app seems to support integration with ToR and will support .onion addresses if this is enabled, that is probably the most practical way to bypass some blocker (assuming ToR is not blocked :D). But this requires that the SMP server used by your contacts supports ToR addresses.
It would definitely be nice to see support for tunneling over other protocols, and of course more servers running those (ToR, I2P, gnunet?, etc, etc).
Some links to stuff: