Note

Authors:

Carlos Álvarez Rábano

David Carballo Baz

Iván Gómez Pinta

Cristina Ruiz de Bucesta Crespo

1. Introduction and Goals

Our goal is to create DeChat, a descentralized chat app based on the solid specifications. This project will be developed by a team of five members.

1.1. Requirements Overview

The main objective is to ensure that the data does not pass through a central server, so each user saves its own data. Therefore the system will be based on a decentralized architecture where the data storage is separated from the application.

Essential features

  • Users can store their chat data in their own pods.

  • The app will allow a user to share pictures, videos or other kinds of files with other friends through the chat.

  • A user can get notifications when some friend wants to chat with him.

  • Users can have groups of friends with whom they may want to chat.

  • It will be possible to have group chats where all members receive the messages.

  • Other optional features are:

    • Users can have live calls and videos.

    • Users can share their screens in the chat.

1.2. Quality Goals

Quality attributes qualify functionality of the application. This table contains the main features DeChat looks for.

Table 1. Quality Goals
Nr Quality Motivation

1

Security

A chat must be visible only by those involved in it. The information of a user must be private and innaccessible by other users.

2

Usability

A chat should be simple and easy to use by everyone. The application should have a simple learning curve.

3

Availability

Whenever there is internet, the user should be able to use all the features of the application.

4

Efficiency

Sended messages must reach the receiver as quick as possible. No message should be lost.

5

Reliability

The app should not fail in any specific action or circumstance, so the users will trust it.

6

Compatibility

The app must work for all browsers without distinction.

1.3. Stakeholders

The following table contains the most important personas for DeChat.

Table 2. Stakeholders
Stakeholder Description Goal/Boundaries

DeChat User

Main user of the system.

Interacts with the application and all its functionalities. Send messages, all kinds of files, create group chats, send chat notifications, etc.

Inrupt company

Company interested in the app.

They are interested in the following criteria: Ease of use by non-technical people, responsiveness of the application, online independence: no central control of data, security and privacy: no vulnerability points, aesthetics and friendliness of the application, originality of the solution and usability of technical documentation.

José Emilio Labra Gayo

Coordinator of the Software Architecture subject.

He is the main tester of the application. Represents the client and its interests.

Solid new comers

Developers interested in Solid.

People who want to see the benefits of solid and decentralized applications.

2. Architecture Constraints

Constraint Explanation

Project budget

Not having a budget for the project limits the resources available for its realization

Documentation

The documentation must follow the structure defined in the arc42 template

Time limit

The project must be completed by April 30, 2019, and there must be a small functional prototype by March 12, 2019

Decentralized architecture

The system will be based on a decentralized architecture where data storage is separated from the application

SOLID technology

Data decentralization should be done using Inrupt’s SOLID technology, whereby data is stored on personal PODs

Language

Due to the requirement to use SOLID, the preferred programming language for application development is Javascript, along with the HTML and CSS languages

Version Control

Version control must be performed with Git, using the repository hosted in the GitHub service.

3. System Scope and Context

Way of working

In this introduction, we briefly describe the users and systems involved in our application. On the one hand, as users are the customers who register in the chat, the team members as developers, and the project manager as supervisor. On the other hand, for the systems we have software as Java, JavaScript, Angular, Asciidoctor, Solid…​ (the group of systems may vary).

What we work with

Here we describe why it has been decide to use the above mentioned programs.

  • Java: Because of the team members' extensive Java background.

  • JavaScript: Because it is recommended to use them for applications with Solid software.

  • Angular: Because it is a JavaScript framework that will speed up the implementation of our chat.

  • AsciiDoctor: Because it is the best processor editor to generate the project documentation through asciidoc documents.

  • Solid: Because it is a data management software whose use is adviced by the project manager.

  • TypeScript: Because it is a super-set of JavaScript, very useful for our project.

Here we explain in a more graphical way the information detailed above.

Name Type of software Reason for use

Java

Programming language

Extensive previous knowledge of Java

JavaScript

Programming language

Recommended for applications with Solid software

Angular

JavaScript framework

Speed up the implementation of our project

Asciidoctor

Text processor

Best text processor to generate asciidoc documents

Solid

Data management software

Use required by the project manager

TypeScript

Programming language

Super-set of JavaScript very useful for our project

3.1. Business Context

Behaviour

The system is based in a decentralized chat in which the communication partners are basically other users of this system. In this system they are going to be able to exchange many kind of different information in a safe environment and in an efficient way. This project is aimed mainly at independent users, but it also can be used by enterprise people who may need sometimes to get some information sent as soon as possible in a secure way, so they would prefer this decentralized system rather than use a centralized one.

How it works

In this system the information exchanged will be only the one that the user in question wants to share, apart from the username. Personal information as well as personal data would be kept in the user’s POD without access permission as long as the user wants to. Apart from this, on the chat the users will also be able to share text messages, audiovisual data such as images or videos, and other type of files.

3.2. Technical Context

The channel and transmission between a user and their partner is somehow direct, it does not take place in any server. They both have their own information and messages stored in their own PODs.

In the following diagram we can find represented the input/output and their relationship with the communication channel in out system of the decentralized chat:

Technical diagram of the system

We also can see that there is a direct connection between the PODs, as descripted previously, and there are no external servers.

4. Solution Strategy

4.1. Technological decisions and reaching the quality goals

The main objective is to achieve a chat that meets all the quality requirements detailed in the first section. The first and great technological decision is to use SOLID. SOLID could be defined as a set of modular specifications, which are based on and extend the Internet’s base technology (HTTP, REST, HTML). SOLID specifications are in GitHub.

Within the SOLID ecosystem, users decide where to store the data and who accesses it. Photos, messages, contacts…​ are stored in your Solid POD. This POD is handled by you and can be moved at any time. You decide who has access rights to the data and the synchronization is not necessary, as the data remains with you. To make an analogy, a POD is like your own USB for the Web, which you access from anywhere (Availability). Thanks to its use, safety, which is our main quality goal, is highly encouraged. How the information is used depends exclusively on the user.

Another decision is the use of TypeScript, a free and open source programming language developed and maintained by Microsoft. It is a superset of JavaScript, which essentially adds static typing and class-based objects. TypeScript can be used to develop JavaScript applications that will run on the client or server side (Node.js). This decision led to using Angular as a framework for the web application. Among its advantages is speed and performance when generating code, it is universal, facilitates the division of code, increases productivity, etc. SOLID documentation recommends its use because of the large number of useful libraries it provides that facilitate development. All these advantages provided by Angular, guarantee us the efficiency and reliability of the app. Also the fact of being universal increases compatibility.

Finally, we will explain Node.js, which is a JavaScript runtime built on Chrome’s V8 JavaScript engine. Taking advantage of the V8 engine allows Node to provide a server-side execution environment that compiles and runs javascript at incredible speeds (Efficiency).

4.2. Design Patterns

Angular tries to increase the number of browser-based applications with apability of Model View Controller (MVC). Our application will be based on this pattern as well, which separates the data and business logic of an application from its representation and the module in charge of managing events and communications. For this, we will distinguish three fundamental parts: the Model, the View and the Controller.

  • The models define the relevant mechanisms to manage the application data. The persistence system is accessed through the models and the data is created, modified or retrieved.

  • The views define the user interface aspect of the application, which is, the part that will be sent to the web browsers of the clients and therefore the information that the users will perceive. In most applications the views will be composed of HTML, CSS and JavaScript, and may also include small scripts of language executed on the server, which is usually used as a link between views and controllers.

  • The controllers are responsible for offering the catalog of actions that the web application is capable of (and that will correspond to the business logic implemented), when the user selects one of these actions the controller must execute the logic of the associate business and generate a response, in many cases these responses will generate a change in the current view of the application.

Modelo Vista Controlador con Angular

4.3. Organizational decisions

Achiving our goals requires a good and prepared organization by the team. As soon as we started the scheme, we opted to divide it in equal parts so that we could work effectively as a team.

At first we decided to divide the documentation, nevertheless, everyone ended up giving some participation in every file. After this we also began with the main project, giving the first steps with the SOLID platform, Angular, an so on. Once we had already the login interface we determined some different parts in order to be able to face the first release of the project, in which we should be able to launch the chat, which would load all the chats of the logged user, then click in the chat desired so that it would convert into the active one and we could see all the messages loaded from it. And, of course, be able as well to send messages to the user in the chat. Here we distinguished 3 clear parts: to load the chat channels, to open the chat and convert it in the active chat, and to send messages so that they would be stored in the user’s POD.

We didn’t follow any sort of development methodology for the time being, like scrum, xp or similar, so there’s no need to explain anything.

5. Runtime View

In this document we describe the main process of our application, since the user enter to the login window till the same user sends a message to the chat (group chat or individual chat).

Here we can find a general view of the full process of a user jorney:

Runtime view of the chat

6. Deployment View

In the following table it is described the way it is related the technical infraestructure with the environment, the hardware given, processors, channels and so, as well as the mapping of software building blocks to that infraestructure elements:

Deployment view of the chat system.
Node/Element Description

User workspace

The computer which the user is going to chat from as well as their environment.

Browser

Any recent browser to access the DeChat page application. Almost every single browser, such as Chrome, Firefox, Safari, Opera or Edge should work.

SOLID (environment)

The SOLID server which the user interacts with. Here the user is allowed to access the inbox of his SOLID POD as well as his friend’s one, and in the same way the main user has no permission to enter to the private folder of the friend’s POD, though he does for his own.

7. Cross-cutting Concepts

Here we find a diagram about the cross-cutting elements about the environment of the chat:

Possible topics for crosscutting concepts

8. Design Decisions

In this section we will talk about all the decisions made for the implementation of our project. Unlike section 4 of the documentation, here we explain possible advantages and disadvantages of these decisions on the development of our decentralized chat.

  • First, we would like to point out that our practice follows the architectural pattern of the MVC (model view controller). We have made this decision because we believe it is a good enough pattern to separate the layers of business logic from the persistence layer with Solid pods, for example. Even though it is not the best architectural pattern, this decision is made because it is a pattern we all know, which counteracts the possible drawbacks with a great advantage that is the convenience and speed up the coding process.

  • For the interface it was decided to start from a design already created, which allowed us to save time and focus on functionality, also getting a professional look in the chat. The design we used was made by Renan Mayrinck. His github is https://github.com/mayrinck.

  • Also, note that our application is almost entirely developed in TypeScript and using a framework called Angular. This decision has been made on the basis that they can be a framework and a language that will facilitate the implementation process of our project with respect to other programming languages and / or other frameworks. Although it may have negative consequences such as, at this moment, our project is too dependent on Angular (some functionality depends a lot on the libraries provided by Angular), which would make it very difficult to migrate this project to other languages, such as Java.

  • In order to save the data of our chat conversations, we have been recommended to use SOLID. The great advantage that it has over other databases is that it is one of the best decentralized databases, which helps us to save the data without needing a main database and that helps to improve the privacy of individual conversations between two users or in group chats between several. But it also has the disadvantage that being a very "young" software, has some difficulties of use (in terms of user interface refers) which makes rather cumbersome implementation tasks and check that the application works properly and that the POD saves the data correctly.

  • Finally, to perform the acceptance tests that check the correct functioning of the practice, we will use Cucumber. It has been decided to use it because it is one of the best programs to perform unit tests (or in this case, acceptance tests) and it will greatly facilitate the process of carrying them out. The "problem" that it has is that it can be quite difficult at first to carry out such tests, either for inexperience with the tool or for being quite tedious the implementation of tests in Cucumber on applications of Angular. We also used in the end for testing the Gatling Tests tool, since we have found it is also good for the subject.

9. Quality Requirements

As a way of sumarizing in a graphical form the requirements of the system with less priority, which is, those ones that will not create high risks if they are not fully achieved is the following kind of quality tree:

Here is the representation of the non-functional requirements of the system

9.1. Quality Scenarios

On the basis of the previous diagram, although is in some way already explained every case, in this section we are going to put some different situations as examples for the system:

  • Some programmers want to add more functionality to our project: there is needed the efficiency as well as the modifiability, in order to make it easy to get changed. The one "disadvantage" we can find is that it completely depends on Angular, so if somebody would like to make a modification it would have to be in TypeScriipt. In any case,we have tried to do the code as simple as possible and tried to explain everything.

  • It is wanted to add some tool which, automatically checks the status of a user, verifying if the user is logged - for example - in their POD. Here we will need interoperability, which we believe we achieve.

  • Imagine that this thing of decentralization becomes popular faster than the expected and your mother wants to use this chat. Considering your mother as a person non-expert in technology - or not much, at least -, we should make the application easy for her to use. This envolves usability.

  • Finally, imagine the same context as previously. We should be able to support numerous users at a time and adequately, which is scalability. Of course, we have not been able to try the app with thousands of people, but we believe it should work. Otherwise, it would be an important enhancement.

10. Risks and Technical Debts

Contents

In this document we will describe some of the problems and risks that may arise during the development of the project, ordered by priority.

Motivation

  • Scarce knowledge of JavaScript, Angular, React…​

  • Low level of knowledge about Solid

  • Problems creating pods with Solid to decentralize the application instead of creating a unifing database

  • Inexperience to carry out a project without a recommended architecture

Form

A small list of the techical risks, with a possible solution of these risks.

Problem Reason Possible solution

Poor knowledge of JavaScript, Angular, React…​

More comfort with other environments (e.g. Java)

Read documentation and perform small tests with these tools and languages

Low level of knowledge about Solid

Inexperience with this environment

Read documentation about Solid to learn more about the environment

Problems creating pods with Solid to decentralize the application instead of creating a unified database

Almost all the code implemented by the memebers of the group to manage data has been done through a centralized database

Perform small tests with a Solid pod

Inexperience to realize a project without a recommended architecture

In great part of the projects realized by the members of the team we were indicated more or less the tools to use

To find the best tools to speed up the process of codification

Github

Inexperience in working on a repository with several branches

Read documentation about Github and be careful

11. Glossary

The most important domain and technical terms used in the system itself. Order alphabetically A-Z.

Term Definition

Angular

TypeScript based open source web application framework.

Arc42

Template for architecture communication and documentation.

Code Coverage

A measure (percentage) in software tests that measures the degree to which a program’s source code has been tested. It serves to determine the quality of the test that is performed.

Cucumber

Is a software tool used by computer programmers for testing other software. It runs automated acceptance tests written in a behavior-driven development (BDD) style.

Decentralized

To keep data with yourself and not in an external server.

Integration Testing

Is a level of software testing where individual units are combined and tested as a group. The purpose of this level of testing is to expose faults in the interaction between integrated units.

Inrupt

The company risponsible of the Solid project, launched by Tim Berners-Lee.

Jasmine

Is a javascript testing framework that supports a software development practice called Behaviour Driven Development, or BDD for short. It’s a specific flavour of Test Driven Development (TDD).

Karma

Is a tool which lets us spawn browsers and run jasmine tests inside of them all from the command line. The results of the tests are also displayed on the command line.

Node.js

Open source, JavaScript runtime environment that executes JavaScript code outside of a browser.

Solid POD

[Personal Own Data] Personal storage space which you can give people as well as apps access to write or read data from.

Protractor

Protractor is an end-to-end test framework for Angular and AngularJS applications. Protractor runs tests against your application running in a real browser, interacting with it as a user would.

RDF

[Resource Description Framework] Is a standard model for data interchange on the Web.

rdflib.js

Javascript RDF library for browsers and Node.js.

React

JavaScript library for bulding user interfaces.

Solid

[Social Linked Data] Web decentralization project led by Tim Berners-Lee, the inventor of the World Wide Web.

Stakeholders

All the people that, for certain reasons, are interested in a project.

Software Architecture

High level structures of a software system and the discipline of creating such structures and systems.

Travis CI

It is a distributed and hosted continuous integration service that is used to create and test software projects hosted on GitHub.

TypeScript

A free and open source programming language developed and maintained by Microsoft. It is a superset of JavaScript, which has added optional types to JavaScript that support tools for large-scale JavaScript applications for any browser, for any host, on any OS

WebID

Is a method for internet services and members to know who they are communicating with.

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

© We acknowledge that this document uses material from the arc 42 architecture template, http://www.arc42.de. Created by Dr. Peter Hruschka & Dr. Gernot Starke.