1. Introduction and goals

Logo

The main goal of this project is to create a decentralized chat, better said, an application or program through two or more people can communicate in a way that all the information does not pass through any external server, avoiding confidentiality losing of the data, allowing real private conversations.

We are going to use SOLID framework to get that decentralization. Every user must have a SOLID POD to log in and use our application

1.1. Requirements

The application will have a "home" page with a list of the users whose the "protagonist" could communicate. After selecting one of them, he will be able to send and receive messages. First, we are going to implement just sending messages, then, we would like to add the possibility of pictures transmission, or even video recordings.

1.2. Quality goals

With this project we must seek to get a real private peer to peer communication between users, avoiding information leaks or security problems. Our most important quality scenarios are:

  1. Functional suitability → The application must correctly meet the minimum requirements for a conversation to take place between two users. At the first place we want a basic text conversation

  2. Usability → The application must be easy to use. All users must be able to use the application, even users with little knowledge.

  3. Efficiency → The time between sending and receiving messages must be reasonable.

  4. Testability → The application must pass our unit test without any problem.

1.3. Stakeholders

The users whom the application is directed are exposed just below. All the users must be capable of log in the application and communicate

Rol

Contact

Expectations

Client

Regular users of the application

Communicate with another contact

Teachers

Teachers of the subject

Decentralized and accesible application using SOLID

SOLID STAFF’S

SOLID Developers and employees

Usable, accesible and "comercial" aplication with a correct use of SOLID

2. Architecture Constraints

Table 1. Table of constraints
Constraints Explication

SOLID

The chat must be decentralized using the SOLID tecnology.

Asciidoc

The documentation must be done using asciidoc.

Arc42

The template for documentation used is Arc42.

Time

The project must be finished before 05/09/2019.

Money

The project will be created with 0 cost.

People

4 programmers will work on the project.

Github

The version control tecnology will be github.

3. System Scope and Context

Our application consists on a decentralized chat in which a user can have conversations with other users. Based on this information we can differentiate two different contexts of our system:

3.1. Business Context

The following diagram shows how all parts of the system communicate when chatting, that is, when one user sends a message to another:

Business context diagram of dechat_es3b

As you can see in the diagram, each user has his own SOLID Pod, where all the messages he sends will be stored. However, sent messages will not be stored in the receiver’s Pod, keeping the SOLID philosophy in which each user has full control over their data. This way to see the message history of the conversation both users will have to allow the other one the visualization of your sent messages.

Table 2. Summary of actions carried out in communication
Involved part Action

User1

Sends a message to User2

User1 Pod

Store the sent message

User2

Receives the message from User1 and answers it

User2 Pod

Store the response message

3.2. Technical Context

For now the technical context of our application shows in a very general way the technologies to use, as the application is implemented will be added to the project new technologies and updating this section.

Technical context diagram of dechat_es3b

The application consists of a device responsible for logging in or out and another that will handle the char itself, ie sending and receiving messages. The whole application itself will use a Pod server that will identify the user and save the messages sent by him.

4. Solution Strategy

Because of our little experience on the Software Architecture World some or this early decisions may change in the future if better technologies are discovered.

  • Technology decisions:

The language selected to create de application is going to be JavaScript. It was selected because it’s good integration with SOLID. The use of SOLID will make a decentralized chat using PODS so we assume no database will be needed. In case it’s finally needed we would use a SQL database because of our knowelge about this database type.

The grafic interface will be done using html and css, this and angular will make our app run both in Desktop computers and smartphones.

  • Decisions about the top-level decomposition of the system:

Because of the angular framework it will be easier to implement a MVC(Model View Controller) to have a better organization o the code

  • Decisions on how to achieve key quality goals:

  • Organizational decisions:

The decisions about organization will be agile, we will have meetings every week were we will distribute the tasks.

5. Building Block View

We are going to partition our system in 2 totally different boxes. We begin the decomposition by displaying a white box description of the overall system with the Login, and the application itself. Then, in the next box, we are going to show all the parts that our application has and uses to send messages.

WhiteBox of the system

First of all the chat itself is being created in the createChat.js after creating it the chat is gonna be a semanticChat type variable. When the user sends a message the MessageManager file takes place distributing it to the two pods. Messagemanager stores the message in the sender’s pods and then calls the dataSync file to store it into the receiver’s POD. After all that process, the MessageManageer file gets the new message through the rdjsFactory file which gets the message from the pod.

6. Runtime View

6.1. First Scenario: Login into deChat

This is the first situation the User finds when enter in our page, to do any sort of actio he must be logged in.

Login

6.2. Second Scenario: Sending a Message

The activity of sending a message to a friend is drawn below:

message

7. Deployment View

7.1. Sending Message View

The procedure of sending a new message is fairly simple. The First User sends a Message to a friend through the interface. The interface transmits the message to deChat app which drives the message to the Pod of the principal user and to the friend’s POD as well. Then deChat catches the new message from the friend’s POD and send it to the interface.

View

7.2. Infrastructure

The infrastructure requires 2 machines (hardware) per user; The first is the one user is going to use to send or receive Messages, it must support HTML5 and javascript. The other machine is SOLID servers which going to save all the information in the user’s POD.

8. Cross-cutting Concepts

concepts

8.1. Problems during development

We had many problems and issues during the project building. We got to solve most of them in this short amount of time, Probably the most challenging ones are:

  1. Microsoft Edge incompatibility → Is known that a lot of javascript applications do not work on the new Microsoft’s browser, and our app is not an excepcion.

  2. Loads chats that are not supposed to sbe shown → When you open a new conversations, sometimes in the text area are shown messages of another past conversation. We are fixing this issue.

  3. Delay on sending Messages → We have a delay about 5 seconds between sending and receiving messages. It is still under development.

8.2. Technical risks

  1. Using SOLID: We have never ever used a technology like SOLID. This was probably the most challenging problem we had, We were unable to find easy and functional examples even though the SOLID company has a bunch of it, most of them didn’t work properly.

  2. Node JS language → This is the first "big" application we build in Node and javascript, so we had to do a lot of self-learning.

8.3. Solution

Our chat is built on the top of the SOLID Chess project. We cleaned the code of the game and converted it into a functional chat. At first we thoght that it would be easy using this example as our base, but we could not be more wrong. We had to dissasembly the example and try to understand a bunch of code that was new to us. A lot of methods werent aporting us any funtionality and others were not adapted to do the function we wanted.

After a lot of ours of work we got a working decentralized chat with a fairly simple and greate interface. We think that is very important to decentralize the conversations and keep the users privacy private.

9. Design Decisions

9.1. Architecture

Peer-to-Peer (P2P). This architecture is used in a SOLID application

9.2. Language

Among the following three languages:

  • Java

  • C#

  • JavaScript

We have decided that the best language is JavaScript since the other two languages (Java and C #) do not have direct support of Solid and it would be us who would have to implement a controller that communicates with SOLID. However, the disadvantage of JavaScript is that we need a level that no member of the team currently has. Despite this, among all we have seen that the best option is to use JavaScript.

9.3. Database

For the moment we will not use any database because we do not see it necessary. As the project progresses, if we see that the project requires a database, we will use a relational database such as MySQL, as we have used them in other subjects and we already have some experience with them.

10. Quality Requirements

This section deals with the quality requirements of the application using the quality tree and quality scenarios. The quality goals are further explained in section 1.2.

10.1. Quality Tree

Quality tree diagram of dechat_es3b

10.2. Quality Scenarios

Quality attributes Scenario Priority

Functional suitability

The application must correctly meet the minimum requirements for a conversation to take place between two users

High, high

Usability

The application must be easy to understand and use to satisfy the user

High, medium

Efficiency

The sending of messages must be correctly reaching the receiver in reasonable times

High, medium

Testability

The application must pass unit tests and integration tests correctly

High, medium

Maintainability

Ensuring continuous improvement against errors, unexpected component failures and new requirements

Medium, high

Securability

Require each user to identify themselves in order to use the application and allow them to control who has access to their data

Medium, medium

Scalability

Although the number of users increases, the application will continue to operate with the same efficiency

Medium, medium

Priority defines the importance of the quality attribute for our application, it is measured in three levels (high, medium, low) which in turn also have three levels. For example, high high is the highest priority while high medium would be somewhat lower but not as high as medium high.

11. Risks and Technical Debts

List of identified technical risks or technical debts, ordered by priority

  • Inexperience with the technology that we must use: One of the requirements is using the SOLID platform in our application. Being a new technology, we have to learn.

  • Loss of time to specialize in a programming language: We have decided to use a language (JavaScript) of which we have a slight notion. This can delay us when carrying out the project. However, if we had chosen another language we would have to learn how to adapt that language to the SOLID platform. Therefore, comparing the advantages and disadvantages of each one, we decided that it was best to use the language previously mentioned.

  • Loss of team members: This could harm us in the future since we are 4 in the team and could cause us to delay with deliveries.

  • Little applications on which to base ourselves: Being a practically new technology, there are hardly any projects that we can use as an example.

To minimize each of the risks we decided that it was best to learn about SOLID and Javascript with a small application by following the steps that appear on this page: https://solid.inrupt.com/docs/writing-solid-apps-with-angular so that when faced with the application, the problems are not so big and we already have part of the work done. We also commit ourselves to help each other so that deliveries are on time.

12. Glossary

Term Definition

Solid

Is a web decentralization project led by Tim Berners-Lee, the inventor of the World Wide Web. More information in https://en.wikipedia.org/wiki/Solid_(web_decentralization_project))

Web Server

It is a computer that is part of a network and that provides services to other equipment

Angular

It is a framework for web applications developed in TypeScript, open source, which is used to create and maintain web applications of a single page.

JavaScript

It is an interpreted programming language, oriented to objects, based on prototypes, imperative, weakly typed and dynamic. It is mainly used in its customer side form.

MySQL

It is a relational database management system based on structured query language (SQL).

ARC42

It is a structure for documenting software systems. More information in https://arc42.org/

C#

It is an object-oriented programming language developed and standardized by Microsoft as part of its .NET platform

Java

It is a general object-oriented programming language that allows application developers to write the program once and execute it on any device, meaning that the code that is executed on one platform does not have to be recompiled to run on another.

Framework

Abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software.

SOLID Pod

Web-accessible personal online datastore

Decentralized

In computer engineering; Communication that does not pass through external servers.

Agile methodology

Iterative development methodology that values human communication and feedback, adapting to changes, and producing working results.

Software

Set of instructions, data or programs used to operate computers and execute specific tasks.

P2P

It is a distributed application architecture that partitions tasks or workloads between peers.

Unit testing

Is a level of software testing where individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed.

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.

Software unit

A unit is the smallest testable part of any software. It usually has one or a few inputs and usually a single output. In procedural programming, a unit may be an individual program, function, procedure, etc. In object-oriented programming, the smallest unit is a method.

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.