Inconsistent `Swarm-Redundancy-Level` Header Handling Across API Endpoints

[gacevicljubisa]

Summary

The Swarm-Redundancy-Level header is inconsistently handled across API endpoints and internal components. Some handlers respect the user-specified redundancy level while others ignore it and use hardcoded values (PARANOID or DefaultLevel). This creates unpredictable behavior and potential performance issues.

This issue requires input from research and product teams to determine appropriate defaults and whether all operations should respect the header.

Current State Analysis

Handler Behavior

Handler	Endpoint	Default	Respects Header	Issue
bytesUploadHandler	POST /bytes	NONE	✅	None
bzzUploadHandler	POST /bzz	NONE	✅	None
bzzDownloadHandler	GET /bzz/{address}/{path}	PARANOID	❌	loadsave.NewReadonly ignores header
bzzHeadHandler	HEAD /bzz/{address}/{path}	PARANOID	❌	loadsave.NewReadonly ignores header
downloadHandler	GET /bytes/{address}	PARANOID	✅	None

Problem Details

Critical Issues in API Handlers

BZZ Download Handlers (pkg/api/bzz.go)

Location: serveReference() method, line ~409

// BUG: Always uses redundancy.DefaultLevel (PARANOID) instead of rLevel variable
ls := loadsave.NewReadonly(s.storer.Download(cache), s.storer.Cache(), redundancy.DefaultLevel)

The header is parsed but ignored. This affects:

• GET /bzz/{address}/{path} - always uses PARANOID
• HEAD /bzz/{address}/{path} - always uses PARANOID

Hardcoded Redundancy Levels in Other Components

Stewardship Service (pkg/steward/steward.go)

• Line 44: traversal.New(ns.Download(true), joinerPutter, redundancy.DefaultLevel)
• Line 45: traversal.New(&netGetter{r}, joinerPutter, redundancy.DefaultLevel)

Node Bootstrap (pkg/node/bootstrap.go)

• Line 285: loadsave.NewReadonly(st, putter, redundancy.DefaultLevel)

Access Control Handlers (pkg/api/accesscontrol.go)

All access control operations hardcode redundancy.PARANOID:

• actDecryptionHandler (line 129)
• actListGranteesHandler (line 207)
• actEncryptionHandler (line 162)
• actGrantRevokeHandler (lines 347-348)
• actCreateGranteesHandler (lines 501-502)

Pin Operations (pkg/api/pin.go)

• Line 56: traverser := traversal.New(getter, s.storer.Cache(), redundancy.PARANOID)

Performance Impact

Critical Concerns

1. Forced Maximum Redundancy: When hardcoded to PARANOID, operations use the highest redundancy level (16 replicas) regardless of user needs

   • Increases network traffic by up to 16x
   • Increases storage requirements across the network
   • Slows down upload/download operations
   • Wastes node resources and bandwidth

2. No User Control: Users cannot optimize performance for their use case:

   • Cannot use lower redundancy for temporary or non-critical data
   • Cannot balance cost vs. reliability for different content types
   • Cannot reduce resource usage when appropriate

3. Inconsistent Behavior: Different endpoints with different defaults create confusion and make it difficult to predict system behavior

Questions for Research & Product Teams

Research Team:

• Should all operations respect the Swarm-Redundancy-Level header, or are there security/reliability reasons for forcing PARANOID on specific operations (e.g., access control, pinning)?
• What are the recommended default redundancy levels for different operation types?
• Are there minimum redundancy requirements for sensitive operations?

Product Team:

• Should users have full control over redundancy levels for all operations?
• Should different operations have different default redundancy levels, or should there be one global default?
• How should this be communicated in API documentation?
• Are there use cases where forcing PARANOID is desirable?