# Solid (proyecto de descentralización web)

Solid (acrónimo del inglés Social Linked Data) es un proyecto de descentralización de datos en la web dirigido por Tim Berners-Lee (el inventor de la web semántica) desarrollado en el Instituto de Tecnología de Massachusetts (MIT). El objetivo principal del proyecto es cambiar de forma radical la manera en la que las aplicaciones web funcionan hoy en día, siendo el usuario quien decide dónde almacenar sus datos, mejorando de esta forma la privacidad. Los usuarios pueden decidir dónde almacenar sus datos, incluyendo el control de acceso que estimen oportuno. Para fomentar el desarrollo y utilización de esta nueva forma de uso de la web, Tim Berners-Lee fundó una compañía llamada Inrupt.
En palabras de Berners-Lee: «Es la forma en que evolucionamos la web para restablecer el equilibrio, dándonos a cada uno de nosotros el control total de los datos, personales o no, de una manera revolucionaria».

## Historia

Dos décadas después de que inventara la red informática mundial en 1989, Berners-Lee resumió, en un borrador que escribió para el Consorcio WWW, los errores de diseño de lo que más tarde se convertiría en el proyecto Solid. Berners-Lee estaba cada vez más decepcionado del mal uso de su proyecto, con casos como las acusaciones de interferencia rusa en las elecciones presidenciales de Estados Unidos de 2016, cuando el escándalo del caso Facebook-Cambridge Analytica se hizo público, cuando Facebook llevó a cabo experimentos psicológicos en casi 700,000 usuarios en secreto en 2012, o cuando Google y Amazon solicitaron patentes en dispositivos que percibían cambios emocionales en las voces de las personas.
Berners-Lee sintió que Internet estaba en una situación deplorable, por lo que creó el proyecto Solid a modo de primer paso para repararlo, para permitir a los usuarios individuales tener control total sobre el uso de sus datos. El proyecto Solid está disponible para todo aquel que quiera unirse y contribuir, aunque Berners-Lee aconseja a la gente que no tenga conocimientos de programación que defienda públicamente cambiar Internet en su lugar.
En 2015, MIT recibió un millón de dólares de Mastercard para apoyar el desarrollo de Solid. El equipo de investigación de Berners-Lee colaboró con el Instituto de Investigación Informática de Catar y la Universidad de Oxford en Solid.
En 2018, Berners-Lee se tomó un año sabático en MIT para fundar Inrupt. La misión de esta empresa es "proporcionar energía comercial y un ecosistema para ayudar a proteger la integridad y calidad de la nueva red creada en Solid."

## Arquitectura y diseño

Hay un número de retos técnicos que hay que superar para llevar a cabo el proyecto de descentralización de datos en las aplicaciones web, según la visión de Berners-Lee. Más que simplemente utilizar el paradigma distribuido spoke-hub, esta nueva forma de tratar con la web permite al usuario (al igual que ocurre con el protocolo P2P) decidir dónde alojar la información y con quién compartirla. Sin embargo, siempre trabaja sobre el protocolo HTTP y utilizando una estructura descentralizada, no punto a punto como BitTorrent. Otros objetivos perseguidos por el sistema son: ser fácil de utilizar, ser rápido, y permitir desarrollar aplicaciones de una forma sencilla.
El foco central del proyecto Solid radica en permitir el descubrimiento y compartición de información de una forma que mantenga la privacidad. Un usuario almacena sus datos en un POD, del inglés Personal Online Datastore (se podría traducir por almacenamiento personal de datos), alojados en el servidor que el usuario considere más oportuno, siendo generalmente alguno ofertado por una compañía, aunque también es posible que el usuario utilice su propio servidor. Las aplicaciones que utilizan Solid tienen permitido tratar la información del usuario siempre que este se encuentre autenticado y haya dado permiso a la misma. Un usuario puede distribuir información personal entre uno o varios pods; por ejemplo, los diferentes pods podrían contener información del perfil del usuario, información de contacto, datos bancarios, información de salud, viajes u otra información. De esta forma el usuario podría permitir a una determinada aplicación web el acceso al pod que estime oportuno teniendo siempre el control y propiedad de los datos alojados en el pod.

### Características principales

Entrando en más detalle, el proyecto Solid tiene las siguientes características:
* Está formado por una colección organizada de estándares, formatos de datos y vocabularios que proporcionan las mismas capacidades que las actuales aplicaciones sociales ofrecen, como identidad, autenticación, inicio de sesión, listas de permisos, administración de contactos, mensajería, suscripciones, comentarios, discusiones, y otros.
* Las especificaciones y el diseño se basan en el protocolo HTTP, servicios REST y HTML, lo que permite un 100% de compatibilidad con la estructura de la web existente aumentando sus capacidades. Este hecho también facilita la tarea a desarrolladores de aplicaciones y administradores de servidores.
* Un entorno para testear y validar las implementaciones de Solid.
* Un ecosistema de aplicaciones sociales, proveedores de identidad, y bibliotecas de ayuda que funcionan en la plataforma de Solid.
* Una amplia comunidad que proporciona documentación, discusiones, tutoriales, y presentaciones, además de diferentes eventos para fomentar y mostrar la capacidad de esta nueva forma de trabajar con aplicaciones web.
Un servidor se puede habilitar para funcionar dentro del ecosistema Solid alojando pods mediante NodeJS de una forma sencilla.
Otra de las ventajas que tiene el proyecto, además del de aumentar la privacidad, es el de dar una mayor comodidad al usuario, facilitando la interoperabilidad de los datos. Esto permite utilizar un mismo pod para identificarse en diferentes aplicaciones web y que estas, basándose en diversos esquemas de nombres, accedan a los datos de perfil de forma que no se tenga que repetir el proceso en cada aplicación que el usuario quiera utilizar. Actualmente se encuentran fijados tres espacios de nombres: rdf, ldp y solid.
Entre el listado de convenciones que el proyecto Solid utiliza están: WebID-OIDC, WebID-TLS, Web Access Control. WebID-OIDC se utiliza como otro método de autenticación primario que está basado en los protocolos OAuth2/OpenID. WebID-TLS constituye otro mecanismo de autenticación primario utilizando certificados criptográficos en lugar de contraseñas. Web Access Control permite el acceso restringido a personas y grupos estando identificados mediante URI.
RDF es el lenguaje de almacenamiento de datos utilizado en el proyecto Solid. Permite acceder a la información de una forma más "natural", facilitando la tarea de los desarrolladores y permitiendo la interoperabilidad mencionada anteriormente.

## Usos y aplicaciones de Solid

Para hacer uso de las aplicaciones que implementan Solid es necesario tener un pod y un WebID. Como se comentaba anteriormente, los pods son las estructuras que utiliza Solid para almacenar datos; por otro lado, el WebID sirve para identificarse en Solid y acceder a nuestros pods, así como conectar con otra gente que utiliza Solid.
El primer paso para crear un pod es elegir dónde queremos almacenarlo. Solid permite elegir entre una lista de proveedores, o bien gestionar de forma personal el pod generado. En la actualidad, la lista de proveedores ofrecidos es la siguiente:
| Proveedor | Responsable del nombre del dominio | Responsable del almacenamiento | Localización física del almacenamiento |
| inrupt.net | Inrupt, Inc. | Amazon | Estados Unidos |
| solid.authing.cn | Authing | Tencent Cloud | China |
La lista es abierta y cualquier proveedor de servicios cloud interesado puede ofrecerse como colaborador.
Por otro lado, si la opción elegida por el usuario es alojar sus propios pods personalmente, necesita configurar su propio servidor. Para ello es necesario instalar el servidor de Solid que, al estar diseñado en Node.js, requiere el uso de JavaScript. Existe una guía detallada sobre este procedimiento de instalación en la página web del proyecto.
Una vez configurado el entorno para utilizar Solid, un desarrollador puede comenzar a escribir aplicaciones que lo utilicen. Estas aplicaciones pueden programarse en Angular o React ya que disponen de gran número de librerías y soporte que facilitan su desarrollo, no obstante, también se puede hacer uso de JavaScript directamente. En la página del proyecto pueden encontrarse ejemplos e instrucciones detalladas sobre este punto.
Si bien la implementación sigue pasos diferentes para cada framework, un paso común en ambas es la identificación del usuario en un servidor Solid para acceder a su(s) pod(s). Para ello, se sugiere redirigir a un portal de acceso en el propio servidor, codificando en la URL la dirección de la aplicación a la que se debería regresar cuando se complete el login. El usuario necesitará identificarse en su proveedor (o su propio servidor Solid) con su WebID personal.

### Ejemplos de aplicaciones que usan Solid

A modo de ejemplo, se citan algunos proyectos que utilizan Solid de manera interesante:
* File Extractor for Pods: extrae archivos desde los pods del usuario.
* Solid Notify: envía al usuario una notificación de escritorio cuando uno de sus recursos Solid (en esencia, un pod) es modificado.
* WebID Profile editor: permite al usuario modificar los detalles de su perfil WebID en el proyecto Solid.
* Twee-Fi: ayuda al usuario a verificar y puntuar la credibilidad de un tuit.
* Solid Calendar: sirve para crear, almacenar y consultar eventos utilizando tarjetas de usuario almacenadas en pods.

## Seguridad
### Consideraciones

Desde la página de especificación de Solid se explican una serie de medidas para garantizar la seguridad. Estas medidas son actualizadas o cambiadas conforme avance el desarrollo del proyecto.
* Un data pod no debe asumir que la cabecera del HTTP enviada por un usuario es válida. Se debe sanear o eliminar valores de cabecera inválidos antes de incorporarlos en mensajes dirigidos a otros
* Un data pod no debe asumir que el Agente de usuario en un Navegador web, incluso cuando contiene valores como "User-Agent" o "Origin". Si se asumiese se podría producir un fallo de seguridad al asumir que se están implementado ciertos modelos de seguridad a pesar de no estar implementados.
* Solid deshabilita todas las protecciones del CORS debido a que el acceso a recursos está dirigido por el Control de acceso a red. Debido a esto no se confiara en los estados de autentificación provistos por los mecanismos de protección "cross-origing" de los navegadores.
* Se ignoraran las Cookies de lugares desconocidos.
* Los data pods utilizaran TLS para garantizar el contenido de las peticiones y respuestas de escuchas o modificaciones por parte de terceros.

### Mecanismos de autentificación

Para garantizar que los datos almacenados externamente se acceden de manera segura y por los clientes con permiso, se dan una serie de especificaciones a seguir por parte del cliente y el servidor.

#### Hypertext Transfer Protocol

Los clientes de SOLID y los servidores que proveen sus servicios necesitan intercambiar los datos a través de internet, para ello se utilizará el protocolo HTTP que deberá ser implementado en los clientes y los servidores.

##### Implementación por parte del servidor

Los data pods deben tener mínimo el protocolo HTTP/1.1, se recomienda utilizar el protocolo HTTP/2 para optimizar el rendimiento.
Se recomienda usar conexiones TLS a través del esquema de URI de https para asegurar la comunicación. Si se permite conexiones por Http y https el servidor deberá redirigir a https. Un data pod deberá incluir la parte del servidor HTTP/1.1 "Conditional Request"7232 para asegurar que las actualizaciones pedidas por el usuario solo se realizan si ciertas precondiciones se han cumplido. Además, se recomienda el uso de "Caching" 7234 y "Range Request" 7233 para mejorar el rendimiento.

##### Implementación por parte del cliente

Se debe usar los protocolos HTML "Message Syntax and Routing"7230 y "Semantics and content"7231. Se debe implementar por parte del cliente "Authentification"7235 si se necesita acceso a recursos que requieren autentificación WebID.

#### Linked Data Platform

Los data pods deben seguir las especificaciones LDP

#### WebID

El acceso a data pods no públicos necesitan una autentificación con WebID.

#### Web Access Control

Los data pods deben seguir las especificaciones WAC

#### Cross-Origin Resource Sharing

Las apps que usan Solid acceden a datos desde múltiples fuentes, los navegadores tienden a bloquear el acceso a datos de una fuente a aplicaciones que acceden por otra fuente. Esta protección bloquea que las aplicaciones puedan acceder a los data pods de un usuario con su autorización. Para evitar este problema se indica al navegador mediante el mecanismo FETCH que no se requiere cross-origin protección mediante la utilización de cabeceras HTTP con combinaciones específicas que indican los recursos que se le dan a cada acción. En el caso de Solid data pods se permite todas las acciones a nivel de CORS.

##### Implementación por parte del servidor

Un data pod debe implementar el protocolo FETCH de CORS para permitir que los navegadores acepten cualquier petición y cabecera de petición de un data pod, y las aplicaciones en Solid puedan leer cualquier respuesta y cabecera de respuesta recibida de un data pod. Si un data pod bloquea el acceso se debe comunicar a través de HTTP no de CORS mediante los códigos de estado 401,403,404 7231.
Cuando un data pod recibe una petición HTTP que contiene un valor "Origin" válido 6454 el servidor debe responder con el "Access-Control-*" adecuado. El data pod convertirá la respuesta para que sea leíble por la app a través de "Access-control-Exposure-Headers".

## Licencia

El proyecto Solid está bajo la licencia del MIT y la licencia Creative Commons Attribution 4.0 International, para cubrir tanto el código como la copia respectivamente. Las licencias individuales de cada repositorio se mencionan en el fichero license.md de cada repositorio.
Se otorga permiso de forma gratuita a cualquier usuario para que obtenga una copia del software presente en el repositorio GitHub del proyecto. El usuario puede utilizar el software sin ningún tipo de restricción. Esto incluye el derecho de uso, copia, modificación, fusión, publicación, distribución, sublicencia y/o ventas de copias del software.
El párrafo anterior junto al siguiente aviso se incluirán en todas las copias o partes sustanciales del software:
«Este software se proporciona tal cual, es decir, sin garantía de ningún tipo, expresa o implícita, incluidas, entre otras, las garantías de comerciabilidad, idoneidad para un fin determinado y no infracción. En ningún caso, los autores o tituladores de los derechos de autor serán responsables de ninguna reclamación, daño u otra responsabilidad.»