Solid

Solid (Social Linked Data) is a web decentralization project led by Tim Berners-Lee, the inventor of the World Wide Web. The project:

aims to radically change the way Web applications work today, resulting in true data ownership as well as improved privacy

by developing a platform for linked-data applications that are completely decentralized and fully under users' control rather than controlled by other entities.

Solid's central focus is to enable the discovery and sharing of information in a way that preserves privacy. A user stores personal data in "pods" (personal online data stores) hosted wherever the user desires. Applications that are authenticated by Solid are allowed to request data if the user has given the application permission.

A user may distribute personal information among several pods; for example, different pods might contain personal profile data, contact information, financial information, health, travel plans, or other information. The user could then join an authenticated social-networking application by giving it permission to access appropriate information in a specific pod.

The user retains complete ownership and control of data in the user's pods: what data each pod contains, where each pod is stored, and which applications have permission to use the data.

Philosophy

In "Paradigm shifts for the decentralized Web", Ruben Verborgh lays out several interesting ideas:

In this blog post, I will discuss three paradigm shifts we need to prepare for if we want to build Web applications with a decentralized mindset:

  1. End users become data owners. This is the most well-known decentralization aspect: we store our data in places of our choice, which improves privacy and control.
  1. Apps become views. As apps become decoupled from data, they start acting as interchangeable views rather than the single gateway to that data.
  1. Interfaces become queries. Data will be distributed across highly diverse interfaces, so sustainable apps need declarative contracts instead of custom data requests.

[...]

The main challenge with full decentralization of data is scalability. In the Mastodon scenario, there are still relatively few servers for many users. In the Solid scenario, there might even be more data pods than users. In the end, decentralization will go hand in hand with dynamic data replication, which will need to be balanced carefully with fine-grained access control possibilities in order to guarantee data privacy.

[...]

In contrast, decentralized Web applications decouple data and applications: you enter data only once—in your own data pod. Instead of maintaining credentials with each app, you log in through your data pod and give apps permission to read or write specific parts of your data. The Web’s ecosystem thereby evolves from bundled data+service packages into applications as interchangeable views, wherein each Web app provides consistent visualizations, interactions, and processing over your personal data pod. Furthermore, those apps let you interact with any other data pods you have access to, such as those of your friends. Applications ask rather than own, and they are able to reuse data create by other apps, avoiding vendor lock-in.

[...]

The combination of decentralization and query execution also confronts us with a temporally different way of interacting with data. In traditional Web applications, the procedure is typically “send query—wait for execution to complete—act on all results”. In a decentralized setting, we know that data collection will take time, so applications should be prepared to do more useful things instead of just waiting. The procedure becomes “send query—act on each incoming result”, processing every piece of incoming data a streaming way. In general, completeness should never be assumed, given that the Web is an open world. This is an additional indication of how radically the relation between data and applications will change.

Specification overview

Solid is a proposed set of conventions and tools for building decentralized social applications based on Linked Data principles. Solid is modular and extensible. It relies as much as possible on existing W3C standards and protocols.

  • Identity: Solid uses WebID URIs as universal usernames or actor identifiers. WebIDs provide globally unique decentralized identifiers, enable cross-service federated signin, prevent service provider lock-in, and give users control over their own identity.

  • Profiles: the WebID URI's primary function is to point to the location of a public WebID Profile Document. Solid uses these for management of user identity and security credentials (such as public keys), and user preferences discovery. Profiles are used by many actor types like users, groups, organizations, devices and software applications.

    A WebID URI, when dereferenced, yields a WebID Profile Document in a Linked Data format (Turtle by default, but often available as JSON-LD or HTML+RDFa). Parsing this document provides a client application with useful information, such as the user's name and profile image, links to user preferences and related documents, and lists of public key certificates or other relevant identity credentials.

    See component spec: Solid WebID Profiles Specification.

  • Authentication: the process of determining a user’s identity. Applications usually manage authentication with usernames and passwords as well as a recovery mechanism using typically email.

    Solid currently uses WebID-TLS as its primary authentication mechanism. Alternative complementary mechanisms are also being actively investigated. In addition, Solid recommends that server implementations also offer secondary authentication available for users for Account Recovery (via email or some other out-of-band mechanism).

    See component spec: Solid WebID-TLS Specification.

    The Solid team is currently implementing support for WebID-OIDC as another primary authentication mechanism. It is based on the OAuth2/OpenID Connect protocols, adapted for WebID based decentralized use cases.

    See component spec: WebID-OIDC Specification.

    There are several other authentication mechanisms that are currently being investigated, such as combinations of traditional username-and-password authentication and WebID-TLS Delegation.

    Regardless of the primary authentication mechanism, bearer tokens and other proofs of identity tend to get lost by users. Passwords can be forgotten, browser certificates can be lost to hardware failure, and so on. Solid recommends that secondary Account Recovery mechanisms are provided by server implementers, to aid in these scenarios.

  • Authorization and access control: the process of deciding whether a user has access to a particular resource. Solid currently uses the Web Access Control (WAC) mechanism for cross-domain authorization for all its resources.

    See component spec: Solid WAC Specification.

  • Content representation: Solid deals with reading and writing two kinds of resources: Linked Data resources (RDF in the form of JSON-LD, Turtle, HTML+RDFa, etc.) and everything else (binary data and non-linked-data structured text). you can build Solid applications with non-linked data resources, using actual RDF-based Linked Data provides you with considerable benefits in terms of interoperability with the rest of the Solid app ecosystem.

    See component spec: Solid Content Representation.

  • Reading and writing resources: Solid extends the Linked Data Platform spec to provide a simple REST API for CRUD operations on resources and containers. Solid also provides a WebSockets based API for a PubSub (Publish/Subscribe) mechanism, through which clients can be notified in real time of changes affecting a give resource.

    See component spec: HTTPS REST API.

    See component spec: WebSockets API.

  • Social web app protocols: Solid provides a number of specs and recommendations to help developers achieve interoperability between various social web applications that are part of the ecosystem. Currently, notifications. API recommendations for managing subscriptions and friends lists are still being discussed.

    See component spec: Linked Data Notifications

  • Recommendations for implementations: for servers and clients.

    See component spec: Recommendations for Server Implementations.

    See component spec: Recommendations for Client Implementations.

Querying

  • SPARQL, a recursive acronym for SPARQL Protocol and RDF Query Language, is an RDF query language — that is, a semantic query language for databases — able to retrieve and manipulate data stored in Resource Description Framework (RDF) format.

Ruben Verborgh and Ruben Taelman and others are doing a lot to connect GraphQL with Linked Data:

  • Querying on a decentralized Web - Ruben Verborgh - GraphQL Day 2018. Video and slides.

  • Bridges between GraphQL and RDF (slides)

  • GraphQL-LD: Linked Data Querying with GraphQL: In this article, we introduce GraphQL-LD, an approach that consists of a method for transforming GraphQL queries coupled with a JSON-LD context to SPARQL, and a method for converting SPARQL results to the GraphQL query-compatible response. We demonstrate this approach by implementing it into the Comunica framework. This approach brings us one step closer towards widespread Linked Data consumption for application development.

    Check out the code for the modules in the GraphQL-LD system: graphql-to-sparql.js, sparqljson-to-tree.js. Also, the live demo

  • HyperGraphQL: a GraphQL interface for querying and serving linked data on the Web. It is designed to support federated querying and exposing data from multiple linked data services using GraphQL query language and schemas. The core of the response is a JSON-LD object, which extends the standard JSON with the JSON-LD context enabling semantic disambiguation of the contained data.

  • Comunica: a Modular SPARQL Query Engine for the Web. Also, what it seems to be its home page and main GitHub repo.

  • Linked Data Fragments is a conceptual framework that provides a uniform view on all possible interfaces to RDF, by observing that each interface partitions a dataset into its own specific kind of fragments.

    A Linked Data Fragment (LDF) is characterized by a specific selector (subject URI, SPARQL query, …), metadata (variable names, counts, …), and controls (links or URIs to other fragments).

  • The RDF JavaScript Libraries Community Group discusses implementations of libraries for working with RDF and Linked Data in ECMAScript platforms like Web browsers and Node.js

  • "Designing a Linked Data developer experience" provides a great overview of LDflex, a JavaScript DSL for querying Linked Data on the Web. It presents an application including LDflex for Solid and Comunica for LDflex. Cool stuff.

Resources

Repositories of interest

Interesting apps

  • Ideas for Solid apps on Solid Discourse forum.

  • Solid app listing on Inrupt.

  • dokieli is a clientside editor for decentralised article publishing, annotations and social interactions.

  • graphMetrix Construction Linked Data Platform: Trinity transforms your data silos into Solid linked actionable information that you control.

  • Darcy. Social media done proper. Darcy will allow everyone to run their own federated social media instance – without having to worry about technology, moderation or legal compliance, because Darcy will take care of that for you – if you want!

  • Solid Pay is about making payments between two people on the Web. It builds heavily on the Solid framework and the webcredits specification.

  • solid-focus a task manager implemented in Vue, using the Solid protocol to store data into a Solid POD.

  • FormRouter. "Using a FormRouter Account, it is now possible to setup an online form that can route directly into a SOLID POD. This allows any person with a SOLID POD to get a copy of the form data they filled out. The submission data may include a copy of the form as a PDF attachment. We have also created a File Extraction Utility to open file attachments from your POD inbox."

  • solid-wiki

  • Solid POD It. All you need to know about the Solid Web and PODs.

  • Inrupt

  • Solid at MIT

  • The Data Transfer Project was formed in 2017 to create an open-source, service-to-service data portability platform so that all individuals across the web could easily move their data between online service providers whenever they want.

  • SAFE Network. Freedom of expression, control of personal data, private and secure communications, and a whole new economy.

  • Solid Hacks. Solid hacks shows you how to have the most satisfying web experience ever. You don't need programming ability. Just the ability to click, drag and drop files, and edit text. This will enable you to combine apps, data and functionality in new innovative ways.

  • Pieter Heyvaert put together this super detailed and awesome explanation of how his chess app works with Solid.

    First, we list the different features of the chess app. Second, we elaborate on the three high-level components of the app. Third, we list the different steps that are taken when certain actions are done by a player. Finally, we discuss how the data generated by this app can be used by other apps.

Community

Understanding Solid PODs

A POD is a personal storage space provided to you by a Solid enabled web server:

Store anything you want in your own Solid POD. PODs are like secure USB sticks for the Web, that you can access from anywhere. When you give others access to parts of your POD, they can react to your photos and share their memories with you. You decide which things apps and people can see.

Think of your Solid POD as your own private website, except that your data interoperates with all your apps, which means you have your own personal API to go along with it. When you post comments or videos online, your friends can view them with whatever app they like, such as an album viewer or a social feed. It’s your data, that can be shaped in any way or form.

You can have as many PODs as you like, and they live on Solid enabled Web servers. Install the Solid Server on your own server at your home or workplace, or Get a Solid POD from a listed provider.