Solid Lite

1. Introduction

Solid Lite is a minimal protocol for building decentralized web applications based on Social Linked Data principles. It prioritizes simplicity and composability—start with a basic server you can build in 10 minutes, then add features via SLIPs as needed.

2. HTTP Protocol

2.1 Server Requirements

• Servers MUST conform to HTTP/1.1 Message Syntax and Routing (RFC7230)
• Servers MUST conform to HTTP/1.1 Conditional Requests (RFC7232)
• Servers SHOULD support HTTP/1.1 Caching (RFC7234)

2.2 Client Requirements

• Clients MUST conform to HTTP/1.1 Message Syntax and Routing
• Clients MAY support Conditional Requests and Caching

3. Resources

3.1 URIs

Resources are identified by URIs conforming to RFC3987. URIs provide consistent identification across the Solid Lite ecosystem.

3.2 CRUD Operations

Servers MUST support GET, HEAD, OPTIONS, PUT, and DELETE methods.

4. CORS

Servers MUST include CORS headers to allow browser-based applications to access resources across origins:

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

5. Identity

Identity in Solid Lite can be established via:

• WebID — A URI that returns machine-readable profile data (JSON-LD)
• did:nostr — A DID using a Nostr public key: did:nostr:<64-char-hex-pubkey>

The profile SHOULD live at the root of storage for human-friendly URLs. See did:nostr spec for details.

6. Authentication

Authentication verifies identity. Solid Lite defines a layered approach—choose the level appropriate for your use case:

6.1 Null Auth (SLIP-80)

Testing only. Everyone can read and write. MUST NOT be used in production.

6.2 Bearer Auth (SLIP-81)

Single-user mode. A shared API key sent via header:

Authorization: Bearer <SOLID_API_KEY>

Server returns 401 if key is missing or invalid.

6.3 Schnorr Auth (SLIP-82)

Multi-user mode. Uses NIP-98 HTTP authentication with Schnorr signatures:

Authorization: Nostr <base64-encoded-signed-event>

The signed event (kind 27235) contains the URL and HTTP method, verified against the user's Nostr public key. No certificates or passwords required.

7. Authorization

The default authorization policy (SLIP-90):

• Everyone can read
• Only the owner can write

Access denial returns:

• 401 Unauthorized — Identity unknown
• 403 Forbidden — Identity known but access denied

8. Data Format

Resources use JSON-LD 1.1 for structured, linked data. Example profile:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://w3id.org/webid"
  ],
  "@id": "#me",
  "type": "Person",
  "name": "Alyssa P. Hacker",
  "preferredUsername": "alyssa",
  "summary": "Lisp enthusiast",
  "storage": "/",
  "nostr": "did:nostr:abcd0123..."
}

9. Extending Solid Lite

Solid Lite is extended via SLIPs (Solid Lite Implementation Proposals). Each SLIP adds a composable feature:

• SLIP 1-999 — Core protocol extensions
• SLIP 1000-9999 — Related projects
• SLIP 10000+ — Community extensions

Combine SLIPs to build the server you need—from a minimal 10-minute implementation to a full-featured system like JSS.