Skip to content

LWS Protocol Mode Support (Draft/Future) #87

@melvincarvalho

Description

@melvincarvalho

Summary

Add optional --lws-mode flag to support W3C Linked Web Storage (LWS) protocol semantics alongside the current Solid Protocol/LDP implementation.

Status: 📋 Draft/Exploratory - LWS spec is in early stages (PR #37 just merged Jan 2026)
Priority: Low (monitor ecosystem first)
Related: w3c/lws-protocol#37

Background

What is LWS?

The W3C Linked Web Storage protocol suite defines CRUD operations with different conventions than Solid/LDP:

  • POST for creation (server-assigned URIs with Slug hints)
  • PUT for updates only (not creation)
  • Link headers for metadata (removes slash semantics for containers)
  • Mandatory ETag concurrency control
  • JSON Merge Patch for metadata updates (via separate linkset resources)

Current State: LDP/Solid

JSS implements Solid Protocol conventions based on LDP:

  • ✅ PUT creates or updates resources
  • ✅ Trailing slash indicates containers
  • ✅ POST to containers with Slug support
  • ✅ ETag-based If-Match/If-None-Match
  • ✅ N3 Patch and SPARQL Update for RDF modifications

Key Differences

Aspect Solid/LDP (Current) LWS Protocol (Proposed)
Resource Creation PUT or POST POST only
PUT Semantics Create or update Update only (404 if not exists)
Container Detection Trailing slash (/alice/) Link header: rel="type"
Metadata Updates N3 Patch, SPARQL Update JSON Merge Patch on linkset
Concurrency Control Optional ETag Mandatory ETag
Slash Semantics Standard (containers end with /) Removed (header-based only)

Proposed Implementation

Configuration Flag

# LWS mode
jss start --lws-mode

# Solid/LDP mode (default, current behavior)
jss start

Code Changes Required

1. PUT Handler Split (src/handlers/resource.js)

Effort: 3 hours

export async function handlePut(request, reply) {
  const lwsMode = request.lwsMode || false;
  
  if (lwsMode) {
    // LWS: PUT only for updates
    const stats = await storage.stat(storagePath);
    if (\!stats) {
      return reply.code(404).send({
        error: 'Use POST to create resources in LWS mode'
      });
    }
  } else {
    // LDP: PUT creates or updates (current)
    const existed = stats \!== null;
  }
}

2. Container Detection Toggle (src/utils/url.js)

Effort: 4 hours

export function isContainer(urlPath, request) {
  if (request?.lwsMode) {
    // LWS: Check Link header for Container type
    const linkHeader = request?.headers?.link || '';
    return linkHeader.includes('ldp#Container');
  } else {
    // LDP: Trailing slash
    return urlPath.endsWith('/');
  }
}

Files affected: src/utils/url.js, src/handlers/resource.js, src/handlers/container.js, src/ldp/headers.js

3. Linkset Metadata Endpoints (new)

Effort: 8 hours

New file: src/handlers/linkset.js

  • GET /resource;linkset - Return metadata as JSON
  • PATCH /resource;linkset - JSON Merge Patch for user-managed metadata

4. Config Infrastructure

Effort: 2 hours

Add --lws-mode flag to CLI and config system.

5. Testing Matrix

Effort: 12 hours

Duplicate all CRUD tests for LWS mode (223 tests × 2 modes = 446 tests total).

Complexity Assessment

Component Effort Files Risk
Config flag 2h 3 Low
PUT behavior 3h 1 Medium
Container detection 4h 4 High
Linkset endpoints 8h 1 new Medium
Testing 12h All High
Documentation 2h 2 Low
Total ~31 hours ~15 High

Trade-offs

Pros ✅

  • Future-proof if LWS gains adoption
  • Universal server supporting both protocols
  • Research value for evaluating LWS concepts
  • Subdomain isolation - run Solid + LWS pods on same server

Cons ❌

  • Test burden - doubles maintenance (446 tests)
  • Code complexity - branching logic throughout
  • Premature - LWS ecosystem is tiny (no known apps)
  • Bug risk - less-used mode more error-prone
  • Documentation split - user confusion

Decision Criteria

Do NOT implement until:

  • ✅ At least 3 other servers implement LWS
  • ✅ At least 5 client apps request LWS support
  • ✅ W3C Solid CG shows interest in LWS alignment
  • ✅ LWS spec reaches Candidate Recommendation status

Monitor These Signals

  • Number of servers implementing LWS
  • Client apps using LWS endpoints
  • W3C Solid CG discussions about LWS
  • LWS spec maturity (currently early draft)

Alternative: Plugin Architecture

Instead of core branching, design protocol adapters:

jss start --protocol=lws      # LWS semantics
jss start --protocol=solid    # LDP semantics (default)
jss start --protocol=s3       # Future: S3-compatible

Benefits:

  • Clean core implementation
  • Community experimentation
  • No test matrix explosion

Current LWS Ecosystem (Jan 2026)

  • Servers: Unknown
  • Clients: Likely zero
  • Spec status: Early draft (PR Login with did:nostr #37 just merged)
  • Community: Small W3C working group

Recommendation

Priority: Low - Monitor but don't implement

Timeline:

  • Now: Capture this analysis
  • Q2 2026: Survey LWS ecosystem adoption
  • Q4 2026: Reassess if signals show traction
  • 2027+: Implement if ecosystem warrants

Keep focus on:

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions