Web Fundamentals
Re-decentralizing the Web

Ruben Verborgh, Ghent Universityimec

Web Fundamentals
Re-decentralizing the Web

Ruben Verborgh

Ghent University imec IDLab

Creative Commons License Except where otherwise noted, the content of these slides is licensed under a Creative Commons Attribution 4.0 International License.

©2019 Facebook
2019
©1969 source unknown
1969 live video 380,000 km
©2020 Google Maps
2019 photo 11 km

We are facing an innovation problem
and it pertains to personal data.

Let’s look for answers to these questions:

Web Fundamentals
Re-decentralizing the Web

Web Fundamentals
Re-decentralizing the Web

The history of computing
started out centralized.

Personal computing decentralized
computational power.

Even when the Internet became popular,
data and CPU remained decentralized.

The software-as-a-service model brought
storage and processing to the cloud.

The pendulum of (de-)centralization
is driven by more than just technology.

Web Fundamentals
Re-decentralizing the Web

Decentralization was an assumption
when the Web was designed.

The Web’s novelty was universality.

The first threat to universality
were the browser wars of the 1990s.

This battle was replaced by another:
the search engine wars of the 2000s.

This battle was also replaced by another:
the platform wars of the 2010s.

Our data has become centralized
in a handful of Web platforms.

Within the walled gardens of social media,
you have to move either data or people.

© David Simonds

In 2017, Tim Berners-Lee listed
three challenges for the Web.

All three indicate a loss of control/agency.

Web Fundamentals
Re-decentralizing the Web

Tim Berners-Lee is spearheading Solid
as an ecosystem to take back control.

Solid aims to restore choice
by separating data from apps.

Every piece of data created by a person
or about them, is stored in a data pod.

Apps and services appear similarly,
but they blend data from many sources.

A person can grant apps and people access
to very specific parts of their data.

Separating app and storage competition
creates better offerings for all parties.

By abandoning data harvesting,
we restore permissionless innovation.

Solid is not a platform to replace others,
but a way of building for the Web.

Web Fundamentals
Re-decentralizing the Web

A Solid server acts as a data pod
that stores and guards your data.

A data pod can contain any data
you create or need online.

Solid clients are browser or native apps
that read from or write to your data pod.

Any app you can envision,
you can build with Solid.

Client–server communication is governed
by the Solid specifications.

Several open-source implementations
of servers, apps, and libraries exist.

Interoperability challenges in Solid
are solved through Linked Data in RDF.

With JSON-LD, every piece of data
can link to any other piece of data.

{
  "@context":  "https://www.w3.org/ns/activitystreams",
  "id":        "#ruben-likes-ugent",
  "type":      "Like",
  "actor":     "https://ruben.verborgh.org/profile/#me",
  "object":    "https://www.ugent.be/#this",
  "published": "2019-04-25T08:00:00Z"
}

Data shapes and their semantics
enable layered compatibility.

{
  "@context":  "https://www.w3.org/ns/activitystreams",
  "id":        "#ruben-likes-ugent",
  "type":      "Like",
  "actor":     "https://ruben.verborgh.org/profile/#me",
  "object":    "https://www.ugent.be/#this",
  "published": "2019-04-25T08:00:00Z"
}

Different source data
can be concatenated.

{
  "@context":  "https://www.w3.org/ns/activitystreams",
  "@graph": [{
    "type":      "Like",
    "actor":     "https://ruben.verborgh.org/profile/#me",
    "object":    "https://www.ugent.be/#this",
    "published": "2019-04-25T08:00:00Z"
  },{
    "type":      "Like",
    "actor":     "https://example.org/people/silvia#me",
    "object":    "https://www.ugent.be/#this",
    "published": "2019-04-25T08:05:00Z"
  }]
}

Web Fundamentals
Re-decentralizing the Web

Simple tasks should be simple,
complex tasks should be manageable.

People think RDF is a pain
because it is complicated.
The truth is even worse.

RDF is painfully simplistic,
but it allows you to work with real-world data
and problems that are horribly complicated.

Dan Brickley & Libby Miller

Decentralized apps have many back-ends
that need to work with many apps.

Decentralization needs replication
to achieve the expected performance.

Current networks are centered
around the aggregator.

We need to create network flows
to and from the aggregator.

The individual network nodes
need to become the source of truth.

Aggregators need to become part
of a larger network.

Aggregators serve as a crucial
but transparent layer in the network.

Aggregators’ main responsibility becomes
fostering a network between nodes.

The Paradox of Freedom:
you can only be free if you follow rules.

Web Fundamentals
Re-decentralizing the Web

Solid apps conceptually query: read/write
data in multiple documents and pods.

Web APIs exist to provide access
to remote data or functionality.

  1. action-oriented APIs
    • RPC
    • SOAP
    • XML
  2. document-oriented APIs
    • REST APIs
    • LDP
  3. graph-oriented APIs
    • SPARQL
    • GraphQL

Graph APIs are just a specific kind of document APIs.

We need to design, in some way,
read–write access to a knowledge graph.

[a browser app needs access to knowledge]

The graph is too big for any single place,
so apps reconstruct the whole via parts.

[apps operate parts of the knowledge graph]

When knowledge fits in a single source,
we can place an API in front of it.

[accessing knowledge hosted on a single server]

Abstract knowledge needs to be exposed
through concrete documents/resources.

[accessing knowledge through a single JSON API]

A GraphQL API combines data from across
multiple resources of the “main” API.

[GraphQL APIs can access multiple conceptual resources]

Let’s revisit API design for cases where
knowledge cannot fit in one place.

[an application needs to access a knowledge graph that is distributed across multiple servers]

Each data pod exposes its part
as RDF through a Web API.

[each server exposes an RDF API]

Different APIs for RDF
have different characteristics.

[RDF can be exposed through different APIs]

It quickly becomes unfeasible for apps
to deal with all possible API combinations.

[each server might expose the same knowledge through multiple APIs]

A GraphQL Web API is not possible here,
since there is no server to attach it to.

[we cannot attach a GraphQL API to any single server when the data resides in multiple servers]

The app can still be written with GraphQL:
a library translates it into HTTP requests.

[a client-side library translates GraphQL queries from the app into HTTP requests for different APIs and servers]

Solid technology marks a transition
from API integration to data integration.

Web Fundamentals
Re-decentralizing the Web

The Web as I envisaged it,
we have not seen it yet.

The future is still so much bigger
than the past.

Tim Berners-Lee