Key Decision Log (Messaging)

This key decision log is to capture the evolution of decisions for future team members.

Meeting notes:

Definition: Messaging BB is receiving messages from IM and relaying to the citizens. Essentially a black box, enabling to send messages to the end users.

• Key Functionality: Messaging BB should be able to be self-sustainable from the point of view of enabling to build e-mail client or SMS gw.

• Modalities: email, SMS, internet based apps like WhatsApp (botbased) social media apps, low footprint messages to devices.

• Specifications of JSON, REST etc,

• The minimum modalities-channels are built in, and it has to be scalable, comprehensive and priorizable. This can be part of a policy.

• Key Dependancy on IM and Workflow BB in order to deliver notifications of interactions. For example we need to define after 2-4 bounces of SMS-s that the transactions fail. At the end of the interaction, Workflow BB should take care of it.

Need to be further defined:

CURRENT SCOPE.

Subscriber, push and pull are both in scope

FUTURE SCOPE.

Chat and message rooms for creating personal assistant for delivery of information and subscribing to gov services.

Government Application (Wallet etc).

OUT OF SCOPE.

Fully offline and no internet connection scenarios. Real time video- and audioconferencing.

Use cases to be mapped out and detailed in section:

Registration of newborn child, message confirming the registration (partly mapped)

Payment transfer, message confirming the success of transfer

Booking appointment to a clinic, reminder about an appointment, scheduling an alert. Confirmation and reminder.

Emergency cenario vs normal cenario

NB! Sender will always have the address of the receiver to whom the information should be delivered to.

Receivers do not have the option to refuse.

Whatsapp has a policy in case mass messaging, the user should an option to opt out. Also there is a question of labeling the messages, to aviod spam. You have to mandate the SENDER ID to be factored in (source, type, ID).

Machine level translation and handling different languages is outside the BB.

14.01.2022 WG discussion and decisions.

The use cases were reviewed, in particular the registration of the mother/child. Sending delivery confirmation of message and a queuing mechanism. By status we can give out information about this particular message (with a token). This is to keep track of the messages. In the queue we should also give an PRIORITY1 or PRIORITY2 to the messages. This applies not for emails, but sending SMS messages, an infrastructure and agreement should be set up to identify the type of message, carrying PRIORITY1 “label”, for creating the priority. Other types can be “PRIORITY2”.

28.01.2022

Rainer Türner gave an overview of the messaging BB capabilities, with the example of Payment request workflow.

Logging part got comments from Ramkumar to log the 1) Performance reasons 2) Administrative Requirements 3) Audit requirements.

We should give recommendations (for example NO SQL databases, postgre, denormalised dbss etc), what type of databases you should be using (ElasticSearch?). The most important thing of the databases is to use denormalised dbss.

Magnus got a confirmation to use what Matrix has, in order to populate the existing parts of the BB Messaging document.

Simon and Magnus presented the json schemas and best practices. Ramkumar asked if a logic can be built using the bot to retrieve the necessery information from another BB - as templates or any other standardized already existing information to increase productivity.

We agreed to look at the work that Ramkumar has done on his BB and to use his Scheduler BB as a model for building up the Messaging BB template.

11.02.2022

John Cordeiro briefed on his additions to the Template.

Discussion was held on the division of labor, and a table was created, where the Matrix team was tasked with two chapters.

Agreed a meeting on Wednesday, 16.02.2022 with John and Rainer and Matrix guys to do joint writing of the following chapters: Data Structures and Service API-s.

GovStack Specs Work Mapping: GovStack Specs Mapping

Meetings in March 2022

The division of labour was detailed further, with John creating the generic Workflow Diagrams and Rainer detailing the forst version of the service API-s with the example of Matrix.

Meetings in April 2022

31.03.2022 and 07.04.2022 at the inter-BB WG meetings, the first version of API descriptions and Workflow Diagrams were commented on by Max, Ramkumar and WG members. On April 11th, the initial BB Template was finalized by Martin and sent for internal review.