deChat - Decentralized Chat

1. Introduction and Goals

The objective of this project that we will develop further is to create a decentralized chat application based on SOLID specifications. Our application can resemble any other more popular and commercially successful in the field of instant messaging, except that ours, as we said in the beginning uses a decentralized architecture to store data, providing a more remarkable security than the others. Our application aims to help users (two or more) to communicate with each other, sharing all kinds of information without this information being stored on any external server, providing a completely private and therefore secure communication. To do so, users must have a POD of SOLID to store their data. As essential characteristics of our application, we will look for them to be the most similar to those of the most popular, either:

Share photos, videos and other files
Multi-person chat groups
Notifications
Etc.

1.1. Requirements Overview

Contents

A brief description of the functional requirements of our application is that it consists of a decentralized chat application based on SOLID, where users using the application must have a SOLID POD, which will allow these users to store their data, to share their files, images, videos, notifications, and so on. A more rigorous specification can be found at the following link, which describes the high level requirements of the application. Requirements.

Motivation

As for the general motivation, the aim of the development of the following project is that in the chat application there is no central database that could violate the information shared by users. The purpose is to seek the security provided by the privacy provided by the decentralization of the application, so that all users who use it feel safe and secure that the data they share is not compromised.

Use cases

Here are two cases of uses in which our application shares a text file: the first one being between two users and the other case, a user sharing a file with several. Diapos0 Case One (1-1) Diapos1 Case Two (1-)*

1.2. Quality Goals

Main characteristics of our application.

Table 1. Quality Goals
Nr	Quality	Motivation
1	Security	The chat should not have weak points that violate the data and files of users, as well as provide visibility only to those users involved in the chat.
2	Usability	It must be a simple application in use for all types of user, that is intuitive and that entails a very easy learning curve.
3	Availability	The application must be ready to run at any time, and as long as there is a connection, the user should be able to use all the features offered by the chat.
4	Efficiency	Messages should be sent as fluidly and quickly as possible, without any loss of information.
5	Scalability	The application is functioning correctly as the number of users grows.
6	Decentralized	Main objective in accordance with functional requirements, we will use SOLID requirements for this purpose to protect user data.

1.3. Stakeholders

Table with the people involved in the project

Table 2. Stakeholders
Stakeholder	Description	Goal/Boundaries
Chat Users	Users of the developed application.	Be able to chat in real time with a person or group of people, with ease of use and comfort.
Inrupt	Company interested in the application and that has proposed us the challenge to develop it.	Obtain a decentralized and secure application using SOLID specifications built by students.
José Emilio Labra Gayo	Coordinator of the Software Architecture subject.	Person who participates in the evaluation of the application and who is also interested in its correct development fulfilling the quality attributes.
Team	Development team	Develop an application that will work and archive the minimum requirements set out in the beginning.

2. Architecture Constraints

2.1. Introduction

There are certain limitations that may restrict our application, which are different in type and scope.

2.2. Constraints

Table 3. Technical Constraints
Constraint	Background and / or motivation
Programming language	TypeScript will be used as the programming language to build the application as it is extremely flexible and confortable to use for web based applications.
SOLID Specifications	The Chat must be decentralized, using SOLID POD tecnologies
Decentralized architecture	It must be a chat where the user’s data is separated from the application that uses it.
Compatible and stand-alone application	This application must be compatible with any operating system and major web browsers (Chrome, Firefox, Opera, Edge …).

Table 4. Organitazional constraints
Constraint	Background and / or motivation
Team	The team will be formed by Aida Maria Gonzalez, Elena Puga, David Canle, Alberto Nuñez, German Iglesias and Jaime Fernández.
Timetable	The project will be carried out during the Software Architecture course, which will be approximately four months.
Project cost	No budget is available for the project, which reduces our resources for the development of the project.
Version Control	A GitHub repository (dechat_es4a) will be used to keep the project development up to date and available to all participants anytime, anywhere.

Table 5. Conventions
Constraint	Background and / or motivation
Arc42 Template for documentation	Use of arc42 templates written on AsciiDoc.
Language	We have decided to use English for the development of the project in order to seek greater international reach.

3. System Scope and Context

The scope of our project is to create an app that can communicate two people without their data having to go through an external server, that is, this app uses data that is in our private server (POD).

For all this we are using Solid that is a tool that allows users to mark their data, which allows them to have their own server. They can also specify which data to communicate with whom and which apps can access which parts of their data do not need that your data go through an intermediary that makes money with private data

The stakeholders who can use this app will be anyone who has added as a friend in solid to the other person, so that they can access their POD with the data of this person.

In this application we will use an interface that allows you to see the name of the other person with whom you are chatting and the messages sent and received, we will have a box to write the message to send. These messages will be stored in the POD so that conversation the messages are completely isolated and only people who chat among them will be able to access them.

The communication interface is that of any chat of this style, so that stakeholders will be known and therefore more intuitive. On the other hand our interface will be made with a library of JavaScript with the aforementioned, an area to write the text to send, another to see the conversation we have with the other person and finally a small part above in which we will see the name of the other person.

Diagram:

basicDiagram

3.1. Business Context

The communicated parties are the stakeholders that can be anyone who wants to have a conversation with this app. There are also the PODs of each of the users that will be used to save the data.

The interface will receive the messages of the two users and will save the conversation in the PODs of the two users. On the other hand it will show information of both users. The communication with Solid and the POD will be received in the application with the use of specific JavaScript libraries. The RDFs returned by the PODs will be used by the application to access the data of both users.

Being an app as simple as a chat, users should not have any problem with the use of this application.

Table:

	Users	The PODs
Name	The both see each other’s name in the application’s interface	The application calls the two PODs and you are given back the username
Message Received	Receive the other’s message and it seen in the part where the conversation shows our interface	The application communicates the message that is in the other POD of the one that sent the message
Message Sent	Write the message in the box and press the button to send it, you can see it just like the once received	The message is stored in the POD of the sender, and the application receives the link from the node that stores the message and communicates it to the other

Users

The PODs

Name

The both see each other’s name in the application’s interface

The application calls the two PODs and you are given back the username

Message Received

Receive the other’s message and it seen in the part where the conversation shows our interface

The application communicates the message that is in the other POD of the one that sent the message

Message Sent

Write the message in the box and press the button to send it, you can see it just like the once received

The message is stored in the POD of the sender, and the application receives the link from the node that stores the message and communicates it to the other

3.2. Technical Context

The implementation of the application has been made in angular and has a user interface that allows you to create a chat with another person who has been added to the POD.

After start a conversation, the messages of the app are stored in a private folder within the POD of each person, stored in order and using the necessary turtle system to store the information of each message.

When you reconnect, read the messages stored in the PODs again to restore the conversation.

In addition, profile images of the users are collected as well as the name of these to be displayed in the application.

The data processing is done through a rdflib library to deal with the storage of data in rdf and different modules are used that provides angular to work with solid.

4. Solution Strategy

The key of this project is the decentralization of data.

For working with data decentralization we will be using Solid, a project by Prof. Tim Berners-Lee, as is one of the prerequisites of this project, has and intuitive form of use and works very well with different programming languages allowing us to have had more alternatives about this choice the first weeks of our planning.

Angular was the framework chosen to program with as it counts with different libraries, as RDFLib or solid-auth-client for example, that makes working with solid a lot easier and way more secure; it is also a high demanded and used framework and it gives us the opportunity to learn more about it and about TypeScript. The last reason is Angular will make our code more valuable for the community as there are not so many applications for Solid+Angular for now.

We are going to use WebStorm for coding and editing our documentation as it is an IDE that provides both functionalities ,most of us are used to it and has many funcionalities and plugins for Angular. Also, it is compatible with Github, the version control manager we are going o use, as is the one used in our university and one of the leader platforms to share free source code.

Regarding design we will be using the MVC pattern that Angular already provides. Solid provides by itself a modular design form by different pods containing the client data, and we want to keep the decentralization of that data as clear as possible so by structuring the project with this pattern we will have the exact responsibilities of each layer separated and the way they communicate to each other will be very clear and visual.

To achieve all this we will be following the agile methodology SCRUM with some modifications. As all of us will have the software architect role so there won’t be a SCRUM master and everybody will have the same level and responsibility. We will document and follow this methodology by the different funcionalities of Github as the Dashboard, milestones, issues,etc.

Finally for testing we will be using Cucumber for the acceptance testing and Karma and Jasmine for the login testing.

5. Building Block View

5.1. Whitebox Overall System

The decentralized chat app, deChat, is based on SOLID, which is a project led by Tim Berners-Lee, father of the World Wide Web. Its name stands for "SOcial LInked Data". The main goal of SOLID is to give the user full control over their data and who can access it, to achieve this, the SOLID PODs have been created. These PODs also let users decide where their data is stored, it can be stored in their personal PC or in an onlive server from various SOLID providers. In order to Log in to the deChat app you can use your SOLID POD.

Whitebox Overall System

The main elements that make part of the app and will communicate with each other are the following:

Name	Responsibility
User	Users will log in using their POD, from there, they can have conversations and share files with other users
User POD	They are used to store the data of his owner, givimg permission to other users if the application that use them need them
deChat app	This app allows users to communicate with each other, provides the functionality and views necessary for that matter. It modifies the POD to fit it’s funcionality

Name

Responsibility

User

Users will log in using their POD, from there, they can have conversations and share files with other users

User POD

They are used to store the data of his owner, givimg permission to other users if the application that use them need them

deChat app

This app allows users to communicate with each other, provides the functionality and views necessary for that matter. It modifies the POD to fit it’s funcionality

5.2. Level 2

Whitebox Inner Structure System

Name	Responsibility
User POD	They are used to store the data of his owner, givimg permission to other users if the application that use them need them
index.ttl	It’s where the chat is stored in a chat turtle format
deChat app	This app allows users to communicate with each other, provides the functionality and views necessary for that matter. It modifies the POD to fit it’s funcionality
chat.component.ts	section of the app that treats the data recieved from chat.service to show it to the user in the chat
chat.service.ts	section of the app reads both PODs to pass the messages to chat.component, and writes in it’s own POD with the messages written in the App by the user

Name

Responsibility

User POD

They are used to store the data of his owner, givimg permission to other users if the application that use them need them

index.ttl

It’s where the chat is stored in a chat turtle format

deChat app

This app allows users to communicate with each other, provides the functionality and views necessary for that matter. It modifies the POD to fit it’s funcionality

chat.component.ts

section of the app that treats the data recieved from chat.service to show it to the user in the chat

chat.service.ts

section of the app reads both PODs to pass the messages to chat.component, and writes in it’s own POD with the messages written in the App by the user

6. Runtime View

6.1. Log in

1. The user runs the application:

1.1. Subscenario 1: The user doesnt have a POD, they have to sign up to either Inrupt or Solid Community. (Solid Community recommended since the current version has some bugs with Inrupt's PODs)

1.2. Subscenario 2: The user does already have a POD, but they are not logged in, then they select their provider and enter the credentials.

1.3. Subscenario 3: The user has a POD and is logged in, in this case the user can use the application from the get-go.

6.2. Send messages

In order to send a message the user has follow the following steps:

1. The user opens the app, logs in, and then they can go to the chat page.The chat page has two main sections, the conversation list and the chat box.
2.1. to chat with someone you need to have them as a friend. if you want to add someone as a friend you can do so by going to the new contact section of the contacts button and putting his POD ID there.
2.2. To chat with a friend the user first selects a contact to have a conversation with in the contacts button, which will add a conversation to the contact list. If there is already a chat ongoing it will be on the conversation list.
2.3. upon clicking a conversation will update the chatbox, loading said chat
3. When a chat is loaded the user can start talking to the selected friend by writing in the text box located in the bottom of the chat box. The app reads the friend’s POD folder for this conversation and checks for messages from the friend to show the user
4. The user clicks "Send" (this action can also be done by pressing the enter key) and then the message will be writen in the submitter’s POD. The other user application can read the messages from the submitter’s POD and display them

7. Deployment View

7.1. Infrastructure

Basic Deployment View

Table 6. Deployment nodes and artifact
Node/Artifact	Description
index.html	Html file that contain all information to execute our application in the web browser.
User Device	A browser that can run our application. Chrome or Firefox should work.
Web Hosting Service	Webpage where the application is deployed.
Home SOLID Server	Server created and administrated by the client with his/her own POD.
Inrupt Provider Web Server	Free provider of PODs by the commercial entity established by the Solid founding team.
SOLID Community Provider Web Server	Free provider of PODs for the Solid community, by the Solid community.

8. Cross-cutting Concepts

8.1. Domain Model

In th following image, we present you the arquitecture of components we are using in this project.

Domain Model

8.2. Domain Concept

In our application we have three main domain concepts:

POD: Place where all client data is store.
Client: Stakeholder that uses the chat to send and receive messages.
Message: Text or file sent by client with information for other client.

8.3. Architecture and design

We are using the architecture design in Angular. It is composed by modules and components following MVC (Model-View-Controller).

8.3.1. Modules

These are the main modules to run the app:

Modules

8.4. User Experience

8.4.1. User Interface

Design of the user interface for the app. The user interface is written with Angular 7. We also used Bootstrap templates and the default design from tutorial of SOLID Inrupt website with Angular. We have pages for the login, registration, main page and chat.

Figure 1. Login Page

Figure 2. Registration Page

Figure 3. Home Page

Figure 4. Chat Page

There is a possibility to change background and colors from the chat. Just clicking in the three points in the chat page. Besides, in the help button from navigation bar you can find this documentation plus user’s guide and about us.

8.4.2. Internationalization

This app will be available in English.

8.5. Under-the-hood

8.5.1. Persistency

The application will be using the costumer POD as database from the SOLID server where the account is hosted. This POD will have all personal data and files and none will be able to administrate it except the owner, the costumer.

8.5.2. Exception/Error Handling

Most of the error handling in the application occurs in the methods of the solid-file-client library: the expected succesful event (reading a file, updating a file, creating it…) is used both as condition of not trowing an exception and the opening of a try statement. Along the whole code of the succesful event we may throw an error at any point, which lets us run the error code of the method a prime example of this kind of error handling would be the addFriend() method in chat.component.ts, which handles the WEBID given to add a friend and throwns am error in different parts of the code after sucessfully reading the index.ttl of the user

8.6. Security and Safety

8.6.1. Security

All files and data from client will be contained in the POD so the costumer will be the only one who can get it. The chat will be decentralized so it will do it very secure.

8.6.2. Safety

This application itself doesn’t do anything that poses a threat: it simply reads the pods and whrites on it’s own, which leaves it not very open to vulnerabilities.

8.7. Development Concepts

8.7.1. Testability

We made several tests for our project:

Load Testing: tests with Gatling.
User Acceptance Testing: made with Cucumber.
Usability Testing: made with some volunteers. They have different ages and different knowledge of informatic.
Monitory and Profiling Testing: tests with Google Chrome.
Unit Testing: tests with Karma and Jasmine.

9. Design Decisions

The main and actual decisions are further explained at the fourth section of this document, Solution Strategy, but an index of these is:

Architecture and design decisions
1. MVC by Angular
2. Modular Desing by Solid
Programing languages
1. Angular [TypeScript]
Technologies
1. WebStorm by Jetbrains
2. Github
Methodologies
1. Scrum
Testing
1. Cucumber
2. Karma and Jasmine

10. Quality Requirements

10.1. Quality Tree

quality tree

10.2. Quality Scenarios

Usage Scenarios:

An user attempts to access the porfile of a friend → the application makes a request to the server to access the porfile’s contents of the friend’s POD, retrieves them, and shows them to the user within 1 second (multimedia content may vary)
An user attempts to access the porfile of a person that has explicitly set their profile to private → the application makes a request to the server to access the porfile’s contents of the person’s POD, but due to the lack of permission the access is denied and the requesting user is informed within 1 second
An user changes his/her porfile picture → The application request the server storing the POD to edit the contents, and upon obtaining permission he changes the picture. from now on people accessing this porfile will see the updated picture
An user wants to start a conversation with a friend → The application makes a request to estabish a line of communication between the current device and the device in which the friend has his app installed within 3 seconds.

Change Scenarios:

The application is modified to be integrated with Github (or any website with social interaction for that matter) → the Application now can retrieve information from the linked GitHub account, informing the user with each relevant action (Commits, updates in repostories, requests to participate in projectts, etc). If Application friends link their accounts to the application and they allow that information to be shared in settings, the user will be informed that they share platform.

11. Risks and Technical Debts

A clear technical risk is that the libraries used by us while being developed could still give failures in specific cases.
Another risk could be that Solid is a project that has recently come out and therefore there is not a large community that explains its use. And this lack of information is also something that must be taken into account.
On the other hand, our lack of knowledge about the functioning of Solid can be a risk, since it may take longer than expected to perform the application. Like the ignorance of many of us about the use of the JavaScript programming language or the use of libraries related to Solid.
We can also see that the use of RDF as output files that Solid uses is a bit more complex, and not so much that, as it is quite different from the conventional way of storing data that has the relational databases that we are used to use. But this risk is solved because we will use libraries that manage the output files of Solid.
Finally, a risk that also exists is that it is the first time that we are going to exercise as software architects. Therefore, we may make mistakes in some design decisions or even find it hard to coordinate.

Measures

To reduce some of these risks we are trying to inform ourselves as much as possible both in the use of Solid, as well as the use of libraries that JavaScript uses to make applications with Solid. Many of us are looking for information that we add to the repository wiki. In addition to the meetings we are doing in practice class, we are meeting separately to be more organized and prepared

12. Glossary

Term	Definition
Javascript	the main clent-side programming language of HTML and the Web. It’s the programming language chosen for this project https://en.wikipedia.org/wiki/JavaScript
HTML	HTML stands for Hyper Text Markup Language; HTML describes the structure of Web pages using markup
SOLID	a web decentralization project that aims to separate user’s data and applications, led by Tim Berners-Lee, the inventor of the World Wide Web. This is the project in which this project is based on. SOLID It stands for Social Linked Data
POD	An Acronim for 'Personal Online Data', it refers to the personal decentralized storage used in SOLID aplications. Its stores the data from the user outside of the application, allowing the user to retain control and ownership of personal information.
REST	It refers to a software architectural style in web applications in which the full extend of HTTP protocols is used, avoiding abuse of the POST and GET well-known protocols. while HTTP is an application protocol, REST is a set of rules, that when followed, enable you to build a distributed application that has a specific set of desirable constraints.
MVC architecture	An architectural pattern that will be used on this application. Commonly used for developing user interfaces that divides an application into three interconnected parts. This is done to separate internal representations of information from the ways information is presented to and accepted from the user. More info: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller https://developer.mozilla.org/en-US/docs/Web/Apps/Fundamentals/Modern_web_app_architecture/MVC_architecture
Decentralized/Decentralization	Within the software context, it refers to the lack of a single entity controling the storage, processing power and/or management of a software entity. within the SOLID aquitecture context in particular, it usually refers to the lack of a single entity to manage the storing of the user’s data. This returns the ownership of the user’s data to the user itself.

Term

Definition

Javascript

the main clent-side programming language of HTML and the Web. It’s the programming language chosen for this project https://en.wikipedia.org/wiki/JavaScript

HTML

HTML stands for Hyper Text Markup Language; HTML describes the structure of Web pages using markup

SOLID

a web decentralization project that aims to separate user’s data and applications, led by Tim Berners-Lee, the inventor of the World Wide Web. This is the project in which this project is based on. SOLID It stands for Social Linked Data

POD

An Acronim for 'Personal Online Data', it refers to the personal decentralized storage used in SOLID aplications. Its stores the data from the user outside of the application, allowing the user to retain control and ownership of personal information.

REST

It refers to a software architectural style in web applications in which the full extend of HTTP protocols is used, avoiding abuse of the POST and GET well-known protocols. while HTTP is an application protocol, REST is a set of rules, that when followed, enable you to build a distributed application that has a specific set of desirable constraints.

MVC architecture

An architectural pattern that will be used on this application. Commonly used for developing user interfaces that divides an application into three interconnected parts. This is done to separate internal representations of information from the ways information is presented to and accepted from the user. More info: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller https://developer.mozilla.org/en-US/docs/Web/Apps/Fundamentals/Modern_web_app_architecture/MVC_architecture

Decentralized/Decentralization

Within the software context, it refers to the lack of a single entity controling the storage, processing power and/or management of a software entity. within the SOLID aquitecture context in particular, it usually refers to the lack of a single entity to manage the storing of the user’s data. This returns the ownership of the user’s data to the user itself.

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

deChat - Decentralized Chat_es4a