Hi all, here’s a first stab at the Introduction text so it speaks a bit more to everyday Web developers. It’s just a draft-shaped thought starter, not gospel; please poke holes, rewrite, or ignore entirely as you see fit!
2 Introduction
The Linked Web Storage (LWS) Protocol is a standardized set of interoperable, HTTP-based interactions that empowers any conforming application to read, write, and manage data residing outside the application’s own infrastructure. Its fundamental purpose is to restore an essential architectural principle of the Web: users control where their data is stored, while applications come and go, without breaking links, permissions, or provenance.
Today, most Web applications entangle storage, identity, access control, and business logic behind a single origin. Migrating to a new provider or adopting a new application therefore often means abandoning existing data. LWS breaks that coupling. By standardising a small, resource-oriented contract, it enables:
- Portable personal and enterprise data vaults that can move between providers, clouds, or on-premise deployments.
- Application innovation decoupled from storage choices.
- Consistent security semantics across heterogeneous back-ends.
- A genuinely linkable data space, because every resource continues to be identified by an ordinary URI.
This specification is primarily intended for developers, architects, and implementers building Web applications and data storage solutions who seek to leverage truly decentralized and user-centric data management.
2.1 Design philosophy
- Leverage, don’t reinvent. LWS reuses established Web building blocks—URI addressing, HTTP transfer semantics, RDF vocabularies—rather than introducing a parallel stack. Experience gained with Solid Protocol, Fedora API, WebDAV, ActivityPub, and modern object-storage APIs informed the design, but the specification remains deliberately minimal and composable, not monolithic.
- Layered extensibility. Capabilities such as real-time notifications, delegated authorization, or content-profile negotiation are specified as optional layers (see § 11 Unstable Features). The core stays small and future-proof.
- Security & privacy by default. The protocol assumes untrusted networks; authentication and authorization are required for any non-public resource, and all normative requirements are transport-agnostic but compatible with TLS-based deployments.
- Interoperability over optimisation. Where trade-offs arise, the Working Group prioritises a uniform client/server contract over provider-specific performance hints.
2.2 Goals and non-goals
| Goals |
Non-goals |
| Interoperability across vendors and platforms |
Mandating a single identity system or token format |
| User-centred data portability |
Defining a storage engine, database schema, or query language |
| End-to-end security and privacy controls |
Specifying user-interface behaviour |
| Extensible feature set for advanced use cases |
Baking experimental features into the core |
2.3 Conformance overview
The specification defines two conformance classes:
- LWS REST Server – an HTTP origin that satisfies every normative requirement labelled “server”.
- LWS REST Client – an HTTP client that satisfies every normative requirement labelled “client”.
Unless a requirement states otherwise, it applies to both classes.
2.4 Document roadmap
| Section |
Content |
| § 3 |
Terminology |
| § 4–6 |
Discovery, authentication, and authorization flows |
| § 7 |
Canonical create/read/update/delete operations and generic responses |
| § 8–10 |
Logical organisation, REST binding, and resource identification rules |
| § 11 |
Features under incubation (profile negotiation, notifications, inbox) |
| § 12–14 |
Portability, security, and privacy considerations |
Readers implementing a client may start with § 7, referring back to § 4–6 for security prerequisites. Storage providers should pay particular attention to the conformance clauses in § 2.3 and the normative statements scattered through § 4–10.
2.5 Illustrative Exchange (non-normative)
To provide a concrete example of LWS in action, consider a simple resource retrieval:
GET /photos/2025/06/puppy.jpg HTTP/1.1
Host: storage.example
Accept: image/jpeg
HTTP/1.1 200 OK
Content-Type: image/jpeg
Last-Modified: Fri, 06 Jun 2025 13:37:42 GMT
This pattern is identical for create, update, and delete operations, which are detailed in § 7. This exchange is provided for illustration and is non-normative.
Hi all, here’s a first stab at the Introduction text so it speaks a bit more to everyday Web developers. It’s just a draft-shaped thought starter, not gospel; please poke holes, rewrite, or ignore entirely as you see fit!
2 Introduction
The Linked Web Storage (LWS) Protocol is a standardized set of interoperable, HTTP-based interactions that empowers any conforming application to read, write, and manage data residing outside the application’s own infrastructure. Its fundamental purpose is to restore an essential architectural principle of the Web: users control where their data is stored, while applications come and go, without breaking links, permissions, or provenance.
Today, most Web applications entangle storage, identity, access control, and business logic behind a single origin. Migrating to a new provider or adopting a new application therefore often means abandoning existing data. LWS breaks that coupling. By standardising a small, resource-oriented contract, it enables:
This specification is primarily intended for developers, architects, and implementers building Web applications and data storage solutions who seek to leverage truly decentralized and user-centric data management.
2.1 Design philosophy
2.2 Goals and non-goals
2.3 Conformance overview
The specification defines two conformance classes:
Unless a requirement states otherwise, it applies to both classes.
2.4 Document roadmap
Readers implementing a client may start with § 7, referring back to § 4–6 for security prerequisites. Storage providers should pay particular attention to the conformance clauses in § 2.3 and the normative statements scattered through § 4–10.
2.5 Illustrative Exchange (non-normative)
To provide a concrete example of LWS in action, consider a simple resource retrieval:
This pattern is identical for create, update, and delete operations, which are detailed in § 7. This exchange is provided for illustration and is non-normative.