Solid

Re-decentralizing the web

Solid (derived from "social linked data") is a proposed set of conventions and tools for building decentralized Web applications based on Linked Data principles. Solid is modular and extensible. It relies as much as possible on existing W3C standards and protocols.

Table of Contents

1. About Solid
2. Standards Used
3. Platform Notes
4. Project directory
5. Contributing to Solid

• Pre-Requisites
• Solid Project Workflow

About Solid

Specifically, Solid is:

• A tech stack -- a set of complementary standards and data formats/vocabularies that together provide capabilities that are currently available only through centralized social media services (think Facebook/Twitter/LinkedIn/many others), such as identity, authentication and login, authorization and permission lists, contact management, messaging and notifications, feed aggregation and subscription, comments and discussions, and more.
• A Specifications document that describes a REST API that extends those existing standards, contains design notes on the individual components used, and is intended as a guide for developers who plan to build servers or applications.
• A set of servers that implement this specification.
• A test suite for testing and validating Solid implementations.
• An ecosystem of social apps, identity providers and helper libraries (such as solid-auth-client) that run on the Solid platform.
• A community providing documentation, discussion (see the solid gitter channel), tutorials and talks/presentations.

Standards Used

The Solid platform uses the following standards.

• RDF 1.1 (Resource Description Framework) (see also RDF Primer) is heavily used in Solid data models. By default, the preferred RDF serialization format is Turtle. Alternative serialization formats such as JSON-LD and RDFa can also be used.

• The WebID 1.0 (Web Identity and Discovery) standard is used to provide universal usernames/IDs for Solid apps, and to refer to unique Agents (people, organizations, devices). See also the WebID interoperability notes for an overview of how WebID relates to other authentication and identity protocols.

• WebIDs, when accessed, yield WebID Profile documents (in Turtle and other RDF formats).

• The FOAF vocabulary is used both in WebID profiles, and in specifying Access Control lists (see below).

• Authentication (for logins, page personalization and more) is done via the WebID-TLS protocol. WebID-TLS extends WebID Profiles to include references to the subject's public keys in the form of X.509 Certificates, using Cert Ontology 1.0 vocabulary. The authentication sequence is done using the HTTP over TLS protocol. Unlike normal HTTPS use cases, WebID-TLS is done without referring to Certificate Authority hierarchies, and instead encourages host server-signed (or self-signed) certificates.

• In Solid, certificate creation is typically done in the browser using the HTML5 keygen element, to provide a one-step creation and certificate publication user experience.

• Authorization and access lists are done using Basic Access Control ontology (see also the WebAccessControl wiki page for more details).

• Solid uses the Linked Data Platform (LDP) standard (see also LDP Primer) extensively, as a standard way of reading and writing generic Linked Data resources.

Solid Platform Notes

Solid applications are somewhat like multi-user applications where instances talk to each other through a shared filesystem, and the Web is that filesystem.

1. The LDP specification defines a set of rules for HTTP operations on Web resources, some based on RDF, to provide an architecture for reading and writing Linked Data on the Web. The most important feature of LDP is that it provides us with a standard way of RESTfully writing resources (documents) on the Web, without having to rely on less flexible conventions (APIs) based around sending form-encoded data using POST. For more insight into LDP, take a look at the examples in the LDP Primer document.

2. Solid's basic protocol is REST, as refined by LDP with minor extensions. New items are created in a container (which could be called a collection or directory) by sending them to the container URL with an HTTP POST or issuing an HTTP PUT within its URL space. Items are updated with HTTP PUT or HTTP PATCH. Items are removed with HTTP DELETE. Items are found using HTTP GET and following links. A GET on the container returns an enumeration of the items in the container.

3. Servers are application-agnostic, so that new applications can be developed without needing to modify servers. For example, even though the LDP 1.0 specs contains nothing specific to "social", many of the W3C Social Work Group's User Stories can be implemented using only application logic, with no need to change code on the server. The design ideal is to keep a small standard data management core and extend it as necessary to support increasingly powerful classes of applications.

4. The data model is RDF. This means the data can be transmitted in various syntaxes like Turtle, JSON-LD (JSON with a "context"), or RDFa (HTML attributes). RDF is REST-friendly, using URLs everywhere, and it provides decentralized extensibility, so that a set of applications can cooperate in sharing a new kind of data without needing approval from any central authority.

Project directory

• Useful links

  • Specification
  • Talks
  • Tutorials
    • Intro to Solid Tutorial introductory Solid tutorial using the solid-auth-client library
    • Solid Angular Apps Tutorial: a set of example apps built on the Solid platform using AngularJS.
    • Working with RDF data tutorial about using a library called rdflib.js

• Implementing

  • Sign-up/Login application
  • Solid Server Test suite

• Community

  • Server implementations
  • Identity providers
  • Applications
  • Join our conversations in our gitter chat room

Contributing to Solid

Get a WebID

In order to try out some of the apps built using Solid, you will need typically an identity on some solid server. There are two forms of authentication we use, and so two types of account.

WebID-OIDC

This uses OpenID Connect to give you a WebID. It involves signing in with a password at your chosen identity provider, such as (2018/2) solid.community, or solidtest.space.

WebID_TLS

A WebID profile from one of the Solid-compliant identity providers, such as databox.me,

With WebID-TLS, you will need to make a WebID browser certificate from the above profile (this is usually created when you sign up for a WebID profile account, but it only works on Firefox at the moment (2018)).

Running a server

Additionally, to get started with developing for the Solid platform, you'll need:

1. A Solid-compliant server

2. While not required, an understanding of RDF/Turtle principles and Linked Data Platform concepts will help you understand the general workflow.

Solid Project Workflow

To contribute to Solid development, and to bring up issues or feature requests, please use the following workflow:

1. Have a question or a feature request or a concern about the Solid framework, or on one of its servers? Open an issue on solid/solid (this repo here).

2. Have an issue with the Solid spec specifically? Open an issue on solid/solid anyway. And then, as a result of discussion, if it's agreed that it is actually a Spec issue, it will be moved to solid-spec.

3. The individual solid/solid issues can coordinate and track component/dependent issues on the various affected Solid servers, apps, and so on.

Places to chat

We use gitter.im. There is a general chat solid/chat as well as specific chats about specific products such as node-solid-server