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”.
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.
1.0.0 | Steve Conrad sconrad@digitalimpactalliance.org | Initial version of the Template |
1.1.0 | Max Carlson, Steve Conrad, Dr. Ramkumar, Trevor Kinsey from the Architecture Group | Applied document standards to template |
1.2.0 | Martin Karner, Rainer Türner (01.09.2021) | Drafted the first definition and started to assign the work on chapters to group members. |
1.2.1 | BB WG members (29.10.2021) | Drafted the Definition, decided to limit the scope of the BB to the messaging between the GovStack application/internal user and the end user (using i.e. Matrix protocol, routing to existing messaging modalities). |
1.2.3 | BB WG members (05.11.2021) | Identified Messaging BB in the Logical Process Blueprint, and in particular the Registering use case. Drafted the table of functional and technical requirements for the registering use case. |
1.2.4. | BB WG members (12.11.2021) | Decisions made: data storage and network transaction logs should be configurable; performance should be monitored, metric installed; Business logic and policy can be stored in separate BB and they can add MSG type, address: who-to-send-to, MSG channel etc. In reverse communication, an unique identifier is created per user (upon registering at the Messaging BB or any other BB). BB should allow push and pull models. Need to sync with Taylor@IM/Workflow |
1.2.5 | Rainer Türner | Initial set of cross-cutting requirements |
1.2.7 | John Cordeiro and Martin Karner | Initial list of definitions |
1.2.8 | Magnus Hult, Martin Karner | Miro table was drafted in order to map the high level functionalities, vis-a-vis the end users and other BB-s, workflows. |
1.2.9 | Rainer Türner | Update of cross-cutting requirements |
1.3.0 | John Cordeiro | Created a generic workflow diagram |
1.4.0 | Rainer Türner | Created initial API descriptions |