Usage of Streams

Question

hi Team,

Do you ever see streams being used as a replacement for messaging frameworks - like Apache MQ or Tibco? I know only pub/sub (broadcast) will be possible and point to point cannot be done but do you ever see multichain streams being used like that in future?

Answer 1

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,
  • routing,
  • eventing,
  • publish-subscribe
  • piping
  • etc

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.

 

Comments

Thanks for your elaborate answer, makes sense.

Answer 2

From our perspective, the answer is definitely yes, now and not only in the future. You can consider the blockchain as an archived, notarized and highly replicated publish-subscribe messaging framework. Without revealing too much about our product plans, you can expect a lot more messaging-related functionality in future.

Comments

Ok fine but will it always remain a true blockchain i.e. every node will receive the stream tx and it will not move the hyperledger way where they have introduced the concept of channels(which is like a sub-ledger and only particular nodes receive the tx) ?

---

As far as we understand it, Hyperledger channels are just separate blockchains, with some permissions in common with each other. You can also run separate blockchains in MultiChain if you wish, but this is your choice.