Version 0.0.1 draft author:melvincarvalho

Solid-Lite Protocol Overview

1. Introduction

Building a decentralized web grounded in Social Linked Data principles aims to shift the paradigm of data ownership and collaborative innovation. For this ecosystem to flourish, it is crucial to develop a protocol that not only aligns with the core values of developers but also simplifies adoption and integration into existing workflows

Presenting Solid-Lite. Grounded in the tenets of Social Linked Data, this protocol offers a balance of elegance and potency. Conceived for expansive adaptability, Solid-Lite caters to a myriad of applications, from safeguarding personal records to powering intricate collaborative platforms. Its design aims to make the complexities of decentralized data accessible, providing tools that empower developers to craft solutions which prioritize user autonomy and innovation.

2. Hypertext Transfer Protocol (HTTP)

2.1 HTTP Server

2.2 HTTP Client

3. Uniform Resource Identifier (URI)

Clients and servers SHOULD conform to the Uniform Resource Identifier (URI) and Internationalized Resource Identifier (IRI) specifications to ensure consistent identification and referencing of resources. The URI provides a simple and extensible means for identifying a resource, while the IRI extends the URI to allow the use of characters from the Universal Character Set (UCS) [RFC3987]. This adherence promotes interoperability and a consistent experience across the Solid-Lite ecosystem.

4. Resources

5. Reading and Writing Resources

5.1 Reading

5.2 Writing

6. Cross-Origin Resource Sharing (CORS)

Solid applications seamlessly integrate data from disparate sources. However, web browsers, by default, adhere to the Same-Origin Policy, restricting requests to different domains for security reasons. This precaution, vital for preventing malicious data retrieval, can inadvertently restrict legitimate Solid applications. The following headers on the server will allow cross origins requests.

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,HEAD,OPTIONS,PUT,DELETE,POST
Access-Control-Allow-Headers: Content-Type

7. Identity

8. Authentication

9. Authorization

All resources should be represented in a clear and structured JSON format. JSON provides an easy-to-understand format that can be quickly parsed and read by both humans and machines. This is based on JSON-LD 1.1. A lite version compatible with ActivityPub may be developed in future, but for now a simple profile, located at the base of storage could be as described below.

Example of a Resource JSON, loosely combines the W3C WebID Community Group Draft, Solid lite WebID definitions, Schema.org and ActivityPub:

  "@context": [
  "@id": "#me",
  "type": "Person",
  "mainEntityOfPage": "",
  "name": "Alyssa P. Hacker",
  "preferredUsername": "alyssa",
  "summary": "Lisp enthusiast hailing from MIT",
  "inbox": "https://social.example/alyssa/inbox/",
  "outbox": "https://social.example/alyssa/outbox/",
  "followers": "https://social.example/alyssa/followers/",
  "following": "https://social.example/alyssa/following/",
  "liked": "https://social.example/alyssa/liked/",
  "img": "avatar.png",
  "knows": "http://alice.example/#me",
  "storage": "/",
  "nostr": "nostr:pubkey:abcd0123456789"

In this example:

Using JSON with links allows for a clear structure while also providing a way to navigate between related resources in the Solid-Lite ecosystem.

Appendix B: CRUD Operations Summary with HTTP Responses:

Extending Solid Lite

Solid Lite is extended via Solid Lite Implementations Propsosals (SLIPs)