deChat - Decentralized Chat 0

Note	This version of the template contains some help and explanations. It is used for familiarization with arc42 and the understanding of the concepts. For documentation of your own system you use better the plain version.

1. Introduction and Goals

DeChat is a decentralized messaging application developed using the Solid platform. It will let any user with a Secure Pod chat with his trusted contacts, guaranteeing the privacy of the conversation.

1.1. Requirements Overview

Right now, there exist many kinds of messaging applications, but all of them follow a centralized architecture. This is, all the data must go through a server, compromising its security and privacy.

Our main goal is to keep user’s data private, and letting the user share it with only with the people he trusts. That’s why we will use the Solid platform to create a decentralized chat application able to reach these standards.

Now, if we are using this platform to build our app, the project requirements will be based on the Solid specification. Here are the basic ones we have decided to define for DeChat:

The application will follow a decentralized architecture, storing the data in the Solid PODs
DeChat will allow a user to chat with his trusted contacts, and share pictures or videos, as well as other kind of media.
Users can create group chats, in which two or more contacts will send messages to all the members of the group.
The user data will be always kept private and secure.

Problem	Solution
Build a decentralized application.	As we said just before, we can make it private by means of the use of the PODS.
The users must have the total control of their own data	We will create local repositories with PODS.
The user can send multimedia like pictures, video…	We will recode different kind of chats to include our technology.
The user will receive a notification when someone wants to chat with him.	We will ask for notification permission in the device to add an extension.
Users can have groups with people they want to chat with. In the groups, the whole group will receive the message.	With PODS we will create repositories in each device also with group chats.

Problem

Solution

Build a decentralized application.

As we said just before, we can make it private by means of the use of the PODS.

The users must have the total control of their own data

We will create local repositories with PODS.

The user can send multimedia like pictures, video…

We will recode different kind of chats to include our technology.

The user will receive a notification when someone wants to chat with him.

We will ask for notification permission in the device to add an extension.

Users can have groups with people they want to chat with. In the groups, the whole group will receive the message.

With PODS we will create repositories in each device also with group chats.

1.2. Quality Goals

Quality goal	Scenario	Priority (Importance, Difficulty of its implementation)
Performance efficiency	The message should be sent and stored in the other user’s POD in less than 2 seconds.	High, High
Usability	If a user deletes a message, it must not appear in the conversation for all the other users in less than 6 seconds.	High, Medium
Usability	A user should be able to select a contact and start the conversation in less than 5 seconds.	High, Low
Security	In case of a network failure, the system should notify the user about having no connection in less than 4 seconds.	Medium, High
Testability	When testing a piece of the design, we should be able to finish in less than 3 days.	Medium, Low

Quality goal

Scenario

Priority (Importance, Difficulty of its implementation)

Performance efficiency

The message should be sent and stored in the other user’s POD in less than 2 seconds.

High, High

Usability

If a user deletes a message, it must not appear in the conversation for all the other users in less than 6 seconds.

High, Medium

Usability

A user should be able to select a contact and start the conversation in less than 5 seconds.

High, Low

Security

In case of a network failure, the system should notify the user about having no connection in less than 4 seconds.

Medium, High

Testability

When testing a piece of the design, we should be able to finish in less than 3 days.

Medium, Low

Note: In the priority column, you have two values as stated in its name, the first one represents the level of importance for the attribute according to the consumer, and the second one represents the level of difficulty for the attribute to be implemented.

1.3. Stakeholders

Role	Expectations
Solid development team	They are the original proposers of the project, and are interested in the best results of this and the ones of other teams of this course, as the best ones will be presented for public review and maybe used in the final product. For more information, see https://solid.mit.edu/.
Teachers of the cousrse	They expect a well developed final version following some specific guidelines, paying special attention to the architecture of the project, due to this being the main topic of the subject.
Software developers	They expect to develop a well-built application, which covers te specifications given, has a good architecture well documented, and the functionalities it has work as they are expected.
Documentation authors	They expect to document as it is said, the architecture of the application, adapting it to the format specified by the teachers of the course.
Application users	They expect the application to be easy to use, to have a good user interface, and that the functionalities that are said to belong to the application, to work in a proper way.
Ethics supervisor	It is expected for the application to cover some ethics principles, for example, to respect the users privacy, and so on.
Software Architects	They expect to build the architecture that fits the best to the specification required by the project proposers, trying to make the best decisions for achieving the desired goal.

Role

Expectations

Solid development team

They are the original proposers of the project, and are interested in the best results of this and the ones of other teams of this course, as the best ones will be presented for public review and maybe used in the final product. For more information, see https://solid.mit.edu/.

Teachers of the cousrse

They expect a well developed final version following some specific guidelines, paying special attention to the architecture of the project, due to this being the main topic of the subject.

Software developers

They expect to develop a well-built application, which covers te specifications given, has a good architecture well documented, and the functionalities it has work as they are expected.

Documentation authors

They expect to document as it is said, the architecture of the application, adapting it to the format specified by the teachers of the course.

Application users

They expect the application to be easy to use, to have a good user interface, and that the functionalities that are said to belong to the application, to work in a proper way.

Ethics supervisor

It is expected for the application to cover some ethics principles, for example, to respect the users privacy, and so on.

Software Architects

They expect to build the architecture that fits the best to the specification required by the project proposers, trying to make the best decisions for achieving the desired goal.

2. Architecture Constraints

Table 1. Technical
Name	Definition
Decentralized	The system will be based on a decentralized architecture where data storage is separated from the app.
Data Storage	The data must be stored in the user’s pods.
Sharing files	Users must be able to share pictures, videos or other kinds of files with other friends through the chat.
Notifications	Users must receive notifications when some friend wants to chat with them.
Groups	Users can have groups of friends where everyone involved must be able to chat.
Live calls	Users can have live calls.
Video calls	Users can have video calls.
Screen sharing	Users can share their screens in the chat.

Table 2. Political
Name	Definition
Non-technical	Every user should manage the app
Responsiveness	The app must work immediately
Independence	The data must be only manage by users
Security	Data must not be in touch by external devices
Privacy	Only own users can manage their own data
Aesthetics	The app must be intuitive
Friendliness	The app must have inviting interfaz
Originality	The app must be different from other apps and be recognize
Usability	The documentation of the app must be easy to understand by users

3. System Scope and Context

What we are going to create is an application where the whole information is stored and managed by the own user. He is the one that must take control of who

can see their information and where is that information. The idea is that we will use SOLID like a "securirty" system, where the user can give his key to another user, and so that the other user can see the first user’s information. Also, we have to consider the implementation of other systems taht can interact with the application, like the possibility of store photos, videos and stuff like that.

3.1. Business Context

Communication partner	Input	Output
User	Send a message	Recieve feedback of messages being received by chat partner
User	Delete a message	Message is deleted, the user and the reciever of said message receive feedback of this action and can no longer see the message

Communication partner

Input

Output

User

Send a message

Recieve feedback of messages being received by chat partner

User

Delete a message

Message is deleted, the user and the reciever of said message receive feedback of this action and can no longer see the message

3.2. Technical Context

The application will be divided in several modules, each one with a different responsability.

Module	Responsabilities	Relations
Login Service	Will verify the user identity and grant him access to the app.	The verification process will use the Solid API.
Messaging Service	This module will let the user write any message, and then send the data to the necessary number of PODs in the Solid platform.	It will have a direct communication with Solid PODs.
Solid Platform	We will use it to securely store the user’s data in a decentralized way.

Module

Responsabilities

Relations

Will verify the user identity and grant him access to the app.

The verification process will use the Solid API.

Messaging Service

This module will let the user write any message, and then send the data to the necessary number of PODs in the Solid platform.

It will have a direct communication with Solid PODs.

Solid Platform

We will use it to securely store the user’s data in a decentralized way.

Right now the project is in a very early stage. This page will be modified during the development process.

4. Solution Strategy

4.1. Technology Decisions

DeChat is developed using the Solid platform, which allows the creation of decentralized applications using Secure Pods, so the privacy of the user is respected. The Solid API is fully written in JavaScript. Therefore, we have decided that the best option the implementation of our application is to use the JavaScript programming language, so it will be in the same programming language as the Solid API.

Over several frameworks available for the development of JavaScript applications, our team has chosen the Angular framework, which is the one that most fits the way we want to develop our application, as it is really helpful for creating web applications in an easier way than other frameworks. We have also decided to run the application in a Node.js environment. This way, we’ll be able to develop a cross-platform application using well-known and fully documented technologies.

For testing our code, we have decided that we would use Mocha JS for unit testing, as it is not very difficult for learning how to do tests, and it is powerful enough for testing our application.

Also, we are using Travis for continuous integration of our project. It will run the tests we have made every time we make a commit.

4.2. Design and Architecture Decisions

As we are using Angular, we have decided to follow a Model-View-Controller structure, which the framework is designed to manage. It will help us to separate the different parts of the program, and implement all the services DeChat will need in a well-defined layer, easy to scale and maintain. image::mvc-angular.png[]

4.3. Decisions on How to Achieve Quality Goals

The message should be sent and stored in the other user’s POD in less than 2 seconds: This is achieved just by executing the action immediately, and makng checks and cosuming processes later.
If a user deletes a message, it must not appear in the conversation for all the other users in less than 6 seconds: again, when this action is requested, it is done right away.
A user should be able to select a contact and start the conversation in less than 5 seconds: the graphical user interface gives little options to the user, so an action this simple is not more complicated than necessary, the button is allways on the screen.
When testing a piece of the design, we should be able to finish in less than 3 days: we are using mocha, which has a simple syntax. This makes the process of testing relatively simple.

4.4. Organizational Decisions

Our idea is to follow an agile methodology -for the moment, a simplified version of SCRUM. Our goal is to always have a minimum viable product, which we can deliver any time a deadline is reached.

5. Building Block View

The building blocks that are currently being explored are in white background, and the ones yet to explore are in grey background. Some of the grey background blocks either are not developed by the team or do not provide significantly wider information when expanded, so they are not going to be explored in this doxumentation.

5.1. Whitebox Overall System

user: represents a human using the application as a client.
chat app: this is the main functionality of the app. It contains all the logic as well as all the styling files and markup.
solid pod: everything related to the solid platform that is not directly developed by our team. This includes mainly the pods and its storing system.

5.2. Level 1

services: logic of the application
components: front end of the application

5.3. Level 2

5.3.1. Services

solid services: logic inside the application not related directly with the external comunication.
dechat services: logic of the application invonving the comunication with the solid pods.

5.3.2. Components

app component: main component of the application.
chatComponents: contains the components related to the chat interaction(showing the messages, submiting the messages, mutimedia, etc.).
dialogComponents: contains the components that are shown as dialogs in the interface.
main-content: wraps everything but the nav bar in the graphical interface.
utilComponents: not the main functionality of the app.

5.4. Level 3

5.4.1. Solid services

auth.guard.service:
rdf.service: manages everything related with rdf communication.
solid.auth.service: logging in and out from solid.

5.4.2. Dechat services

chat.service: chat management.
files.service: file management in the pod.
inbox.service: inbox management.
message.service: message management.
user.service: user management.

6. Runtime View

When the application is executed the login page is the first to be shown
When the user clicks log in "login-popup" shows a popup to give the login options, and "login" processes the login.
Once the user is logged in to the desired platform, the main page is shown, delivered by several components.
If the user selects a chat, the chatroom is shown for that user. This is handled by the "chatroom" component.
To send a message, it must be written in the specified field and ordered to send, this action is handled by "message" and "chat-form".
The "chat-feed" receives the message, and shows it in the screen. The message is also sent to the other chatter’s pod, also being shown in his feed. The sending is managed by "messageService".

7. Deployment View

TBD

7.1. Infrastructure Level 1

TBD === Infrastructure Level 2

TBD

8. Cross-cutting Concepts

Use of observer pattern to keep the chat feed updated, as well as the chat notifications.
Synchronization of the messages to ensure security and privacy of the messages posted.
Simple interface using angular, css and html.
Security is handled by the Solid platform, giving access to the accounts through the use of a pair username-password. It is also secure, in the sense that the user’s information is not stored in the machine, but in the cloud.

9. Design Decisions

The app code is distributed in a modular way (see document 5 "building-block-view", level 1 and 2, for a more detailed insight), being all the classes in the same package level, and interacting between one another, taking a part in the construction of the app, in a more "graphical design" sense, and each one having very concrete functions. For the main structuration of the architecture we have based it on angular using a template provided by it. The main programing languale for the logic is TypeScript, and for the graphical aspect CSS and HTML mainly. Testing is implemented using Karma, also provided by angular templates. Cucumber was used for user stories. Gatling was used for load testing.

10. Quality Requirements

Content

This section contains all quality requirements as quality tree with scenarios. The most important ones have already been described in section 1.2. (quality goals)

Here you can also capture quality requirements with lesser priority, which will not create high risks when they are not fully achieved.

Motivation

Since quality requirements will have a lot of influence on architectural decisions you should know for every stakeholder what is really important to them, concrete and measurable.

10.1. Quality Tree

10.2. Quality Scenarios

Quality goal	Scenario	Priority (Importance, Difficulty of its implementation)
Performance efficiency	The message should be sent and stored in the other user’s POD in less than 2 seconds.	High, High
Usability	If a user deletes a message, it must not appear in the conversation for all the other users in less than 6 seconds.	High, Medium
Usability	A user should be able to select a contact and start the conversation in less than 5 seconds.	High, Low
Security	In case of a network failure, the system should notify the user about having no connection in less than 4 seconds.	Medium, High
Testability	When testing a piece of the design, we should be able to finish in less than 3 days.	Medium, Low

Quality goal

Scenario

Priority (Importance, Difficulty of its implementation)

Performance efficiency

The message should be sent and stored in the other user’s POD in less than 2 seconds.

High, High

Usability

If a user deletes a message, it must not appear in the conversation for all the other users in less than 6 seconds.

High, Medium

Usability

A user should be able to select a contact and start the conversation in less than 5 seconds.

High, Low

Security

In case of a network failure, the system should notify the user about having no connection in less than 4 seconds.

Medium, High

Testability

When testing a piece of the design, we should be able to finish in less than 3 days.

Medium, Low

11. Risks and Technical Debts

The development team ^[1] has never designed and implemented an aplication related to the use of Solid pods, so they have to get used to how this technology works, which is translated into time spent learning how they work, subtracting time from development.
The development team has never worked with Angular, so there is the risk that the team is not able to adapt themselves how to work with this framework, or it would take them time, that at last, this time is going to be reduced from development time.
The development team has never designed an architecture for an application, and they are learning how to do it at the same time, so there is the risk that the architecture designed for this project is not as optimal as it should be, deriving in a poor design of the project, which could hinder the development.
The majority of the group has never worked with RDF, which can be complex to understand, and to design structures and classes with it, so there is the risk that the design of the application from the point of view of translating the data to RDF, is not very efficient, or is not working properly.
Until now, the team, has not worked with continuous integration, therefore, there is te risk of not adapting properly to this way of working, or not doing it as it should be done. We have to spend time checking that we are doing this part correctly.
In the past, the members of the team have worked with relational databases as HSQLDB or oracle, and they are not used to using the NoSQL database engine MongoDB, which can derive into a poor database design.
The team has never used Mocha for implementing tests in JavaScript, and that could mean that, at first, tests may not be as good as they should, because the team need time to adapt its work to this technology.
Until now, in the projects the members of the team had to face, they never had to do documentation as the one required for this project, which could subtract time of development, because they have to do a lot of research about how to do this type of documentation properly.

12. Glossary

SOLID: Solid is an exciting new project led by Prof. Tim Berners-Lee, inventor of the World Wide Web, taking place at MIT. The project aims to radically change the way Web applications work today, resulting in true data ownership as well as improved privacy.

About arc42

arc42, the Template for documentation of software and system architecture.

By Dr. Gernot Starke, Dr. Peter Hruschka and contributors.

Template Revision: 7.0 EN (based on asciidoc), January 2017

1. Not necessarily refering to the abolute totality of the members of the team, but to the majority of it. Applicable to the rest of this piece of documentation.