Home

Arquitectura de Roar

La red social Roar está compuesta por los siguientes tipos de servidores:

• Servidor Backend: Este tipo de servidor se encarga del almacenamiento de la información en Roar.
• Servidor API: Ese tipo de servidor implementa la lógica del negocio de la aplicación. Conecta el frontend de la red social con el backend de la misma
• Sevidor Frontend: Implementa la interfaz visual.

Protocolo utilizado

El protocolo utilizado para la implementación de este proyecto es una adaptación del protocolo ActivityPub que es un protocolo de red social descentralizado basado en el formato de datos [ ActivityStreams ] 2.0. Proporciona una API de cliente a servidor para crear, actualizar y eliminar contenido, así como una API federada de servidor a servidor para enviar notificaciones y contenido.

ActivityPub proporciona dos capas:

• Un protocolo de federación de servidor a servidor (para que los sitios web descentralizados puedan compartir información)
• Un protocolo de cliente a servidor (para que los usuarios, incluidos los usuarios del mundo real, los bots y otros procesos automatizados, puedan comunicarse con ActivityPub usando sus cuentas en servidores, desde un teléfono, escritorio, aplicación web o lo que sea)

Objetos

Cada objeto en Roar es una instancia de la clase RObject, la cual tiene dos atributos: id y tipo, ambas cadenas de caracteres. El id es un identificador único para cada objeto y el tipo se referiere al tipo del objeto.

Colecciones

Una colección es un RObject que permite guardar otros RObjects de forma distrbuida entre los diferentes servidores backend. Los objetos de este tipo cuentan con métodos para agregar y remover objetos.

DHT

Una de las colecciones implementadas fue un DHT (un diccionario distribuido). Esta estructura fue implementada según la bibliografia suministrada por los profesores.

Cada nodo de esta estructura tiene un diccionario en el cual se guardan sus elementos, ademas de otro diccionario en el que guarda los elementos de su predecesor. Además contiene los id de su predecesor, sucesor y su segundo sucesor. Cuando un nodo no puede acceder a su sucesor tratara de contactar con su segundo sucesor. En caso de tampoco ser posible comenzará a iterar por su tabla de fingers tratando de conectarse a uno de esos nodos. Si el nodo pudo hacer contacto con su sucesor entonces se actualiza su segundo sucesor (pues este podría haber cambiado). El resto del funcionamiento de esta estructura, es fundamentalmente similar a como se describe en la bibliografía.

Lista distribuida

La lista distribuida es una variante de lista la cual distribuye sus elementos por los servidores disponibles en el sistema. Esta se utiliza para la bandeja de entrada y la bandeja de salida. La bandeja de salida contiene todas las actividades que ha realizado un usuario en el sistema y la bandeja de entrada contiene las actividades que le han llegado al usuario por parte de los usuarios a los que sigue.

La idea de tener una lista es para conservar el orden en que las actividades se iban realizando y se decidió que fuera distribuida pues la información a guardar podía ser demasiado grande.

La estructura consiste en una lista circular doblemente enlazada que mantiene el funcionamiento de una linked list. Para esto se guardan referencias al primer y último nodo de la lista y estos a su ves guardan referencia de su antecesor y sucesor (de esta forma para cada nodo). Y cada nodo guarda los datos de su predecesor además de los suyos.

Los nodos tienen una capacidad limitada que puede aumentar con el tiempo. Para almacenar información existe una propiedad current que hace referencia al nodo que se está llenando actualmente. Cuando el nodo alcance su máximo de capacidad se pasa al siguiente. En caso de que todos estén llenos se procede a ampliar la capacidad de cada nodo y se irán corriendo los elementos hacia los primeros nodos de la lista.

En caso de desconexión de un nodo se tomará el último nodo y si está vacío este ocupará su lugar copiando los datos del nodo caído desde el sucesor del nodo caído. Si el último nodo tiene datos se amplia la capacidad de todos los nodos y se distribuyen los datos como se explicó anteriormente.

Actor

Esta clase describe a los usuarios en la red, que son quienes interactuan entre sí en la misma. Cada actor tiene:

• id: Alias del usuario. Este debe ser único dentro de toda la red.
• inbox: Lista distribuida que contiene los actividades que han creado o compartido los usuarios que este usuario sigue.
• outbox: Lista distribuida que contiene las actividades que ha realizado el usuario.
• following: Conjunto de todos los usuarios seguidos por el usuario.
• followers: Conjunto de todos los usuarios que siguen al usuario.
• user_name: Nombre de usuario
• hashed_password: Hash de la contraseña
• a1: Hash de la respuesta a la pregunta de seguridad 1
• a2: Hash de la respuesta a la pregunta de seguridad 1
• preferences: Categorías que prefiere el usuario

Post

Esta clase describe las publicaciones de un usuario. Cada post tiene:

• id: Identificador del post
• author: Usuario que creó el post
• content: Texto del post
• published: Momento en que fue publicado
• reply: En caso de ser respuesta a algún post, el id de este post
• likes: Conjunto de alias de los usuarios que han dado like al post
• shared: Conjunto de alias de los usuarios que han compartido el post
• replies: Conjunto de id de los post que respondan a este post
• cat_label: Categoría con la que se clasifica este post mediante machine learning (Ver Clasificador de Textos) por defecto tiene valor -1 que significa que no tiene clasificación (o que no se ajusta a las etiquetas que se usan para clasificar).

Activity

Consiste en las actividades que puede realizar un usuario en la aplicación

CreateActivity

Consiste en la actividad de crear. En este caso un crear o responder un post. Esta consta de:

• actor: Actor que creo la actividad.
• obj: post que se crea.
• published: Momento de publicación.
• to: A quién va dirigido el post.
• replay: En caso de ser respuesta de algún post, se guarda este.
• replies: posts que responden a este post.

DeleteActivity

Consiste en la actividad de eliminar. En este caso un eliminar un post. Esta consta de:

• obj: El post que se elimina.

FollowActivity

Consiste en la actividad de seguir a un usuario. Esta consta de:

• actor: Usuario que se sigue.

UnfollowActivity

Consiste en la actividad dejar de seguir a un usuario. Esta consta de:

• actor: Usuario que se deja de seguir.

LikeActivity

Consiste en la actividad dar like a un post. Esta consta de:

• obj: post al que se le da like.
• actor: Usuario que da like.

UnlikeActivity(Activity)

Consiste en la actividad quitar like a un post. Esta consta de:

• obj: post al que se le quita el like.
• actor: Usuario que realiza la acción.

ShareActivity(Activity)

Consiste en la actividad dar compartir a un post. Esta consta de:

• obj_share: post que se comparte.