DawePost – A Messaging architecture

©Dawe Post Ltd 2018 Author Peter Dawe, peter@dawe.co.uk Date 13 June 2018

    1. Introduction

      Digital messaging is a fragmented space with a wide range of proprietary and non-proprietary systems each optimised for specific use cases, and typically poor at inter operation between systems.

      The WizPar Digital Messaging Architecture is an attempt to generalise digital messaging to allow current usage to be within a single architecture and to provide one that allows novel use of digital messaging. In much the same way that HTMP and HTTP transformed “File Sharing”.

      The WizPar architecture is TCP/IP like, in that every node may be a source, transit or destination for a message. A node will subscribe to a message “stream”, defined by a “Parent Message” and seek to keep its view of that stream synchronised with other subscribers, according to distribution rules held in the “Parent message”, or local defaults. Rules may also deal with routing, reliability and flow control issues. As with any architecture, it is how the system views its core components. In WizPar, the individual message is the core component. Each message must provide the system with the information needed to manage that message. Either with specific information, or references to sources where that information can be garnered, e.g the parent message. Some of this information may be overruled by local defaults.The system is basically a database of articles that synchronise across diverse media. Implementation is through a partial de-Normalisation of that database, resulting in Lists of sources to be checked for lists of article “types”.

      A DNS style of look-up can be used to associate various UIDs with display names

      All Nodes are equal, but some nodes may be more equal than others For example

      • A node may be designated as the preferred source

      • A node may be a repository for messages, that another node chooses not to archive

      • A node may be defined as the keeper of “Authoritative message stream”

      The system seeks to provide the source to control where their message goes and the destination to control what it receives and what happens to that message

    2. Implementation

      WizPar nodes can provide gateways between legacy messaging systems. Reformatting the legacy message and data into WizPar and taking WizPar messages and exporting them to the legacy systems. In the current proof of concept WizPar system, we have the ability to import various message streams including RSS, Twitter, Google Alerts and others. Adding other legacy messaging systems can be done either in the app or using an agent.

      The current implementation provides for on-line and off-line operation, and message propagation through both peer-to-peer and agent nodes.

      The use of encryption may be used on some of the data fields and message to

      • secure privacy

      • allow meshed distribution of private messages

      • enforce readership limits

      • etc

    3. Mapping usage cases to WizPar implementation

  • Base Email- A Stream anyone can write to and only the owner can read

  • Two users agree a unique message streamID, defined by a parent message. This message stream synchronises all messages. Note as they view the same stream, disputes over message delivery can be quickly resolved, especially if an “Authoritative archive” has been defined

  • Subscription publication -

  • Hyper-local publishing

  • User filtering for good signal to noise

  • Blogging

  • Social Media

  • Signalling for real-time streams

  • eBay

  • Uber

  • eCash