Hi. Perhaps some more detailed answer will come from someone else but here are some thoughts.
Although many will apply interesting ideas to blockchain, not all of these will pan out or best use case for a blockchain.
There is nothing stopping you from using blockchain in messaging or any other concept, but there are things to consider.
- A database is a lot faster.
- A custom database designed for piping messages could be even faster.
- Message Queus are usually stack based where as blockchain is immutable.
- Querying: Creating new streams, interrogating streams, select * from messages where messages are unsent and system = x and users in list(4,6) is not the kind of thing that suits the blockchain.
- Hashes and Encryption exist outside of blockchain
Hybrid designs that only commit immutable records of the message in a separate process could have some benefits.
for example, architectures like..
A traditional db stores queues and messages and once the user confirms receipt of said message it writes a transaction to the blockchain.
A message queue contains list of emails to send. once sent, adds a transaction, once email opened it writes a transaction to the blockchain (perhaps in a stream where a user is subscribed).
if not time critical a secret message could be sent to a wallet address and decrypted by their key.
More, specifically to ApacheMQ or similar.
- The transport protocols are varied
- Performance is critical (or at least to a certain messages per second)
- Different architectures exist across messaging, but they tend to include
- web services like rest or soap,
- message formatters,
Consumers expect a variety of protocols and good speed of execution. Consumers expect formatters and perhaps an eventing model. The point I am making is that, none of those architectures can exclude blockchain, but blockchain will be on the fringes or leaves of the architectural design. The core will have to be a process/piping/workflow architecture and blockchain would merely be a data point.