Escola Tècnica Superior d’Enginyeria Electrònica i Informàtica La Salle
Trabajo Final de Máster
Máster Universitario en Programación Web de Alto Rendimiento
RED SOCIAL DESCENTRALIZADA CON SOLID
Alumna Profesor Ponente Profesor Ponente
Mónica Sánchez Rosero Víctor Caballero Codina David Vernet
ACTA DEL EXAMEN DEL TRABAJO FINAL DE MÁSTER
Reunido el Tribunal calificador en la fecha indicada, el alumno
D. MONICA SANCHEZ ROSERO expuso su Trabajo Final de Máster, titulado:
RED SOCIAL DESCENTRALIZADA CON SOLID
Acabada la exposición y contestadas por parte del alumno las objeciones formuladas por los Sres. miembros del tribunal, éste valoró dicho Trabajo con la calificación de
Barcelona,
VOCAL DEL TRIBUNAL VOCAL DEL TRIBUNAL
PRESIDENTE DEL TRIBUNAL
RESUMEN
Actualmente existe una gran variedad de aplicaciones web, que tienen una arquitectura de almacenamiento de datos centralizada y políticas de privacidad generalizadas que muchas veces los usuarios desconocen y dan consentimiento para ceder sus datos a terceros. Esto permite que se puedan explotar los datos mediante comercialización de información, envíos de publicidad, correo electrónicos e incluso manipulaciones etc. Consecuentemente, existe la necesidad de presentar alternativas, con el principal fin de empoderar al usuario sobre la forma en cómo administra su información en la web. SOLID (Social Linked Data) es un proyecto open source creado para incentivar la propiedad de datos, su privacidad y la creación de aplicaciones web descentralizadas. Para ello se apoya en tecnologías estandarizadas como Web Semántica y Linked Data, permitiendo que los datos de usuarios, llamados PODS (Personal Online Data Stores), estén completamente desacoplados entre aplicaciones y servidores de almacenamiento de información. El objetivo de este proyecto es investigar estas tecnologías Web Semántica o Web 3.0, Linked Data y SOLID para conocer el estado del arte y la integración de estos conocimientos para diseñar y desarrollar una aplicación web descentralizada que permita interactuar con los PODS. Se ha observado que, aunque el proyecto aún está en una fase de desarrollo temprana, entidades como MIT, Inrupt y SOLID Community dan un fuerte respaldo al proyecto SOLID.
Palabras Clave: SOLID, Social Linked Data, Personal Data Stores, Web Semántica, Linked Data, arquitectura descentralizada, aplicaciones web descentralizadas, Inrupt.
i
ABSTRACT
Nowadays there is a wide number of apps out there on the web, that have a centralized data storage architecture and generalized privacy policies that often the users are not aware of and give their consent for passing their data to third parties. This allows data to be exploded by information marketing, adds sending, spam emails, and even blackmails. Consequently, there is a need to present alternatives, with the main purpose of empowering the user about the way they manage their information on the websites. SOLID (Social linked data) is an open-source project created to incentivize data ownership, its privacy, and the creation of decentralized web apps. For this it relies on standardized technologies such as semantic web and linked data, allowing user´s data, called PODS (Personal Online Data Stores), to be completely decoupled between apps and data storage servers. The objective of this project is to investigate technologies such as semantic web or web 3.0, linked data, and SOLID to know the art and integration of this knowledge to design and develop a decentralized web application that allows interacting with PODS. It has been observed that even the project is still in an early development phase, entities like MIT, Inrupt, and SOLID community give strong support to the SOLID´s project.
Keywords: SOLID, Social Linked Data, Personal Data Stores, Semantic Web, Linked Data, Decentralized Architecture, Decentralized Web Apps, Inrupt.
ii
TABLA DE CONTENIDO
1 Introducción...... 1 1.1 Justificación del Proyecto ...... 1 1.2 Objetivos ...... 2 1.2.1 Objetivo Principal ...... 2 1.2.2 Objetivos Específicos ...... 2 1.3 Situación Actual ...... 2 1.3.1 Instituto de Tecnologías de Massachusets (MIT) ...... 3 1.3.2 Inrupt Inc...... 3 1.3.3 Solid Community Forum ...... 3 2 Aspectos Teóricos y Estado del Arte ...... 5 2.1 Web 3.0 y Web Semántica ...... 5 2.2 Linked Data ...... 6 2.3 Tecnologías Web Semánticas ...... 6 2.3.1 RDF (Resource Description Framework) ...... 8 2.3.2 RDFS (RDF Schema) ...... 9 2.3.3 RDF/XML ...... 9 2.3.4 TURTLE (Terse RDF Triple Languaje) ...... 10 2.3.5 SPARQL (Protocol and RDF Query Language) ...... 10 2.3.6 Ontologías y Vocabularios ...... 11 2.3.7 FOAF (Friend of A Friend)...... 13 2.3.8 VCARD ...... 13 2.3.9 SCHEMA.ORG ...... 14 2.3.10 OWL (Web ontology Language) ...... 15 2.4 SOLID (Social Linked Data) ...... 16 2.4.1 Arquitectura de Solid ...... 17 2.4.1.1 Gestión de Identidad ...... 17 2.4.1.2 Modelo de Datos ...... 18 2.4.1.3 Autenticación ...... 18
iii
2.4.1.4 Control de Acceso: Web Access Control – WAC ...... 18 2.4.1.5 Recursos de Lectura y Escritura ...... 19 2.4.1.6 Sistema de Archivos: LDPC (Linked Data Platform Containers) ...... 20 3 Ejecución del Proyecto ...... 22 3.1 Entorno de Desarrollo ...... 22 3.2 Servidor SOLID con Docker ...... 23 3.2.1 Prerrequisitos ...... 23 3.2.2 Estructura del Repositorio ...... 23 3.2.3 Configuración de SOLID Server con Docker ...... 24 3.2.4 Iniciar SOLID Server con Docker...... 26 3.3 Red Social Descentralizada – RSD TODAY ...... 28 3.3.1 Casos de Uso ...... 28 3.3.2 Arquitectura y Diseño de la Solución RSD TODAY ...... 29 3.3.3 Desarrollo ...... 31 3.3.3.1 Login de Usuario ...... 31 3.3.3.2 Actualizar Perfil ...... 33 3.3.3.3 Mostrar Perfil ...... 34 3.3.3.4 Galería de Fotos ...... 35 3.3.3.5 Privacidad de publicaciones ...... 37 3.3.3.6 Gestionar Amigos ...... 39 3.3.4 Puesta en Producción de RSD TODAY ...... 40 4 Análisis de los Resultados Obtenidos ...... 42 4.1 Servidor SOLID con Docker ...... 42 4.2 Aplicación Web RSD TODAY ...... 43 5 Estudio Económico ...... 45 6 Conclusiones ...... 46 7 Líneas de Futuro ...... 47 8 Referencias ...... 48 9 Anexos ...... 52
iv
9.1 Participación con la Comunidad de SOLID ...... 52 9.1.1 Privacy of .ttl registries ...... 52 9.1.2 Remove friend! 403 (User Unauthorized) ...... 53 9.1.3 Update trusted applications ...... 54 9.2 Mockups ...... 56 9.2.1 Mockup Login de Usuario ...... 56 9.2.2 Mockup Perfil de Usuario ...... 57 9.2.3 Mockup Editar Perfil de Usuario ...... 57 9.2.4 Mockup Publicar Post ...... 58 9.2.5 Mockup Gestionar Amigos ...... 58
v
1 INTRODUCCIÓN
Uno de los principales descubrimientos de la historia sin duda alguna es la WWW (World Wide Web) y el desarrollo de aplicaciones web, que involucra a absolutamente todas las áreas desde lo personal, profesional, educación, entretenimiento, entre otros, que han dado paso al auge de la información digital. Las aplicaciones como redes sociales, comercio electrónico, sistemas financieros son ahora las encargadas de atender la mayoría de necesidades de la población, lo que ha llevado a un mercado demandante de datos y sistemas de información cada vez más sofisticados, escalables y accesibles, que manejan nuestra información personal a su conveniencia provecho, poniendo en riesgo nuestra privacidad. En marzo de 2019, en el 30º cumpleaños de la World Wide Web, el creador de la web Tim Berners- Lee presentó una reflexión clave acerca de cómo construir una web que sirva al toda la humanidad y no solo a un pequeño porcentaje sin infringir los derechos humanos. Tim Berners- Lee menciona que el diseño de plataformas web que prioricen la privacidad, diversidad, seguridad es fundamental para construir aplicaciones y servicios confiables y beneficiosos [2]. En este sentido, actualmente existe la necesidad de que las personas puedan tener un acceso total y transparente de su propia información con el fin de ser ellos los únicos dueños, debido a ello la Web Semántica (y tecnologías/proyectos similares) tiene un gran potencial para ser una solución definitiva. 1.1 JUSTIFICACIÓN DEL PROYECTO Hoy en día se nos presentan ante el uso de plataformas web una serie de términos y condiciones extremadamente largos que nosotros como usuarios, sin abrir el contenido de estos y leerlos, procedemos con un solo clic a “aceptar y continuar”. En ocasiones las aplicaciones almacenan nuestra información personal y posteriormente son las principales fuentes de información para comercialización de datos, mismo que se benefician mediante anuncios personalizados según nuestras necesidades. Como usuarios de la internet esta es una práctica muy común e irrelevante “aceptar y continuar”, porque la mayoría desconocen el uso específico que pueden llegar a tener sus datos. Por el contrario, se sentirán cómodos al compartir información en sus redes sociales y otras aplicaciones web que se benefician considerablemente a costa de la información proporcionada. Dado este enfoque surgió el proyecto SOLID [1] de la mano de Inrupt [3], fundada por el mismo Tim Berners-Lee que, dado el modelo conocido en el que el usuario otorga información a compañías que dominan la economía digital mediante el almacenamiento centralizado, el control y el acceso total a nuestros datos personales, revoluciona a un modelo en el que el usuario puede
1
elegir dónde almacenar sus datos y qué aplicaciones podrán acceder a ellos, con visión a descentralizar la web mediante aplicaciones independientes de los datos. La principal motivación de este proyecto es adentrarnos en conocer y experimentar la creación de una aplicación web que funcione a modo de red social y que permita interactuar con los datos descentralizados, alojados en los servidores SOLID que se encuentran distribuidos en la web (SOLID IDPs [4]), mediante tecnologías como Linked Data [5] y la Web Semántica [6], que nos permita ver el potencial de este nuevo ecosistema para data y aplicaciones web. 1.2 OBJETIVOS 1.2.1 OBJETIVO PRINCIPAL Nuestra principal meta es poder conocer y aprender el funcionamiento de SOLID (Social Linked Data) y todo el ecosistema que proporciona con el fin de poder construir nuestra propia red social descentralizada, partiendo de ello es necesario definir que es SOLID, tomando la definición de su propia web [7] nos dice que SOLID es “es un conjunto de convenciones y herramientas para construir aplicaciones sociales descentralizadas basadas en principios de datos enlazados (Linked Data). SOLID es modular y extensible y se basa en la mayor medida posible en los estándares y protocolos W3C existentes”. Estos conocimientos abarcan desde el entendimiento de la filosofía y el objetivo de SOLID, hasta las tecnologías que se están usando para llevarlo a cabo. Para ello, se plantea la creación de una red social descentralizada. 1.2.2 OBJETIVOS ESPECÍFICOS • Adquirir conocimientos sobre el ecosistema tecnológico de SOLID. A grandes rasgos, se incluyen las tecnologías de la Web Semántica [6], el uso de PODS, y las SPA (Single-Page Applications) [8]. • Desarrollar una aplicación web mediante el ecosistema SOLID, poniendo en práctica las tecnologías del ecosistema. • Dado que SOLID se centra en la privacidad de los datos, entender y describir como la arquitectura SOLID proporciona los métodos necesarios para preservarla. Diseñar una aplicación web descentralizada, mediante la investigación y uso de tecnologías web actuales como Linked Data y Web Semántica para el desarrollo de una red social con esta nueva filosofía de desarrollo web, que tendrá impactos que favorezcan la investigación y nuevos desarrollos de aplicaciones web semánticas en distintas líneas de negocio. 1.3 SITUACIÓN ACTUAL Actualmente hay un gran equipo de organizaciones públicas, privadas y desarrolladores independientes que están impulsando la nueva Web Semántica o Web 3.0, con profesionales
2
especializados en algunas tecnologías propias para Linked Data como RDF, SPARQL, OWL mismas que serán tratadas en las siguientes secciones, permitiendo el fácil acceso al uso y aprendizaje de las mismas, tal como: 1.3.1 INSTITUTO DE TECNOLOGÍAS DE MASSACHUSETS (MIT) El MIT [9], lugar en el que nace el proyecto SOLID, cuenta con un grupo de investigadores y desarrolladores que forman parte del Computer Science & Artificial Intelligence Lab (MIT CSAIL) y que actualmente están trabajando en los siguientes proyectos: • SolidVC pensada como una plataforma descentralizada para credenciales basándose en la especificación “Modelo de Datos de Credenciales Verificables” [3] de la W3C. Este modelo proporciona un mecanismo para credenciales criptográficamente seguras, privadas y verificables por máquinas en la web. • Privacy-Preserving Data Aggregation proyecto que expone un método viable para la agregación de datos y preservar la privacidad en una arquitectura descentralizada. • Investigación para gestión descentralizada de datos de salud y estado físico, con el aumento de dispositivos móviles aptos para monitoreos personalizados como smartwatch de distintas empresas como Google, Apple almacenan datos en formatos diferentes, esta investigación propone un formato estándar de gestión y almacenamiento descentralizado. 1.3.2 INRUPT INC. Inrupt Inc. [10] se funda en 2018 por Tim Berners-Lee cuya misión es “proporcionar energía comercial y un ecosistema para ayudar a proteger la integridad y calidad de la nueva red creada en SOLID.” [11]. Inrupt Inc. ha diseñado algunas aplicaciones y herramientas de código abierto que brindan facilidad para los desarrolladores de crear aplicaciones con este nuevo enfoque, con esto están impulsando esta nueva tecnología, siendo su principal producto SOLID. Entre los productos que ofrece están Servidores SOLID, herramientas de desarrollo e interfaces de Usuario para los PODS [12]. 1.3.3 SOLID COMMUNITY FORUM SOLID Community Forum [11] se trata de una web enfocada a la comunidad donde se pueden resolver preguntas sobre temas específicos como funcionalidades de SOLID o preguntas técnicas que involucren desarrollo de una aplicación. Más allá de ser un espacio abierto a la comunidad para resolver preguntas y exponer puntos de vista, podemos ver en la Ilustración 1 que SOLID Community Forum ha permitido crear, probar, y validar proyectos que sirven como atractivo y punto de inicio para que nuevos desarrolladores se involucren en SOLID. 3
Ilustración 1: Muestra de las intervenciones de la comunidad en SOLID Community Forum [13]
4
2 ASPECTOS TEÓRICOS Y ESTADO DEL ARTE
Con el propósito de dar a conocer cuáles fueron las bases teóricas y conocimientos técnicos, en el presente capítulo se detallan todos los conceptos, tecnologías e investigaciones realizadas para el desarrollo del proyecto. 2.1 WEB 3.0 Y WEB SEMÁNTICA La Web ha evolucionado considerablemente, desde su invención en los años noventa hasta nuestra actualidad, los usos de la web se han expandido para crear todo tipo de contenidos: foros, blogs, etc., que han enriquecido el acceso a la información. Pero también hay que mencionar las desventajas de privacidad y piratería; es por ello necesario que la evolución continúe (web 3.0) hacia un web más abierta y accesible para la persona común. La W3C define a las Web 3.0 como: “Una Web extendida, dotada de mayor significado en la que cualquier usuario en Internet podrá encontrar respuestas a sus preguntas de formas más rápida y sencilla gracias a una información mejor definida sobre lo que busca” [14]. En definitiva, una web inteligente, con información estructurada, de calidad, y sobre todo de fácil acceso. La Web Semántica, a diferencia de la Web del hipertexto que está construida mediante enlaces a documentos en HTML, está comprendida con tripletas RDF1 que describen el contenido, la relación y significado de los datos sin ambigüedad; de tal manera que se cree un grafo, como muestra la Ilustración 2, que conecte datos entre sí mediante Linked Data, facilitando la interpretación y procesamiento de la información.
1 RDF es un framework para describir recursos en la web del que hablaremos en la sección Tabla 1: Tecnologías y Estándares W3C para la web Semántica RDF (Resource Description Framework) 5
Ilustración 2: Diagrama Linked Open Data Cloud, 2020, esta imagen describe el conjunto de datos publicados en formato de datos vinculados. Contiene 1260 conjuntos de datos y 16187 enlaces, mayo 2020, The Linked Open Data Cloud [15] 2.2 LINKED DATA Datos enlazados o vinculados es un término propuesto por Tim Berners-Lee en 2009 para definir a la publicación e interconexión de datos estructurados en la Web mediante tecnologías como HTTP, URIs y RDF que, en lugar de conectar páginas web como está funcionando la Web hoy día, lo que busca es conectar información y que esta pueda ser leída por máquinas desde diferentes fuentes. Linked Data hace referencia a un conjunto de buenas prácticas con estándares W3C con los siguientes principios: 1. Usar URIs, como identificadores únicos y globales en la web para nombrar cosas. 2. Usa HTTP como mecanismo de recuperación del recurso identificado con la URI, que nos permite conocer y acceder a su significado y descripción mediante otras URIs, que sean interpretables por humanos y máquinas. 3. Proveer información útil acerca de cada URI. 4. Crear links entre URIs, disponibles en tripletas RDF. 2.3 TECNOLOGÍAS WEB SEMÁNTICAS Son tecnologías que permiten interactuar con datos estructurados en un formato común. La arquitectura de la web semántica se muestra en la siguiente Ilustración 3, en el cual se detalla la jerarquía de estándares recomendados por W3C:
6
Ilustración 3: Arquitectura de la web semántica
Estas tecnologías se encuentran divididas en tres tipos como se muestra en la Tabla 1:
Tecnologías Descripción Estándares Web de Tecnologías Unicode permite expresar la información en cualquier idioma. Hipertexto conocidas como IRI (Internationalized Resource Identifier) [16] corresponde a hipertexto, las identificador único global, formado por la URL (Uniform Resource cuales son la base Locator) más la URN (Uniform Resource Name). del XML (Extensible Markup Language) y Turtle (Terse RDF Triple funcionamiento Language) [17] permiten crear documentos con datos estructurados. de la web. Web Tecnologías que RDF (Resource Description Framework) [18] que proporciona Estandarizadas han sido semántica en tripletas para modelos de datos. estandarizadas RDF SCHEMA [19] para descripción de objetos y propiedades con por W3C y que jerarquías. permiten la OWL (Web Ontology Language) [20] para representar el creación de conocimiento/ontologías sobre objetos y relaciones basado en lógica aplicaciones web computacional y que este sea explotado por máquinas. semánticas
SPARQL (Query Language for RDF) [21] se trata de un lenguaje de consultas para RDF muy similar a SQL, que permite obtener información de ontologías.
7
Web sin Las capas SWRL (Semantic Web Rule Language) [22] se refiere a un lenguaje estandarizar superiores que propuesto para expresar reglas y lógica en la web semántica
aún no están RIF (Rule Interchange Format) [23], tiene el objetivo de definir un estandarizadas estándar para el intercambio de reglas entre sistemas. Capa de Confianza o de verdad en donde se verificará que las premisas vengan de fuentes confiables. Interfaces de Usuario y Aplicaciones para la web semántica.
Tabla 1: Tecnologías y Estándares W3C para la web Semántica 2.3.1 RDF (RESOURCE DESCRIPTION FRAMEWORK) RFD es una tecnología que nos permite describir la información para que las máquinas procesen e interpreten la información, proveyendo un significado a la estructura de los documentos. De hecho, RDF y otros estándares centrales de la Web Semántica como RDFS [24] y OWL tienen sus propios vocabularios, que generalmente se combinan entre sí y se amplían utilizando otros vocabularios para describir objetos y sus propiedades. Sin embargo, RDF es mucho más que un simple vocabulario, ya que es un lenguaje de modelado de datos semánticos con todas las funciones. El modelo de datos RDF se basa en declaraciones para describir y presentar recursos, especialmente recursos web, en forma de expresiones sujeto-predicado-objeto (valor de propiedad de recurso) llamadas triples RDF (o tripletas). El predicado (propiedad) describe la relación entre el sujeto y el objeto. Estas estructuras llamadas “tripletas” se basan en expresiones semejantes a una oración compuesta por “sujeto”, “predicado” y “objeto” cada uno de estos elementos expresados por una URI. Por ejemplo, en la siguiente Ilustración 4 se puede apreciar que el recurso Persona corresponde al sujeto, URI de organización es el predicado indicando “pertenece a” y el objeto La Salle Ramon Llul.
8
Ilustración 4: Ejemplo de tripleta RDF
Ahora bien, expresado en tripleta RDF se tendría lo siguiente:
Para la representación de estas tripletas se tiene distintos métodos que se describen a continuación. 2.3.2 RDFS (RDF SCHEMA) Es una extensión de RDF que proporciona un vocabulario de modelado de datos para datos RDF, es decir con RDF Schema y RDF podemos comenzar a hacer descripciones más detalladas. Por ejemplo, en la Ilustración 6 se puede ver que tenemos los siguientes objetos “Teacher” y “Person” y para describir de manera semántica estándar que “Teacher” es también “Person” se define con RDFS. PREFIX rdfs:
Entonces, RDF tiene términos para crear instancias, RDFS tiene términos para crear clases. 2.3.3 RDF/XML La serialización RDF/XML es procesable para las máquinas y mediante URIs podemos enlazar e identificar objetos en la Web. Su sintaxis está basada en XML (eXtensible Markup Language) que es un lenguaje para describir estructuras de datos orientadas a jerarquías estandarizado en 1998 por W3C; del grafo de la Ilustración 4 su representación en XML correspondería a:
9
Ilustración 7: Ejemplo de serialización RDF/XML 2.3.4 TURTLE (TERSE RDF TRIPLE LANGUAJE) Es otro tipo de serialización para representar tripletas RDF textualmente, dado el ejemplo Ilustración 4, se tendría como un archivo con extensión. ttl: @prefix : <#>. @prefix solid:
:me #sujeto a schem:Person, n0:Person; n0:organization ; #predicados n0:role "ESTUDIANTE"; c:name La Salle Ramón LLul. #objeto Ilustración 8: Ejemplo de serialización RDF con Turtle
Turtle es incluso más fácil de leer y editar que XML, la sintaxis está definida por: • @prefix nombres con prefijo • Lista de predicados separados por “ ; ” • Lista de objetos separados por “ , ” • Triples (sujeto, predicado y objeto) terminados por “ . ” después de cada triple • Escribir comentarios con “ # ” 2.3.5 SPARQL (PROTOCOL AND RDF QUERY LANGUAGE) Provee un lenguaje de consulta, inserción y actualización de grafos RDF. Normalizado por la Data Access Wolking Group DAWG [25] y constituido como recomendación oficial de W3C. Entre las características principales se destacan:
10
• Provee diferentes formatos de salida • Permite la creación y conversión de tipos de datos • Modificadores de consulta como “order by”, “distinct”, “limit” entre otros • Funciones condicionales y de comprobaciones tipo de datos Se puede ver un ejemplo en la Ilustración 9: Datos:
Query: SELECT ?title WHERE {
Resultado: title: "SPARQL Tutorial" Ilustración 9: Ejemplo query con SPARQL. 2.3.6 ONTOLOGÍAS Y VOCABULARIOS Una ontología (dentro del lenguaje computacional) se refiere a la conceptualización de un modelo de dato o de una pieza del mundo real, como una persona, un evento, un calendario, etc., para poder realizar el modelado y este pueda entenderlo la máquina, se definen los siguientes componentes: • Clases • Atributos • Relaciones • Funciones • Restricciones • Reglas • Axiomas • Eventos Las ontologías son descripciones formales de un área de conocimiento representadas mediante redes de objetos. En las ontologías los sustantivos están representados por clases de objetos y los verbos son las relaciones entre ellos. Por ello, de forma resumida, podemos concluir que las ontologías nos permiten conocer el sentido de las palabras (dentro del contexto que se emplea) y relaciones entre los términos, permitiendo con ello que la máquina (ordenador) los entienda.
11
Por ejemplo, en el presente proyecto usamos la ontología Friend of a Friend – FOAF [26] y VCARD [27] que son ontologías para describir personas [28]. Un vocabulario, sin embargo, está descrito por una URI, por ejemplo, la ontología FOAF mediante la URI http://xmlns.com/foaf/0.1/ y para hacer referencia a los objetos y relaciones entre ellos, se adjunta la propiedad por ejemplo “name” al vocabulario, se tendría la siguiente URI http://xmlns.com/foaf/0.1/name. W3C tiene la siguiente postura al respecto: “No existe una división clara entre lo que se conoce como "vocabularios" y "ontologías". La tendencia es usar la palabra "ontología" para una colección de términos más compleja y posiblemente bastante formal, mientras que "vocabulario" se usa cuando un formalismo tan estricto no se usa necesariamente o solo en un sentido muy vago. Los vocabularios son los bloques de construcción básicos para las técnicas de inferencia en la Web Semántica.” [29]. En la Tabla 2 se muestran los vocabularios más comunes:
Vocabulario Abreviación Espacio de Nombres Uso
Person class from schema:Person http://schema.org/Person Obtener el nombre, familia, schema.org género, afiliación, nacionalidad,
trabajo, etc
Friend of Friend Foaf http://xmlns.com/foaf/0.1/ Persona, nombre, genero, página principal
Contact contact http://www.w3.org/2000/10/ Lugar, título personal, etc swap/pim/contact
Vcard vcard http://www.w3.org/2001/ Tarjeta electrónica para negocios. vcard-rdf/3.0#
Bio bio http://vocab.org/bio/0.1/ Información Biográfica.
Relationship relationship http://vocab.org/ Relaciones entre personas relationship/ (friendOf, parentOf, spouseOf, etc)
Tabla 2: Vocabularios más comunes. Fuente: Vocabularios y Ontologías extraído de [30].
12
2.3.7 FOAF (FRIEND OF A FRIEND) FOAF es una ontología (o vocabulario) que describe a personas, sus actividades y sus relaciones con otros objetos y personas (ver Ilustración 10).
Ilustración 10: Términos FOAF en orden alfabético, por categoría/tipo/clase y propiedades [29]
Para expresar se usa sintaxis RDF y OWL (Web Ontology Language) que veremos a continuación en la sección 2.3.10. Actualmente se encuentra en su versión 0.99 siendo la más estable desde su nacimiento en el año 2000. Como vemos en la siguiente Ilustración 11, un ejemplo de perfil con FOAF escrito en formato Turtle, en la que describe datos personales como recursos web. @prefix : <#>. @prefix solid:
13
Ilustración 12: Grafo para la ontología VCARD, extraído de Visual Data Web [31]
La W3C establece la representación de VCARD en RDF permitiendo así que la descripción de personas y organizaciones sea común, como se muestra en la Ilustración 13.
14
Ilustración 15: Una parte de la ontología OWL (https://www.w3.org/2002/07/owl)
Como se puede ver, el vocabulario OWL amplía el concepto de rdf:Property al crear nuevos tipos de propiedades que son menos abstractas y pueden proporcionar descripciones más precisas de los recursos. Ahora bien, para describir aplicaciones orientadas a objetos, se necesita tipos, clases, atributos, instancias, etc.; con RDF podemos describir solo objetos y con RDF Schema describir clases y herencia, pero para definir restricciones se necesita OWL.
15
En definitiva, OWL es un vocabulario construido con RDF y RDF Schema que proporcionan nuevos términos para crear descripciones más detalladas de los recursos. 2.4 SOLID (SOCIAL LINKED DATA) SOLID es un proyecto de código abierto desarrollado en el MIT, pensado para descentralizar la web e ir minimizando el poder de gigantes tecnológicos que cuánto más datos tengan a su disposición, más potentes serán los algoritmos aplicados a procesos de producción, de logística y del marketing dirigido y además que han sido actores de múltiples escándalos de violación de privacidad a sus usuarios como “Facebook ha permitido a más de 150 empresas, como Netflix, Spotify, el Banco Real de Canadá o Amazon, acceder a los datos personales de los usuarios de la red social” [32]. El principio fundamental de SOLID es “empoderamiento personal a través de los datos” mediante la creación de PODS. Un POD es un espacio de almacenamiento personal del usuario en SOLID, estos pueden alojarse donde el usuario prefiera (SOLID Identity Providers [4]), incluso puede tener su propio servidor SOLID en la web. En el marco de SOLID, aplicaciones descentralizadas pueden solicitar datos a los PODS. Como respuesta a una solicitud de datos, SOLID autenticará y dará acceso a la aplicación a solo ciertos datos del POD. A continuación, en el apartado 2.4.1 describimos el diseño de los diferentes componentes de SOLID, cabe recalcar que el ecosistema de SOLID aún se encuentra en proceso de investigación y desarrollo (ver Ilustración 16) por lo que la siguiente sección se describe básicamente las especificaciones con las que se ha tenido interacción en el proyecto.
Ilustración 16: El ecosistema SOLID, Borrador al 3 de agosto de 2020 [32].
16
2.4.1 ARQUITECTURA DE SOLID Su arquitectura se basa en el paradigma distribuido Spoke Hub que se define como un nodo central y radios conectados, en la que el servidor SOLID corresponde al nodo central y los PODS a los radios distribuidos permitiendo a los usuarios de la web decidir donde alojarse y a que aplicaciones compartir su información. Los servidores SOLID son independientes a las aplicaciones por lo que al desarrollar una aplicación no se requiere modificar nada en los servidores este diseño es ideal para mantener una gestión de datos estándar. 2.4.1.1 GESTIÓN DE IDENTIDAD
SOLID usa WebId para identificar a usuarios de forma única.
Flujo de trabajo:
1. El usuario “Alice” quiere registrase 2. SOLID verificará si existe de cuenta https://alice.databox.me/ mediante HTTP GET https://alice.databox.me/ 3. Si la respuesta es 404, SOLID pedirá que registre esta cuenta. 4. Para creación de la cuenta se enviará una solicitud HTTP POST con la URL https://alice.databox.me/. Esta solicitud POST se enviará con los siguientes datos:
• Content-Type : application/x-www-form-urlencoded • Email: utilizado para fines de recuperación • Username: para especificar el nombre de la cuenta
5. Finalmente, el usuario podrá obtener su certificado asociado a su WEBID y su perfil https://alice.databox.me/.
Ilustración 17: Representación gráfica de certificados asociados a un WebId [33]
17
2.4.1.2 MODELO DE DATOS El modelo de datos es RDF, por lo cual los datos se pueden trasmitir en sintaxis como Turtle, JSON-LD o RDFa, cuando SOLID crea nuevos recursos la sintaxis predeterminada es Turtle, pero esto no quita la compatibilidad que tiene con las otras serializaciones de RDF. 2.4.1.3 AUTENTICACIÓN SOLID permite la identificación desde diferentes aplicaciones en la web a un mismo POD las siguientes convenciones para autenticación y manejo de interoperabilidad: 2.4.1.3.1 WEBID-TLS Permite autenticación del usuario simplemente eligiendo uno de los certificados del navegador estos certificados pueden ser creados por cualquier sitio web para cualquier propósito. Un usuario puede tener varios certificados de cliente, vinculados a uno o varios WebID. 2.4.1.3.2 WEBID-OIDC Este tipo de autenticación está basada en el protocolo OpenID Connect y este a su vez se basa en OAuth2, que funciona de la siguiente manera a partir de una solicitud inicial, se presenta un pop up de selección del proveedor del WebId, luego el usuario es redirigido al inicio de sesión de su proveedor en el que realiza la autenticación (IDPs de SOLID en [4]) y finalmente el usuario será dirigido hacia el recurso original. En este proyecto empleamos la autenticación mediante WebID-OIDC, puesto que para el login se debe seleccionar su IDP (SOLID Identity Provider) de POD para que este sea redirigido a su proveedor para autenticación. 2.4.1.4 CONTROL DE ACCESO: WEB ACCESS CONTROL – WAC Es un sistema para control de accesos de dominio cruzado mediante un recurso ACL (Access Control List) que permite que se puedan dar accesos a recursos alojados en otros sitios mediante URI. En estos recursos, dado un ejemplo en la Ilustración 18 se deben especificar los diferentes modos de acceso como para adjuntar, leer, escribir y controlar; hay que tomar en cuenta que los permisos también pueden ser heredados del contenedor padre que puede ser un directorio, esto para evitar un ACL por cada recurso y gestionar actualizaciones accesos desde el contenedor padre.
18
Ilustración 18: Ejemplo de recurso ACL, en el que se describe el acceso de lectura, escritura y control hacia el recurso file1 para el agente Alice representado por su respectivo WebId.
2.4.1.5 RECURSOS DE LECTURA Y ESCRITURA SOLID ofrece una serie de herramientas para desarrollar aplicaciones que cumplan con estándares del W3C entre ellas formatos de datos, bibliotecas y vocabularios que permitan autenticación, inicio de sesión, listas de permisos, administración de contactos, mensajería, suscripciones, comentarios, discusiones, y otros. EL diseño se basa en especificaciones de protocolo HTTP, servicios REST y HTML. SOLID amplía la especificación de LDP (Linked Data Platform) para proporcionar una API REST simple para operaciones CRUD en recursos y contenedores en la siguiente Tabla 3 unos ejemplos:
Path Método Descripción /{username}/ GET Lista todos los documentos en el contenedor raíz. POST Cree un nuevo documento debajo del contenedor raíz. PUT Actualice la descripción y / o lista de archivos del contenedor raíz. PATCH Actualice la descripción y / o lista de archivos del contenedor raíz. DELETE No permitido. /{username}/{{document}/}* GET Recupera el documento. POST Descubierto a partir de las posibilidades de recursos. PUT Actualice el documento. PATCH Actualización parcial del documento si se admite PATCH.
19
DELETE Elimina el documento. /*/* OPTIONS Descubra las operaciones permitidas sobre un recurso HEAD Recuperar solo metainformación sobre un recurso
Tabla 3: Solicitudes HTTP ejemplo de SOLID
SOLID se basa tanto como sea posible en los estándares y protocolos del W3C existentes. Para más información al respecto de la arquitectura y especificaciones consultar “Solid-spec: la arquitectura y las especificaciones Solid” [34] es el repositorio oficial de SOLID y su comunidad. 2.4.1.6 SISTEMA DE ARCHIVOS: LDPC (LINKED DATA PLATFORM CONTAINERS) Los recursos se almacenan directamente en el sistema de archivos esto permite a las personas leer y escribir datos tanto usando aplicaciones de escritorio como basadas en la Web, y también compartir la misma unidad de disco entre diferentes servidores. LDP define la creación de un tipo especial de recurso llamado contenedor (LDPC), que es capaz de responder a solicitudes para crear nuevos recursos, además de los mecanismos generales que define HTTP (POST, GET, PUT, DELETE). Luego de registrarse en SOLID se crean los contenedores LDP principales para el usuario (ver Ilustración 19) los cuales tienen sus recursos ACL respectivos ver ejemplo Ilustración 20. Durante la creación de un recurso (archivos HTML, imágenes, directorios o archivos RDF) se agrega a su contenedor y se crea un vínculo de contención entre el contenedor y la nueva entrada.
Ilustración 19: Contenedores LDP generados por SOLID [35]
20
Ilustración 20: Recurso ACL del directorio Public
Estos contenedores son los básicos para SOLID, es decir, se crean por defecto con la lógica ACL para cada contenedor, estos permisos pueden ser actualizador por el usuario si así lo desea.
21
3 EJECUCIÓN DEL PROYECTO
En esta sección se detalla el diseño y desarrollo del proyecto, iniciando con la descripción del entorno de trabajo, posteriormente se explicará el proceso de ejecución de un servidor SOLID con Docker y para finalizar se detallará la creación de la red social descentralizada. 3.1 ENTORNO DE DESARROLLO Para el desarrollo del presente proyecto se utilizaron las siguientes tecnologías descritas en la Tabla 4:
Item Software Descripción Sistema Operativo Ubuntu 20.04 LTS Es una de las distribuciones de Linux más famosas, en su versión 20.04 LTS desarrollada por la empresa Canonical [36], entre los beneficios de usar esta distribución tenemos que posee una gran cantidad de paquetes que
facilitan la compatibilidad entre hardware y software. IDE (Entorno de PHP Storm 2020.2.1 Es un IDE multiplataforma que posee plugins para Desarrollo mejorar la experiencia de usuario, proporciona Integrado) autocompletado de código, herramientas de desarrollo integradas como GitHub, Docker entre otras. Soporta tecnologías Front-End como HTML5, CSS, Sass, TypeScript, Javascript entre etc., con disponibilidad de refactorizaciones, depuración automática [36]. Servidor de Node Js 12.18.3 Es un entorno de ejecución para Javascript de código Desarrollo abierto, proporciona una biblioteca que incluye varios módulos de JavaScript que simplifica en gran medida el desarrollo de aplicaciones [35]. Entorno de Docker 19.03.12 Es una plataforma de software de código abierto que Ejecución de permite crear contenedores, mismos que incluyen todas Contenedores las características (librerías, código fuente y dependencias) necesarias para que el software se ejecute, de manera similar a una máquina virtualizada (elimina la necesidad de tener hardware). Posee grandes ventajas como consistencia en los entornos de desarrollo, automatización en el despliegue de aplicaciones, contenedores livianos y modulares para facilitar la transferencia entre equipos de desarrollo.
22
Sistema de Control GitHub Es un sistema de control de versiones adquirido por de Versiones Microsoft en 2018, que permite la creación de repositorios y la colaboración entre varios desarrolladores que facilita el trabajo en equipo.
Tabla 4: Entorno de desarrollo del proyecto. 3.2 SERVIDOR SOLID CON DOCKER 3.2.1 PRERREQUISITOS Para levantar un contenedor con SOLID Server se requiere haber instalado Docker Engine y Docker Compose. Para ello en la siguiente referencia se tiene una guía de instalación para cada sistema operativo [35]. Para verificar si contamos con este requisito nos dirigimos a un terminal y, como muestra la Ilustración 21, ejecutamos los siguientes comandos verificando la instalación y versión. > docker-compose -v docker-compose version 1.26.2, build eefe0d31 > docker -v Docker version 19.03.12, build 48a66213fe Ilustración 21: Versión de Docker y Docker-compose
Es necesario descargar o clonarel repositorio de GitHub (ver Ilustración 22) disponible desde la siguiente dirección: - https://github.com/MONISANCHEZ10/SOLID.git > git clone https://github.com/MONISANCHEZ10/SOLID.git Cloning into 'SOLID'... remote: Enumerating objects: 7828, done. remote: Counting objects: 100% (7828/7828), done. remote: Compressing objects: 100% (5572/5572), done. remote: Total 7828 (delta 1452), reused 7639 (delta 1304), pack-reused 0 Receiving objects: 100% (7828/7828), 6.14 MiB | 4.15 MiB/s, done. Resolving deltas: 100% (1452/1452), done.
Ilustración 22: Clonar repositorio SOLID Server con Docker 3.2.2 ESTRUCTURA DEL REPOSITORIO Se ha creado un repositorio en GitHub con todo los archivos y pasos necesarios para levantar un Servidor SOLID con Docker mismo que puede ser descargado en la referencia [35], el cual tiene la siguiente jerarquía de directorios ver Ilustración 23.
23
. ├── App │ ├── Certificates │ │ ├── fullchain.pem │ │ └── privkey.pem ├── config.json ├── docker-compose.yml ├── Dockerfile │ └── Dockerfile ├── HELPER.md └── README.md
Ilustración 23: Estructura de archivos de repositorio creado para SOLID Server con Docker
En la Tabla 5 se tiene mayor detalle de cada uno de los ficheros del repositorio.
Tipo Nombre Detalle Directorio App Directorio de trabajo del contenedor, aquí se almacenarán todos los directorios y archivos de SOLID Server.
Certificado fullchain.pem Llave pública privkey.pem Llave privada Archivo de config.json Archivo de configuración para instalación de SOLID Server configuración Archivo YALM docker-compose.yml Docker-compose principal Dockerfile Imagen Centos 8 y SOLID Server Archivo de texto HELPER.md Archivo de ayuda con comandos principales y generación de llaves SSL. README.md Estructura e inicio del proyecto.
Tabla 5: Detalle de archivos y directorios del repositorio SOLID Server con Docker 3.2.3 CONFIGURACIÓN DE SOLID SERVER CON DOCKER El archivo config.json tiene la configuración necesaria para la instalación de SOLID Server, como se puede ver en la Ilustración 24, estamos usando la configuración predeterminada pero obviamente esto podría cambiarse, entre los parámetros que se han modificado tenemos: la ubicación y nombres de las llaves SSL (se pueden usar las de prueba generadas en este
24
repositorio2), el parámetro multiuser como TRUE que permitirá tener un servidor multiusuario es decir que permitirá crear más de un POD.
Ilustración 24: Configuración predeterminada archive config.json de SOLID
El archivo Dockerfile ver Ilustración 25, contiene las instrucciones necesarias para crear una imagen de CentOS 8, con todas las configuraciones necesarias como el directorio de trabajo, puerto, instalaciones base (node js, updates para la instalación de SOLID Server (línea 14) y levantamiento del servidor (línea 19).
2 Se utilizan certificados autofirmados generados automáticamente y no adecuado para uso en producción. Para un servidor de producción, tendrá que crear algunos certificados reales y configurar variables de entorno, como SOLID_SERVER_URI, SOLID_SSL_KEY y SOLID_SSL_CERT. 25
Ilustración 25: Dockerfile de SOLID Server
El fichero docker-compose.yml (Ilustración 26), inicia y ejecuta como servicio la imagen del Dockerfile creada; Docker-compose levantará un contenedor exponiendo SOLID Server en el puerto 8443 y manteniendo la persistencia de los datos en el directorio /App.
Ilustración 26: archivo docker-compose.yml 3.2.4 INICIAR SOLID SERVER CON DOCKER Desde el directorio principal del proyecto ejecutar el siguiente comando “docker-compose up” como indica la Ilustración 27.
26
……\SOLID> docker-compose up Creating network "solid_default" with the default driver Building solid-server Step 1/15 : FROM amd64/centos:latest latest: Pulling from amd64/centos 3c72a8ed6814: Pull complete Digest: sha256:fc4a234b91cc4b542bac8a6ad23b2ddcee60ae68fc4dbd4a52efb5f1b0baad71 Status: Downloaded newer image for amd64/centos:latest ---> Running in 996b835cadd5 CentOS-8 - AppStream 2.9 MB/s | 5.8 MB 00:01 CentOS-8 - Base 1.3 MB/s | 2.2 MB 00:01 CentOS-8 - Extras 15 kB/s | 7.3 kB 00:00 Dependencies resolved. ======Package Arch Version Repository Size ======Installing: dnf-plugins-core noarch 4.0.12-3.el8 BaseOS 64 k ... Ilustración 27: Levantamiento del Contenedor de SOLID Server
Una vez se inicializa el contenedor obtendremos el resultado de Ilustración 28. ... Creating solid_solid-server_1 ... done Attaching to solid_solid-server_1 solid-server_1 | 2020-09-03T04:33:32.602Z solid:settings Server URI: https://localhost:8443 solid-server_1 | 2020-09-03T04:33:32.604Z solid:settings Auth method: oidc solid-server_1 | 2020-09-03T04:33:32.604Z solid:settings Strict origins: true solid-server_1 | 2020-09-03T04:33:32.605Z solid:settings Allowed origins: solid-server_1 | 2020-09-03T04:33:32.605Z solid:settings Db path: ./.db solid-server_1 | 2020-09-03T04:33:32.605Z solid:settings Config path: ./config solid-server_1 | 2020-09-03T04:33:32.605Z solid:settings Suffix Acl: undefined solid-server_1 | 2020-09-03T04:33:32.605Z solid:settings Suffix Meta: undefined solid-server_1 | 2020-09-03T04:33:32.605Z solid:settings Allow WebID authentication: true solid-server_1 | 2020-09-03T04:33:32.605Z solid:settings Live-updates: true solid-server_1 | 2020-09-03T04:33:35.609Z solid:authentication Local RP client initialized ... Ilustración 28: Inicialización del contenedor de SOLID Server exitosa
Ahora en el navegador nos dirigimos a la dirección https://localhost:8443/ como vemos en la Ilustración 29, podremos interactuar con el servidor local de SOLID en el que crearemos PODS para interactuar con la aplicación descentralizada que se detalla en la siguiente sección 3.3.
27
Ilustración 29: Inicio de SOLID Server versión 5.2.4 con Docker desde el Navegador. 3.3 RED SOCIAL DESCENTRALIZADA – RSD TODAY 3.3.1 CASOS DE USO La red social desarrollada cuenta con los siguientes casos de uso Tabla 6:
Caso de Uso Descripción
Login de usuario Iniciar sesión en la aplicación con el proveedor de PODS SOLID descentralizado elegido por el usuario (SOLID Server local, SOLID Community o Inrupt).
Mostrar perfil Cargar la información del perfil del usuario.
Actualizar perfil Permitirá editar la información del usuario, datos personales y foto. Galería de fotos Añadir fotos, estas permitirán adjuntar pie de foto opcional.
Privacidad de publicaciones Únicamente se manejarán permisos de visualización ente público, mis amigos y solo yo. Gestionar amigos Debe permitir agregar amigos mediante WebId a usuarios con perfil público independientemente del proveedor de PODS.
28
Tabla 6: Casos de Uso de la aplicación
Durante la elaboración de los casos de uso se realizó también los mockups con un diseño aproximado de los componentes ver anexo 9.2 Mockups. 3.3.2 ARQUITECTURA Y DISEÑO DE LA SOLUCIÓN RSD TODAY Se desarrolló una SPA (Single Page Application) que es un tipo de aplicación donde tenemos un único punto de entrada (comúnmente llamado index.html), mientras que los datos son consultados y renderizados en la vista cada vez que el usuario los requiera. Se puede observar en la Ilustración 30 el flujo de trabajo de una SPA: 1. El flujo inicia con una entrada del usuario. 2. Con esta entrada se realiza una petición al servidor mediante una URL Request. 3. El servidor procesa la petición y retorna los recursos estáticos. 4. Se muestran los recursos (HTML, CSS) en la interfaz de usuario. 5. Se cargan los componentes de JavaScript y se consultan los datos al servidor. 6. Se renderizan los componentes en la interfaz de usuario. 7. Se muestra la interfaz de usuario completa.
Ilustración 30: Ciclo de una SPA Single Page Application [37].
Se ha optado por utilizar el framework para Javascript React Js [38] que permite tener un patrón de diseño basado en componentes en donde cada funcionalidad es un componente, facilitando así la reutilización y el encapsulamiento de funcionalidades. Los componentes están estructurados de forma jerárquica como se indica en la Ilustración 31 y utilizan dos tipos de datos para representar el HTML: 1. this.props: para acceder a los datos que se reciben de entrada desde el componente padre. 2. this.state: para acceder a los datos de estado que genera el propio componente. 29
Cuando los datos de un componente cambian, el componente se vuelve a renderizar en la vista en función de los datos actualizados.
Ilustración 31: Estructura y flujo de componentes React Js [39].
Los componentes usan JSX, que es una extensión de la sintaxis de JavaScript para describir las etiquetas HTML necesarias para ser visualizados en la interfaz de usuario. Los navegadores no pueden interpretar la sintaxis JSX, para ello se utiliza un transpilador como Babel para convertir el JSX en JavaScript estándar para que pueda ser comprendido (una aplicación puesta en producción se despliega únicamente el código transpilado). Para finalizar esta sección, se resume el diseño de la Red Social desarrollada mediante la Ilustración 32 que corresponde a una arquitectura SPA, con la principal diferencia que los datos en lugar de estar en una Base de Datos central se encuentran descentralizados en la web en los distintos Proveedores de PODS [40].
30
Ilustración 32: Diseño Red Social Descentralizada 3.3.3 DESARROLLO En esta sección se detalla los componentes que conforman a RSD TODAY con una descripción de lo que implicó el desarrollo de la funcionalidad. 3.3.3.1 LOGIN DE USUARIO
Ilustración 33: Interfaz de usuario RSD TODAY – Login
El componente de login de usuario Ilustración 33 permite iniciar sesión con un proveedor de PODS entre las siguientes opciones Ilustración 34:
31
Ilustración 34: Interfaz de usuario RSD TODAY – Login SOLID IDPs
Para la autenticación utiliza la librería solid-auth-client [41], que permite verificar la existencia de una sesión con SOLID IDPs [4], en caso de no existir sesión activa redirecciona al login del proveedor seleccionado (ver apartado 2.4.1.1 sobre gestión de identidad con SOLID). Solid-auth- client almacena tokens de autorización como cookies en el navegador. Finalmente, el usuario será dirigido al inicio de la aplicación Ilustración 35:
Ilustración 35: Interfaz de usuario RSD TODAY – Inicio
32
3.3.3.2 ACTUALIZAR PERFIL
Ilustración 36: Interfaz de usuario RSD TODAY – Editar Perfil de usuario
La actualización del perfil de usuario permite modificar los datos y foto de perfil cómo indica la Ilustración 36, de estos datos ninguno campo es obligatorio por lo que pueden estar vacíos. Para el desarrollo de este componente se trabajó con la librería LDflex [42], que se trata de un lenguaje de domino para consultar datos enlazados en la web, a continuación, un ejemplo Ilustración 37: LDflex: await [https://julianrojas.solid.org/profile/#me].add('foaf:givenName' , 'Julian');
LDflex traduce en query SPARQL:
INSERT DATA {
Ilustración 37: Ejemplo escritura de datos en POD de SOLID con librería LDflex
LDflex utiliza solid-auth-client para garantizar que solo los clientes autorizados puedan leer y escribir datos desde y hacia los PODS.
33
3.3.3.3 MOSTRAR PERFIL
Ilustración 38: Interfaz de usuario RSD TODAY – Perfil de usuario
En este componente muestra los datos públicos del perfil de usuario como el WebId, nombre, email, dirección etc., como se puede ver en la Ilustración 38 estos datos de usuario no son requeridos en el POD ni en la aplicación RSD TODAY. Para esta lectura de datos del usuario también se empleó LDflex como se muestra en la Ilustración 39. import data from "@solid/query-ldflex"; const me = data[https://julianrojas.solid.org/profile/#me]; firstName= `${await me.vcard_fn}`; image = `${await me["vcard:hasPhoto"]}`; company = `${await me["vcard:organization-name"]}`;
Ilustración 39: Ejemplo lectura de datos de un POD de SOLID con librería LDflex
34
3.3.3.4 GALERÍA DE FOTOS
Ilustración 40: Interfaz de usuario RSD TODAY – Galería de fotos
Este componente gestiona carga de fotos a RSD TODAY mediante la creación y actualización de un archivo llamado “social.ttl” en el directorio public del POD (por lo que hereda los permisos de public ver apartado 2.4.1.4 sobre Control de Acceso) como indica Ilustración 41; este archivo “social.ttl” funciona como registro de las fotos publicadas por el usuario, estas se almacenan en el directorio “..public/social/” para ser mostradas posteriormente en RSD TODAY sección Galería Ilustración 40.
35
Ilustración 41: POD SOLID archivo “social.ttl” (registro de fotos públicas)
Para el desarrollo de este componente se utilizó la librería TripleDoc que permite crear, leer y actualizar documentos RDF de SOLID, posee interfaces como TripleDocument [43] para el acceso al contenido de los documentos y TripleSubject [44] que permite manipular su contenido mediante métodos get*, add*, set*y remove*. En la Ilustración 42 se puede ver la función UpdateNote que utiliza los métodos fetchDocument para acceder al contenido del documento social.ttl, removeSubjet para eliminar un registro y save para guarda los cambios realizados. async UpdateNote(){ let noteList = await fetchDocument(../public/social.ttl) if (noteList) { noteList.removeSubject(note.asRef()); let updatedDoc = await noteList.save(); } } Ilustración 42: Ejemplo actualización del archivo social.ttl con librería TripleDoc
36
3.3.3.5 PRIVACIDAD DE PUBLICACIONES
Ilustración 43: Interfaz de usuario RSD TODAY - Publicaciones
El componente de gestión de publicaciones (PostCreator) gestiona las publicaciones y permisos de acceso a las mismas, mediante la creación un archivo (.ttl) por cada publicación en el directorio “posts” como muestra en Ilustración 44, en esta ilustración se puede ver que el directorio posts cuenta con dos publicaciones.
Ilustración 44: POD SOLID, directorio posts en donde se almacenan las publicaciones.
37
Para cada publicación el componente gestiona tipos de acceso entre “público”, “privado” y “amigos” (ver Ilustración 43) para ello actualiza el archivo ACL ( Access Control List ver apartado Control de Acceso) de la publicación respectiva. Para desarrollar este componente se utilizó las librerías TripleDoc y solid-auth-client, en la Ilustración 45 se muestra un ejemplo de la creación de un archivo ACL (usando Triple Doc ) con permisos de lectura, escritura y control al usuario con sesión activa (solid-auth-client). async aclOnlyForMe(document){ await auth.trackSession(session => { if(session){ let nameAcl = document+".acl"; const dataFolder = createDocument(nameAcl); const dataFolderACL = dataFolder.addSubject(); dataFolderACL.addRef(rdf.type, acl.Authorization); dataFolderACL.addRef(acl.accessTo, doc); dataFolderACL.addRef(acl.agent, session.webId); dataFolderACL.addRef(acl.mode, acl.Read); dataFolderACL.addRef(acl.mode, acl.Write); dataFolderACL.addRef(acl.mode, acl.Control); dataFolder.save([dataFolderACL]); }}) } Ilustración 45: Ejemplo creación y escritura de un archivo ACL (Access Control List)
Nota: Para el diseño de este componente surgió la interrogante sobre el manejo de privacidad de las publicaciones para lo que se planteaba un solo archivo de registro de publicaciones, pero luego de investigar e intervenir con la comunidad de SOLID se llegó a la conclusión que se manejaría un archivo por cada publicación ver Anexo 9.1.1 Privacy of .ttl registries. Durante la actualización de permisos en la publicación de usuario, repentinamente daba errores de autorización para lo que se verificó con múltiples PODS y se intervino con la comunidad ver anexo 9.1.3 Update trusted applications, para el cual también se levantó un Issue en el repositorio oficial de SOLID [45].
38
3.3.3.6 GESTIONAR AMIGOS
Ilustración 46: Interfaz de usuario RSD TODAY – Amigos
El componente amigos permite agregar amigos mediante el WebId del Amigo sea este de cualquier proveedor de PODS [40], también permite visualizar los amigos mediante una lista que proporciona la foto de perfil, el WebId y la información básica. Para desarrollar este componente se utilizó las librerías RDFLib para agregar o eliminar amigos del usuario y TripleDoc para la lectura de los datos de los PODS de amigos. RDFLib [46] permite buscar, analizar y serializar datos RDF en varios formatos/serializaciones (Turtle, RDF / XML, RDFa, etc.), en el desarrollo de RDS TODAY se empleó como indica Ilustración 47 para conocer los amigos del usuario. const FOAF = Namespace("http://xmlns.com/foaf/0.1/”) // establece el Predicado const $rdf = require('rdflib') var store = $rdf.graph();
// Cuando uno de los términos del triple se establece como indefinido , sirve como comodín. En este caso, la fórmula devuelve el objeto de un triple coincidente. let friends = store.each(me, FOAF('knows'), undefined) for (var i=0; i Nota: Durante el diseño de este componente se realizó una intervención con la comunidad SOLID debido a que se presentó un error durante la eliminación de amigos ver anexo 9.1.2 Remove friend! 403 (User Unauthorized). 39 3.3.4 PUESTA EN PRODUCCIÓN DE RSD TODAY RSD TODAY se encuentra en un repositorio de GitHub disponible desde la siguiente dirección: - https://github.com/MONISANCHEZ10/RSDSocialLinkedData Es necesario clonar o descargar el proyecto, como indica la Ilustración 48. > git clone https://github.com/MONISANCHEZ10/RSDSocialLinkedData Cloning into RSDSocialLinkedData... remote: Enumerating objects: 7828, done. remote: Counting objects: 100% (7828/7828), done. remote: Compressing objects: 100% (5572/5572), done. remote: Total 7828 (delta 1452), reused 7639 (delta 1304), pack-reused 0 Receiving objects: 100% (7828/7828), 6.14 MiB | 4.15 MiB/s, done. Resolving deltas: 100% (1452/1452), done. Ilustración 48: Clonando el proyecto desde el repositorio GitHub Luego se debe dirigir a la directorio raíz del proyecto y ejecutar el comando “npm install” para instalar dependenciaas del proyecto como inica la Ilustración 49. > npm install npm WARN @unimodules/[email protected] requires a peer of react-native@* but none is installed. You must install peer dependencies yourself. npm WARN [email protected] requires a peer of popper.js@^1.16.1 but none is installed. You must install peer dependencies yourself. npm WARN [email protected] requires a peer of webpack@^3.1.0 but none is installed. You must install peer dependencies yourself. Ilustración 49: Instalación de dependencias del proyecto Para poner en producción la aplicación el tener muchos archivos de Javascript no es ideal para ello es necesario minimizar la cantidad y tamaño de archivos, para lo cualde debe compilar el código con el comando “npm run build” como se muestra en la Ilustración 50. > npm run build > [email protected] build D:\MASTER\TFM\RSD\solid-social- react-simple > webpack --config ./webpack.config.js --mode production | ./src/assets/images/people.png 3.87 KiB [built] | ./src/assets/images/login-icon.png 20.6 KiB [built] | ./src/lib/PostsHelpers.js 14.8 KiB [built] | ./src/lib/agent-solid.js 1.3 KiB [built] ... Ilustración 50: Compilación del proyecto Al terminar la ejecuión se generaran unos archivos compactos necesarios para la ejecución de RSD TODAY, ahora mediante index.html podrá acceder directamente (ver Ilustración 51). 40 Ilustración 51: Interfaz de usuario RSD TODAY–Login 41 4 ANÁLISIS DE LOS RESULTADOS OBTENIDOS 4.1 SERVIDOR SOLID CON DOCKER Como resultado se tiene un servidor SOLID con Docker disponible para la creación de PODS locales, con los que se pude conocer la estructura y contenido de directorios del servidor ver la Ilustración 52, como también la estructura de un POD (directorio monica.localhost) con sus respectivos LDPC (Linked Data Platform Containers ver sección 2.4.1.6) D:. ├───.db │ └───oidc │ ├───op │ │ ├───clients │ │ ├───codes │ │ ├───refresh │ │ └───tokens │ ├───rp │ │ └───clients │ └───users │ ├───users │ └───users-by-email ├───.well-known ├───Certificates ├───config │ ├───templates │ │ ├───emails │ │ ├───new-account │ │ │ ├───.well-known │ │ │ ├───inbox │ │ │ ├───private │ │ │ ├───profile │ │ │ ├───public │ │ │ └───settings │ │ └───server │ │ └───.well-known │ └───views │ ├───account │ ├───auth │ └───shared ├───localhost │ └───.well-known ├───monica.localhost │ ├───.well-known │ ├───inbox │ ├───private │ ├───profile │ ├───public │ └───settings Ilustración 52: Estructura de directorios SOLID Server con Docker. 42 4.2 APLICACIÓN WEB RSD TODAY Como resultado del desarrollo de la aplicación RSD TODAY se cuenta con funcionalidades como • Login de usuario • Consulta y actualización del perfil • Gestión y privacidad de publicaciones • Galería de fotos • Gestión de amigos Estos componentes cuentan con la ventaja de consultar información de PODS descentralizados en la web mediante métodos que favorecen los mecanismos de consulta y respuesta entre ellos (ver 2.4.1.5 Recursos de Lectura y Escritura). Tanto RSD TODAY como otras aplicaciones web descentralizadas no dependen de un servidor centralizado de datos, por lo que si uno de los SOLID IPDs falla no afectaría a la disponibilidad de la aplicación y la capacidad de seguir interactuando con los demás IDPs (ver sección 3.3.2 sobre arquitectura y diseño de la solución). Durante el desarrollo de RSD TODAY se logró conocer el funcionamiento y escalabilidad de una aplicación web semántica, al usar el frameworks React Js se obtuvo ventajas como modularidad respecto a los componentes (casos de uso) y flexibilidad durante el proceso de desarrollo respecto a los requerimientos investigativos necesarios, con el siguiente resumen Tabla 7. Caso de Uso Descripción Componente Librerías Vocabularios React Js Login Iniciar sesión en la aplicación con Login solid-auth- CERT[47] el proveedor de PODS SOLID client [41] descentralizado elegido por el usuario (SOLID Server local, SOLID Community o Inrupt). Mostrar perfil Cargar la información del perfil del ShowProfile LDflex [42] FOAF [29] usuario. VCARD [26] Actualizar perfil Permitirá editar la información del EditProfile LDflex FOAF usuario, datos personales y foto. VCARD Galería de fotos Añadir fotos, permitirá adjuntar AddPhoto TripleDoc [48] SCHEMA.ORG un pie de foto opcional. [49] OWL [20] 43 Privacidad de Únicamente se manejarán PostCreator TripleDoc SCHEMA.ORG publicaciones permisos de visualización ente OWL público, mis amigos y solo yo. ACL Gestionar Debe permitir agregar amigos FriendsInfo TripleDoc FOAF amigos mediante WebId a usuarios con RDFLib [46] VCARD perfil público independientemente del proveedor de PODS. Tabla 7: Vocabularios y librerías empleados por cada caso de uso de RSD TODAY 44 5 ESTUDIO ECONÓMICO Este proyecto tuvo enfoque en investigar y analizar tecnologías web semánticas, SOLID, y el diseño de una aplicación web, para poder desarrollar una Red Social Descentralizada que abarque estas tecnologías. La Ilustración 53, muestra el porcentaje de tiempo invertido por cada fase del proyecto y las actividades realizadas se describen en la Tabla 8. ANÁLISIS INVESTIGACIÓN 28% 33% DESARROLLO 39% Ilustración 53: Tiempo invertido por fases. Fase Actividades Horas Tiempo (%) Investigación Estado del arte de SOLID, Linked Data y Web 40h 33% Semántica Análisis de arquitectura SOLID 40h Integración SOLID con aplicaciones web 40h semánticas Desarrollo Levantamiento de servidor SOLID 20h 39% Diseño de componentes 40h Desarrollo de componentes 80h Análisis Definición de objetivos y enfoques 10h 28% Mockups de la aplicación 10h Elaboración de memoria 80h TOTAL 360h 100% Tabla 8: Enfoque y porcentaje de tiempo invertido en el proyecto 45 6 CONCLUSIONES • El punto de inicio del proyecto consistió en conocer el ecosistema de SOLID, mediante el levantamiento de un Servidor de PODS con Docker. Esto permitió explorar parte de la arquitectura descentralizada que provee tanto para usuarios (la creación de PODS en SOLID IDPs) como para aplicaciones web semánticas (ver apartado 3 sobre la ejecución del proyecto). • Actualmente SOLID cuenta con respaldo de instituciones como el MIT, Inrupt y SOLID Community que respaldan el desarrollo de esta nueva tecnología. También está sujeto a los estándares de la W3C que hace a SOLID cada vez más atractivo para desarrollar aplicaciones web semánticas para descentralizar la web y tener un control propio de nuestros datos. • Existen librerías que cuentan con versiones beta, es el caso de solid-client versión 0.24.3 [50]. Adicionalmente, otras librerías cuentan con documentación en proceso (ver Anexos), lo que ocasiona una curva de aprendizaje prolongada. • Desde el punto de vista investigativo se obtuvo conocimientos sobre tecnologías web semánticas y Linked Data, lo que permitió identificar posibles casos de uso a desarrollar y los recursos tecnológicos necesarios tales como librerías, frameworks de desarrollo y arquitectura de la aplicación RSD TODAY, tomando en cuenta plazos de entrega del proyecto. • Linked Data permite tener diversidad de fuentes de datos con diferentes contextos sociales, ya sea medicina, política, educación, cultural etc., y la web semántica nos permite el intercambio de información entre aplicaciones de forma estandarizada. Así pues, permite la creación o adaptación aplicaciones que involucren el desarrollo en distintas líneas de negocio. • SOLID Server proporciona una plataforma flexible para desarrolladores mediante estándares internacionales de la W3C y soporte por entidades a cargo del proyecto (MIT, Inrupt, SOLID Forum) que actualmente están trabajando para seguir madurando las librerías (ver apartado 2.4 SOLID (Social Linked Data). • A usuarios finales SOLID garantiza la privacidad y la disponibilidad de sus datos en la web mediante tecnologías web semánticas como vocabularios FOAF, VCARD, CERT, que permiten mantener una misma estructura de datos en los PODS. • Existen entidades, organizaciones, desarrolladores entre otros que están actuando en diferentes roles para probar y desarrollar este nuevo ecosistema (ver apartado 1.3 Situación Actual) que favorecen el intercambio de conocimiento y experiencias con SOLID, con lo cual se concluye que existe amplio camino investigativo y de desarrollo para la web semántica y aplicaciones web que funcionen dentro de ella. 46 7 LÍNEAS DE FUTURO El trabajo realizado aporta una serie de posibles líneas de trabajo futuro tanto de investigación, desarrollo e innovación que permitan ampliar este proyecto o crear nuevas aplicaciones con otros enfoques sociales: Dentro del desarrollo de RSD TODAY, se puede ampliar los casos de uso partiendo de los que ya se tiene desarrollado con funciones como notificaciones, interacción con publicaciones de usuarios, módulo de chat, etc. Respecto al servidor SOLID con Docker, se encuentra con certificados autofirmados lo que permite tener un servidor SOLID local para estudio y pruebas. Como línea futura se podría implementar un servidor SOLID personal u organizacional disponible en la web. SOLID es una plataforma open source que se encuentra respaldada por organismos internacionales, con enfoque a tener el control total de nuestros datos, esto hace que tenga una amplia oportunidad de mercado en respuesta a una necesidad social como es la privacidad de los datos. Entre las oportunidades de mercado encontramos la de proveedor de identidad (IDPS SOLID) que gestiona espacios personales u organizacionales (PODS), o el desarrollo de nuevas aplicaciones web semánticas en distintas disciplinas. Par finalizar, es necesario que se continúe investigando, desarrollando y compartiendo el conocimiento para potenciar nuevos y avanzados desarrollos tecnológicos que permitan ir migrando contenidos a la web semántica, y proveer aplicaciones web que respondan a las necesidades de los usuarios. 47 8 REFERENCIAS [1] “Welcome to Solid.” https://solid.community/ (accessed Aug. 21, 2020). [2] “¡Felicidades, Internet! La World Wide Web cumple 30 años.” https://www.entrepreneur.com/article/330031 (accessed Aug. 21, 2020). [3] “Home | inrupt.” https://inrupt.com/ (accessed Aug. 21, 2020). [4] “Solid IDPs.” https://solid.github.io/solid-idps/ (accessed Sep. 02, 2020). [5] “Data - W3C.” https://www.w3.org/standards/semanticweb/data (accessed Sep. 10, 2020). [6] “Semantic Web - W3C.” https://www.w3.org/standards/semanticweb/ (accessed Sep. 10, 2020). [7] “About MIT | MIT - Massachusetts Institute of Technology.” https://www.mit.edu/about/ (accessed Aug. 25, 2020). [8] “SPA (Single-page application) - MDN Web Docs Glossary: Definitions of Web-related terms | MDN.” https://developer.mozilla.org/en-US/docs/Glossary/SPA (accessed Sep. 11, 2020). [9] “Verifiable Credentials Data Model 1.0.” https://www.w3.org/TR/vc-data-model/ (accessed Aug. 25, 2020). [10] “Tim Berners-Lee presenta su evolución de la World Wide Web: ‘ha llegado a un punto de inflexión y necesita un cambio poderoso.’” https://www.xataka.com/privacidad/tim- berners-lee-presenta-su-evolucion-world-wide-web-ha-llegado-a-punto-inflexion- necesita-cambio-poderoso (accessed Aug. 21, 2020). [11] “Solid Community Forum.” https://forum.solidproject.org/ (accessed Aug. 31, 2020). [12] “Página de inicio de productos | arruinar.” https://inrupt.com/products (accessed Sep. 08, 2020). [13] “Solid Community Forum.” https://forum.solidproject.org/ (accessed Aug. 30, 2020). [14] “Web semántica - W3C.” https://www.w3.org/standards/semanticweb/ (accessed Aug. 21, 2020). [15] “The Linked Open Data Cloud.” https://lod-cloud.net/ (accessed Aug. 21, 2020). [16] “Internationalized Resource Identifiers (IRIs).” https://www.w3.org/International/O- URL-and-ident.html (accessed Sep. 10, 2020). [17] “RDF 1.1 Turtle.” https://www.w3.org/TR/turtle/ (accessed Sep. 10, 2020). [18] “RDF - Semantic Web Standards.” https://www.w3.org/RDF/ (accessed Sep. 10, 2020). 48 [19] “RDF Schema 1.1.” https://www.w3.org/TR/rdf-schema/ (accessed Sep. 10, 2020). [20] “OWL - Semantic Web Standards.” https://www.w3.org/OWL/ (accessed Sep. 10, 2020). [21] “SPARQL Query Language for RDF.” https://www.w3.org/TR/rdf-sparql-query/ (accessed Sep. 10, 2020). [22] “SWRL: A Semantic Web Rule Language Combining OWL and RuleML.” https://www.w3.org/Submission/SWRL/ (accessed Sep. 10, 2020). [23] “RIF Overview (Second Edition).” https://www.w3.org/TR/rif-overview/ (accessed Sep. 10, 2020). [24] “semantic - recurso rdf - Resuelto.” https://code.i-harness.com/es/q/94d9e9 (accessed Sep. 02, 2020). [25] “Data Access Working Group (DAWG).” https://serc.carleton.edu/usingdata/dawg/index.html (accessed Aug. 21, 2020). [26] “vCard Ontology - for describing People and Organizations.” https://www.w3.org/TR/vcard-rdf/ (accessed Aug. 21, 2020). [27] “vCard Ontology - for describing People and Organizations.” https://www.w3.org/TR/vcard-rdf/ (accessed Sep. 08, 2020). [28] “Ontologías - W3C.” https://www.w3.org/standards/semanticweb/ontology (accessed Sep. 02, 2020). [29] “Especificación de vocabulario FOAF.” http://xmlns.com/foaf/spec/#sec-for (accessed Aug. 21, 2020). [30] L. F. Sikos, Mastering structured data on the semantic web: From HTML5 microdata to linked open data. 2015. [31] “WebVOWL.” http://www.visualdataweb.de/webvowl/#iri=http://www.w3.org/2006/vcard/ns (accessed Aug. 21, 2020). [32] “El ecosistema sólido.” https://solid.github.io/specification/#clients (accessed Sep. 02, 2020). [33] “solid/solid-signup: Signup and login app.” https://github.com/solid/solid-signup (accessed Sep. 09, 2020). [34] “solid / solid-spec: la arquitectura y las especificaciones sólidas.” https://github.com/solid/solid-spec#standards-used (accessed Sep. 02, 2020). [35] “W3Counter: Global Web Stats.” https://www.w3counter.com/globalstats.php (accessed Sep. 05, 2020). 49 [36] “Los mejores navegadores web de 2020 - PCWorld.” https://www.pcworld.es/mejores- productos/internet/mejores-navegadores-web-3672988/ (accessed Sep. 05, 2020). [37] “(8) SPA (Single Page Application ) in React - For Beginners [6] - YouTube.” https://www.youtube.com/watch?v=ev_BwtCbnCI (accessed Sep. 06, 2020). [38] “React – Una biblioteca de JavaScript para construir interfaces de usuario.” https://es.reactjs.org/ (accessed Sep. 08, 2020). [39] “Single page application in React on ASP.NET Core.” https://www.soloco.be/realtimeweb-net-react-on-aspnet-core/ (accessed Sep. 06, 2020). [40] “Solid IDPs.” https://solid.github.io/solid-idps/ (accessed Sep. 02, 2020). [41] “solid/solid-auth-client: A browser library for performing authenticated requests to Solid pods.” https://github.com/solid/solid-auth-client (accessed Sep. 06, 2020). [42] “GitHub - solid/query-ldflex: Simple access to data in Solid pods through LDflex expressions.” https://github.com/solid/query-ldflex (accessed Sep. 06, 2020). [43] “TripleDocument · Tripledoc.” https://vincenttunru.gitlab.io/tripledoc/docs/api/interfaces/tripledocument.html (accessed Sep. 07, 2020). [44] “TripleSubject · Tripledoc.” https://vincenttunru.gitlab.io/tripledoc/docs/api/interfaces/triplesubject.html (accessed Sep. 07, 2020). [45] “Update trusted applications · Issue #248 · solid/solid-panes.” https://github.com/solid/solid-panes/issues/248 (accessed Sep. 11, 2020). [46] “solid/solid-tutorial-rdflib.js: Tutorials for using rdflib.js.” https://github.com/solid/solid- tutorial-rdflib.js (accessed Sep. 07, 2020). [47] “The Cert Ontology Specification.” https://www.w3.org/ns/auth/cert (accessed Sep. 09, 2020). [48] “tripledoc - npm.” https://www.npmjs.com/package/tripledoc (accessed Sep. 07, 2020). [49] “Home - schema.org.” https://schema.org/ (accessed Sep. 11, 2020). [50] “solid-client - npm.” https://www.npmjs.com/package/solid-client (accessed Sep. 08, 2020). [51] “Privacy of .ttl registries - General Discussion - Solid Community Forum.” https://forum.solidproject.org/t/privacy-of-ttl-registries/3383 (accessed Sep. 09, 2020). [52] “Manage Access to Data (ACL) — Inrupt JavaScript Client Libraries.” https://docs.inrupt.com/developer-tools/javascript/client-libraries/tutorial/manage- access-control-list/ (accessed Sep. 09, 2020). 50 [53] “Remove friend! 403 (User Unauthorized) - General Discussion - Solid Community Forum.” https://forum.solidproject.org/t/remove-friend-403-user-unauthorized/3358 (accessed Sep. 09, 2020). [54] “Update trusted applications - General Discussion - Solid Community Forum.” https://forum.solidproject.org/t/update-trusted-applications/3401 (accessed Sep. 09, 2020). [55] “solid/solid-panes: A set of core solid-compatible apps based on solid-ui.” https://github.com/solid/solid-panes (accessed Sep. 09, 2020). 51 9 ANEXOS 9.1 PARTICIPACIÓN CON LA COMUNIDAD DE SOLID 9.1.1 PRIVACY OF .TTL REGISTRIES [51]se expuso si existe la posibilidad de manejar aspectos de privacidad en los registros de un archivo en sintaxis TURTLE (ver Ilustración 54), con el objetivo de mejorar el componente de Privacidad de publicaciones (apartado 3.3.3.5 Privacidad de publicaciones), para que en lugar de generar un archivo por publicación, generar un único registro (.ttl) que gestione los post de usuarios. Ilustración 54: Intervención con la comunidad SOLID Forum Privacity of .ttl registries Como resultado quedó claro que el manejo de accesos de lectura, escritura y control en los PODS de SOLID únicamente se manejan con un recurso ACL (Access Control List) por documento, como también que Inrupt está trabajando en una librería @inrupt/solid-client [52] para gestión de ACL que también se encuentra en versión beta sujeta a cambios. 52 9.1.2 REMOVE FRIEND! 403 (USER UNAUTHORIZED) Esta intervención [53] se dio a raíz de una respuesta 403 (user unauthorized) a la eliminación del WebId (del amigo) en el documento de perfil de usuario durante el desarrollo del componente de gestión de amigos (3.3.3.6 Gestionar Amigos) como indica la Ilustración 55, la comunidad sugiere cambiar de librería a TripleDoc. Finalmente se logra actualizar el documento del perfil del usuario identificando que la documentación de LDFlex se encuentra desactualizada y solid-client está en versión beta por lo que no es aconsejable su uso de momento para este proyecto por ser susceptible a cambios. Ilustración 55: Intervención con la comunidad SOLID Forum Remove friend! 403(User Unauthorized) 53 9.1.3 UPDATE TRUSTED APPLICATIONS Esta intervención [54] se realizó para dar a conocer un inconveniente con la carga de aplicaciones de confianza, que durante la actualización de permisos de las publicaciones de usuario (3.3.3.5 Privacidad de publicaciones) estas no persisten (Ilustración 57) o simplemente no se muestran como indica la Ilustración 56. Ilustración 56: Intervenció con la comunidad SOLID Forum Update Trusted Aplications 54 Ilustración 57: Intervención con la comunidad Solid Forum Update Trusted Aplications Aparentemente se trata de un error el cual luego de las distintas intervenciones de la comunidad se llegó a la conclusión de reportarlo como Issue (Ilustración 58) en el repositorio oficial de SOLID en GitHub [55]. 55 Ilustración 58: Repositorio de SOLID en GitHub sección Issues[45] 9.2 MOCKUPS 9.2.1 MOCKUP LOGIN DE USUARIO El diseño de este componente principalmente contempló que se pueda iniciar sesión con más de un SOLID IDPs (ver Ilustración 59). Ilustración 59: Mockup login de usuario 56 9.2.2 MOCKUP PERFIL DE USUARIO La Ilustración 60 muestra el diseño del perfil de usuario luego del inicio de sesión. Ilustración 60: Mockup Perfil de usuario 9.2.3 MOCKUP EDITAR PERFIL DE USUARIO La interfaz de usuario para la edición de datos del perfil se diseñó como muestra la Ilustración 61, tomando en cuenta los datos del perfil de los PODS que se puede ver en cada SOLID Identity Provider [4]. Ilustración 61: Mockup Editar perfil de usuario 57 9.2.4 MOCKUP PUBLICAR POST La publicación de post se diseñó como muestra la Ilustración 62, manejando la privacidad únicamente a dos niveles debido a que en este punto se desconocía aún algunos aspectos de privacidad. Ilustración 62: Mockup Publicar post 9.2.5 MOCKUP GESTIONAR AMIGOS El diseño del componente gestión de amigos se realizó como indica en la Ilustración 63, con funcionalidades de mostrar, agregar y eliminar amigos. Ilustración 63: Mockup gestión de amigos 58