Application organization

The next few files implement the peer to peer communication protocol built on top of the messaging format presented in the first part.

The application follows the FRP method using RX queues as channels between actors.

At the top of the hierarchy, there is the actor in charge of the blockchain. As the most fundamental data upon which the rest of the data model derives, the blockchain stays isolated from other components by a tight actor boundary. The blockchain is only read and modified by its associated actor whose name is Bob.

Bob is the boss. He maintains the accounting books and he trusts no-one. He sits in his office and spends his day counting his money. He never goes out - he has people to do that for him.

But Bob needs to know when his blockchain is modified. He hired Tom to keep him in the loop.

Tom is a well connected guy. He knows people who know people who know people. He has a group of active informants. They are a bit flaky and tend to quit without notice but Tom doesn't mind. He can always replace them.

When one of his crew tells Tom about something new on the blockchain, Tom sends a note to the boss. Tom doesn't understand that blockchain nonsense but he knows his boss would be very unhappy if he was not informed and it's not good to make the boss angry.

Bob is a collector by nature. His blockchain is his most valued collection. The blockchain is made of blocks and Bob wants them all. And so he watches his mailbox waiting for messages from Tom.