Minimum Viable Message Bus 🚌

## Overview

As an engineer connecting services, I want an always-on, tamper-resistant message bus to pass messages between services so that I can coordinate my services.

### Reference

- [Epic - MB for Stratego](https://github.com/ConsenSys/web3studio-sidejam/issues/1)
- [Atomic Crosschain Transactions (Pantheon)](https://arxiv.org/abs/1904.12079)
- [chain.link](https://docs.chain.link/docs)
- [General Message Bus Pattern](https://github.com/ConsenSys/web3studio-sidejam/issues/1#issuecomment-490906621)

### Questions

- What patterns exist in other MQ, MB systems?
- What steps should be put in place to prevent deadlocking?
- Is it all on the client? Does the MB need to expose features to allow clients to prevent deadlocking?
- Should a "time-lock" mechanism be put in place? See Atomic Crosschain Transactions. "Message slots" per topic for concurrency?

### Assumptions

- Optimize for keeping gas low

### Acceptance

- A smart contract to be used as a MB, it should:
- accept a message and provide guarantees that once the calling process get's a successful return that the message is guaranteed (to some degree) to be durable.
- Provide some way for services to request messages since a cursor (timestamp, vector, clock, hash chain, etc..)
- Provide some scheme for additional metadata on the messages that could be read (optionally) by services and used for filtering. (topics, senders, etc.)
- Emit events allowing services to process in real time
- Allow for deadlock prevention (See questions)