EW-DOS Decentralized Service Bus (DSB)

The idea behind Pub/Sub is that a user can publish a message on a broadcast channel and let anyone who has permission to subscribe to the channel to receive the message. This paradigm is implemented by multiple messagingg systems already. Some of the best known are Rabbit MQ, nats.io, Apache Pulsar. AWS, Azure and GCC have a hosted version of messaging services with the same functionality.

The question of why we need out own version of the message queue or pub/sub implementation is therefore justified. The answer is that we do not want to re-implement the pub/sub functionality of these solutions but aim to create an interface which can use any or all of these services.

Design

The design shall mimic the design choices made for the EWC:

  • Only authorized nodes can participate in providing the service
  • The services are publicly available
  • A reward system is in place to reward the service providers for their efforts
  • It is assumed that the nodes are honest and their actions are verified

It is assumed that the user can trust the infrastructure providers to fulfill the requirements. The system does not require a consensus protocol between the user and the infrastructure. Nonetheless, the user will receive proof for the successful execution of the operation they have requested, in order to keep the infrastructure providers on their toes.

Identity and chain abstraction layer are implemented. IAM based on DID is used.

Each end-point is implemented as a GraphQL API Server endpoint.

The EW-DSB component of the utility layer allows EW-DOS users (humans and automated agents) to communicate seamlessly with one another by publishing messages and subscribing to messages. See the capabilities for details

The users can be one of two types:
  • Human user which interacts with the system through a UI
  • Technical user which interacts with the system autonomously. E.g. a server process or IoT device

The user types differ only minimally as to the functionality of messaging. Both get:

  • Guaranteed delivery for acknowledged messages
  • Single delivery guarantee for messages
  • 3 message types:
  • Unicast (P2P)
  • Multicast (one to many)
  • Broadcast (channel pub/sub)
  • Access control management and enforcement for message channels
  • White and Black listing for peers (i.e. you can mute a chatty peer or make sure only group members can send)
  • Poll or Stream delivery depending on the connection channel. WS, HTTP, UDP, WebRTC

Components

Components overview

The EW-DOS DSB utlity contains 4 major components and two external components. The idea behind the design is to enable a drop in replacement of any of the components, most importantly the Message Transport

The system is built to cater for the requirements of the two actors:

  1. The Sender or Publisher is the user who creates a message and expects it to be delivered
  2. The Recipient or Subscriber is on the delivery end of the message transport.

Message Broker

The Message Broker is the end-point to which the actors connect to in order to publish or subscribe to the message delivery system. It fulfills following functions:

  • Authentication, Authorisation and Accounting for user access
  • Gateway to the Message Archive to provide access to the history of sent messages
  • Gateway to the Message Transport layer which allows to send messages from one broker to another
  • Publish messages to broadcast channels
  • Subscribe to broadcast channels
  • Send direct messages to specific DID addresses
  • Subscribe to direct messages for the DID used to login

Address Book

The address book holds the list of all existing channels and makes sure that the meta-data pertaining to a channel is accessible to the users of the system. Each channel has a publisher and subscriber role and must not be overwritten by a new definition.

Message Archive

The Message Archive contains the logs of all messages per channel or recipient. It is an independent component from the Message Broker and can be scaled independently.

The Message Archive is implemented by listening to a wildcard channel like * which allows the subscriber to get all the messages from all the topics. Only Message Brokers Message Archive and Accounting agents can listen to wildcard channels.

Message Transport

If the Publisher and Subscriber of a message are not connected to the same Message Broker the Message Transport is used to get the message from one Message Broker to the other.

The Message Transport layer is also used to send logging and other administrative messages and to send the messages to the Message Archive.

Only Message Brokers can publish and subscribe on the Message Transport. This functionality is not available to the Sender and Recipient actors.

The message transport shall use one of the solutions mentioned at the beginning of this document. The test implementation uses nats.io but this can easily be replaced with andy of the other solutions.

Identity Provider

Each user must authenticate before being granted access to any of the components of the system. The Identity Provider serves as identity federation server and allows the user to use SSO features for the applications and the messaging service.

The components also need to authenticate among one another and also use the Identity Provider to perform authentication and authorisation functions. This means that the components must have a DID which has been enrolled in a specific role before they can start serving users.

Key Manager

The Key Manager serves two functions:

  1. It is the entry point to the Public Key Infrastructure or Identity Registry which contains the public keys for all the identities known to the system
  2. It serves as provider for encryption keys that enable users to read messages encrypted with a channel public key. For more details see the Channel Encryption document.

The Key Manager can also be used as a key wallet by the user. Which allows them to control their keys in a single location and benefit from key recovery by the support department of their company.

Accounting

Every message should be accounted for so that the system can charge for usage. The price per message might vary based on the package the user has subscribed to and other parameters. Hence it may not be possible to charge the user for each message as they're being processed but only at a later moment when the usage for the billing period is known.

There is no need to know about the messages themselves in the accounting mechanism. The important data to record are:

  • the message hash
  • the sender's signature
  • the message broker's signature
  • the timestamp of the message entering the system

This information should allow to assign the message to a delivery period and account for such things as daily or hourly quotas. Both the sender's and the broker's signatures are required in order to be able to make the broker pay for messages if the sender has an insufficient balance.

Ideally, the accounting system would create a recursive proof which allows to verify the claims it makes without going through the long log of messages. Something like mina protocol would be cool. It is an implementation of the trustless recursive ero-knowledge proof concept

Until we master these complex schemes, we're stuck with counting by using normal database functionality which runs on the data that is indexed in the accounting agent. But as each entry contains only two signatures (2x64 bytes), a hash (32 bytes) and a long, the amount of data is kept low and it is easy to create efficient indexes.

Capabilities

  • DID Authentication and Authorization
  • Roles Based Access Control for core features and messaging
  • Broadcast messaging in which one agent publishes a message without knowing who (if anyone) will read it as there can be an arbitrary number of subscribers
  • Worker queue which is a specialized version of the broadcast message channel in which only one of the subscribers gets each message and is expected to perform a task and send back a result
  • Unicast messaging: a message is sent to a specific recipient and only they can read it
  • Multicast: a message is sent to a group of recipients and only they can read it

DID Authentication

In order to access any part of the system an authentication is mandatory.