Small Grant - Riter
Introduction
Project Name: Riter — Zero-Knowledge S3 Gateway for Decentralized Storage
Name of the organization or individual submitting the proposal: Abuo Favour Opiah
Systems architect and full-stack developer specializing in decentralized infrastructure, privacy-critical systems, and end-to-end encrypted storage. Core expertise spans React, Node.js, cryptographic protocols, and user-owned data architecture. Currently engineering onsafile.com, a production medical records platform built on Sia’s indexd, demonstrating how encryption and deterministic key derivation can preserve privacy while maintaining searchability. Passionate about making encrypted, decentralized storage accessible to developers without requiring cryptographic expertise or infrastructure overhead.
GitHub: yucky-dev
Describe your project.
Riter is a zero-knowledge S3-compatible gateway paired with a client-side encryption library that enables privacy-preserving decentralized storage without requiring users to run renterd infrastructure.
The system has two components:
Client-Side Component (JavaScript/Python SDK):
Developers integrate Riter’s SDK into their applications. Before any data leaves the client, the SDK:
- Encrypts file content with AES-256-GCM using a deterministic key derived client-side
- Generates cryptographic blind indexes from user-defined metadata (filenames, tags, categories)
- Returns encrypted blob + indexed metadata headers ready for S3 upload
- The client retains all key material; no secrets ever transit to the gateway
Gateway Component (S3-Compatible Backend):
Riter acts as a stateless S3 endpoint that:
- Accepts encrypted blobs via standard S3 PUT/GET/DELETE/LIST operations
- Stores encrypted files on Sia via renterd
- Indexes blind metadata (hashed, non-reversible) via X-Amz-Meta headers
- Uses indexd to maintain searchable metadata without ever decrypting content
- Returns encrypted blobs on retrieval; clients decrypt locally
- Maintains zero knowledge of plaintext, keys, or file semantics
The result: S3-compatible APIs meet end-to-end encryption. Developers use familiar tooling (boto3, AWS SDK, rclone). Sia becomes a private, user-owned blob store. indexd enables efficient retrieval without semantic visibility.
The MVP delivers a production-ready stack with client SDK (JavaScript + Python), gateway server with blind indexing, deterministic key derivation reference implementation, Prometheus observability, complete deployment guides, and integration examples. All code ships MIT-licensed and open-source.
How does the projected outcome serve the Foundation’s mission of user-owned data? What problem does your project solve?
The Sia Foundation’s mission is user-owned data. But “user ownership” has a hidden cost: operational complexity. Users must run renterd, manage contracts, handle redundancy, and maintain infrastructure. This excludes most developers.
The privacy problem is worse. Existing S3-compatible solutions (hosted gateways, managed services) require users to trust the gateway provider with plaintext data or encryption keys. This is not user ownership; this is delegated trust.
Riter solves both problems simultaneously:
Privacy Without Infrastructure Overhead
Encryption happens client-side before any data leaves the developer’s application. The gateway never sees plaintext, never holds keys, never understands file semantics. Users own their encryption material entirely. This is true user ownership of data.
Searchability Without Semantic Visibility
Traditional encrypted storage sacrifices discoverability: you can store securely, but you cannot search efficiently without downloading and decrypting everything. Riter solves this through blind indexing. Clients derive deterministic hashes from metadata (filenames, tags, categories) and send these hashes as X-Amz-Meta headers. indexd indexes the hashes, not the plaintext. Retrieval is efficient; privacy is preserved.
Adoption Without Compromise
Developers use standard S3 APIs. No code rewrites. No cryptographic expertise required. Riter’s SDK handles encryption transparently. This removes the false choice between “easy to use” and “private.” Developers can have both.
The market need is immediate and real. Developers want decentralized storage but not infrastructure complexity. Enterprises want encryption but not lock-in to custodial services. Riter bridges this gap by making privacy-preserving, user-owned decentralized storage as simple as configuring an S3 endpoint.
Are you a resident of any jurisdiction on that list? No
Will your payment bank account be located in any jurisdiction on that list? No
Grant Specifics
Amount of money requested and justification with a reasonable breakdown of expenses:
Total requested: $10,000 for a 3-month MVP development period (May – July 2026).
| Line Item | Detail | Amount |
|---|---|---|
| Client-side encryption SDK | AES-256-GCM encryption, deterministic key derivation, blind index generation (JavaScript + Python) | $4,000 |
| Zero-knowledge gateway | S3 API server, blind metadata indexing, renterd integration, indexd coordination | $3,500 |
| Blind indexing implementation | Hashed metadata schema, X-Amz-Meta header extraction, indexd query layer | $1,500 |
| Documentation, testing, security audit | Integration guides, deployment, cryptographic review, test suite | $1,000 |
| TOTAL | ~200 developer hours | $10,000 |
Grant payments will be received monthly in tranches: $3,500 / $3,500 / $3,000 USD, contingent on milestone completion and security review sign-off.
Sia storage costs excluded: Riter is architecturally designed to defer all storage operations to renterd. No Sia storage is consumed by the gateway itself. Users provision and fund their own renterd instances. The grant funds engineering time only.
What is the high-level architecture overview for the grant? What security best practices are you following?
Riter is a four-layer zero-knowledge system. Encryption happens client-side; the gateway operates on encrypted blobs with indexed metadata only.
Layer 1: Client-Side Encryption (SDK)
The Riter SDK runs in the developer’s application environment (Node.js, browser, Python CLI). Before any data is sent:
-
Key Derivation: User provides a master secret (passphrase, seed, or existing key). SDK derives encryption keys deterministically using PBKDF2 + SHA-256. Same master secret always produces the same keys (enabling recovery and multi-device access).
-
Content Encryption: File content is encrypted with AES-256-GCM. A random nonce is generated per file; the nonce is prepended to the ciphertext. The result is a sealed blob.
-
Metadata Hashing: User-defined metadata (filename, category, tags, timestamps) is hashed using BLAKE2b. These hashes are blind indexes — they are non-reversible but deterministic. The same metadata always produces the same hash.
-
Upload Preparation: The SDK returns:
- Encrypted blob (ready for S3 PUT)
- X-Amz-Meta headers containing blind index hashes
- Client retains all key material; nothing sensitive leaves the client
// Pseudocode
const masterSecret = "user-provided-passphrase"
const encryptionKey = PBKDF2(masterSecret, salt, iterations)
const ciphertext = AES256GCM.encrypt(fileContent, encryptionKey)
const blindIndex = BLAKE2b(filename + category)
// Upload
PUT /bucket/key
X-Amz-Meta-BlindIndex: <blindIndex>
X-Amz-Meta-Nonce: <nonce>
[ciphertext]
The gateway never sees masterSecret, encryptionKey, or plaintext filename. It only sees ciphertext and hashes.
Layer 2: Gateway Server (S3-Compatible)
Riter exposes a standard S3 endpoint that accepts PUT, GET, DELETE, LIST from any S3 client. The gateway:
-
Receives encrypted upload:
- Extracts X-Amz-Meta headers (blind indexes + nonce)
- Streams ciphertext directly to renterd (no buffering)
- Stores metadata (hashes, size, timestamp) locally for indexd coordination
-
Indexes via blind metadata:
- Sends blind index hashes + metadata to indexd
- indexd creates a searchable index using the hashes, not plaintext
- Users can query by blind index without the gateway knowing the original metadata
-
Retrieves encrypted content:
- Client queries gateway with a blind index or object ID
- Gateway returns ciphertext + nonce + associated metadata hashes
- Client decrypts locally using their derived key
-
Zero-knowledge guarantee:
- Gateway stores no plaintext
- Gateway stores no encryption keys
- Gateway stores no unencrypted metadata
- All operations are stateless except for indexd coordination
Layer 3: Blind Indexing via X-Amz-Meta Headers
Standard S3 supports custom metadata via X-Amz-Meta-* headers. Riter leverages this:
X-Amz-Meta-BlindIndex-Filename: <BLAKE2b(filename)>
X-Amz-Meta-BlindIndex-Category: <BLAKE2b(category)>
X-Amz-Meta-BlindIndex-Tag1: <BLAKE2b(tag)>
X-Amz-Meta-Nonce: <AES-GCM nonce, cleartext>
X-Amz-Meta-Timestamp: <ISO8601, cleartext>
indexd is configured to index these specific headers. Because the values are hashes:
- They are searchable (same input always produces same hash)
- They are non-reversible (cannot derive original metadata from hash)
- They enable efficient retrieval without decryption
- Privacy is maintained; queryability is preserved
Layer 4: Storage & Retrieval (renterd + indexd)
renterd handles all Sia network operations (contracts, redundancy, retrieval). indexd maintains a searchable index of blind metadata. Neither system ever has access to plaintext or encryption keys.
Security Practices:
- End-to-End Encryption: AES-256-GCM with per-file random nonces. Industry standard, proven security.
- Deterministic Key Derivation: PBKDF2 with 100,000+ iterations. Enables client-side key recovery without key servers.
- Blind Indexing: BLAKE2b hashing of metadata. One-way function; original metadata cannot be recovered from indexes.
- Zero-Knowledge Gateway: Riter stores no plaintext, no keys, no unencrypted metadata. All data at rest is encrypted.
- Nonce Transparency: AES-GCM nonces are stored cleartext in metadata (required for decryption). This is cryptographically sound; nonces are not secrets.
- Transport Security: All deployments enforce HTTPS via reverse proxy (nginx/Caddy).
- Code Review: All cryptographic code reviewed against NIST guidelines and Sia Foundation Development Guide prior to each milestone submission.
Goals and timeline:
MONTH 1
Client SDK & Cryptographic Foundation
Implement deterministic key derivation (PBKDF2 + SHA-256) in JavaScript and Python
Implement AES-256-GCM encryption with per-file random nonces
Implement BLAKE2b blind index generation for metadata
Build SDK wrapper for seamless encryption-before-upload workflow
Write integration examples (boto3 SDK wrapper, Node.js example, Python CLI)
Unit tests for all cryptographic operations
Deliverable: Production-ready client SDK (JS + Python) with full test coverage
MONTH 2
Zero-Knowledge Gateway & Indexing
Implement S3-compatible gateway server (PUT, GET, DELETE, LIST)
Implement X-Amz-Meta header extraction and blind index coordination
Integrate with renterd for encrypted blob storage
Integrate with indexd for blind metadata indexing
Build /health and /metrics endpoints (Prometheus-compatible)
Docker Compose deployment (gateway + renterd + indexd)
Integration tests against live renterd + indexd stack
Deliverable: Production-ready gateway with blind indexing and observability
MONTH 3
Documentation, Security, and Release
Complete security audit of cryptographic implementations
Full deployment guide (self-hosting, Docker, reverse proxy configuration)
Client integration guide for developers (how to use SDK in applications)
Blind indexing best practices documentation
Public GitHub repository release under MIT license
Final progress report and milestone sign-off
Deliverable: Production-grade open-source release with full documentation
Who is the target user for your project?
Riter serves three critical user cohorts:
| Segment | Why They Adopt | Use Case |
|---|---|---|
| Privacy-First Developers | Existing applications (Node.js, Python, Go backends) that need encrypted decentralized storage without infrastructure complexity. Want S3 compatibility but cannot accept plaintext data on any backend. | Backend storage for healthcare, fintech, legal, and compliance-critical applications |
| Self-Hosters & Privacy Advocates | Individual users and small teams who want to store sensitive data (documents, photos, archives) on decentralized infrastructure without trusting any service provider. Do not want to run renterd; want encryption to be automatic. | Personal encrypted storage, family photo archives, document vaults, cryptocurrency custody records |
| Sia Ecosystem Builders | Current and prospective Sia ecosystem projects that need privacy-preserving storage but are blocked by “encryption or searchability” false choice. Riter enables both simultaneously. | Grant applicants, ecosystem tools, decentralized applications |
| Enterprise Compliance | Mid-market teams with encryption mandates (HIPAA, GDPR, SOC 2) who want decentralized infrastructure but require audit trails and deterministic key recovery. Riter provides encrypted storage + verifiable key derivation. | Healthcare, fintech, legal document management, enterprise backup |
What are your plans for this project following the grant?
Riter Phase 1 (MVP) establishes the core encryption + gateway foundation. Subsequent phases extend ecosystem reach and operational maturity.
Phase 2 — Advanced Encryption & Key Management
Hardware security module (HSM) integration for key material in enterprise deployments
Shamir secret sharing (splitting master secrets across multiple devices or custodians)
Time-locked encryption (data becomes decryptable only after a specified block height or timestamp)
Multi-user encryption (shared encrypted buckets with independent key material per user)
This enables enterprise use cases: custody, legal holds, multi-party access control.
Phase 3 — Ecosystem Integration & Compliance
Audit log integration (immutable proof of who accessed what, when, encrypted on Sia)
FIPS 140-2 compliance documentation
Integration with Sia ecosystem directory
Client library SDKs for additional languages (Go, Rust, C#)
Community contribution guidelines and developer onboarding
Phase 4 — Advanced Indexing & Discovery
Order-preserving encryption (enables range queries on numeric metadata)
Searchable encryption (enables keyword search without decryption)
Homomorphic encryption integration (computation on encrypted data without decryption)
These are forward-looking; Phase 1 proves the core viability.
Sustainability Model:
The open-source core (SDK, gateway, indexing layer, deployment guides) remains MIT-licensed permanently. Community contributions keep the project alive independent of commercial outcomes. The grant period establishes the foundation; post-grant adoption and ecosystem integration drive long-term viability. Because Riter incurs zero infrastructure costs in the self-hosted model, the project is sustainable even at zero commercial revenue during the open-source phase.
Potential risks that will affect the outcome of the project:
- Cryptographic implementation correctness
Incorrect encryption or key derivation implementation could compromise user privacy.
Mitigation: All cryptographic code uses established libraries (libsodium, cryptography.io, TweetNaCl). No custom crypto. Code reviewed against NIST guidelines. External security audit before Phase 1 release. Ongoing review by Sia Foundation Development Guide.
- Blind indexing hash collisions or reversibility
If blind indexes are not one-way enough, metadata could be recovered.
Mitigation: Use BLAKE2b (cryptographic hash, no known preimage attacks). Include random salt in hash input (prevents rainbow table attacks). Document hash collision risk tolerance in deployment guide. Explicitly scope advanced indexing (order-preserving, homomorphic) to Phase 3.
- renterd API changes during development
renterd’s API surface may change as Sia Foundation refines the interface.
Mitigation: Pin to specific renterd release. Abstract storage layer behind clean interface. Monitor SiaFoundation/renterd changelog. Maintain compatibility layer.
- Nonce reuse vulnerability
If AES-GCM nonces are reused, encryption security is compromised.
Mitigation: Generate per-file random nonces. Store nonce with ciphertext (nonces are not secrets in AES-GCM). Add assertion checks in SDK to prevent nonce reuse. Document nonce handling in security guide.
- Scope creep into advanced encryption schemes
Advanced indexing (order-preserving, searchable, homomorphic) is tempting but out of scope for MVP.
Mitigation: Phase 1 scope is explicitly limited to AES-256-GCM + BLAKE2b blind indexing. All advanced schemes are Phase 2+. No expansion within grant period.
Development Information
Will all of your project’s code be open-source?
Yes. All code produced under this grant will be released under the MIT license from day one. No closed-source components. No proprietary dependencies. Complete transparency. The cryptographic implementations will be auditable and reviewable by the security community.
Leave a link where code will be accessible for review.
Contribute to yucky-dev/Riter development by creating an account on GitHub.
Do you agree to submit monthly progress reports?
Yes. Monthly progress reports will be submitted to the Sia Foundation forum at the end of each month, detailing milestone completion, cryptographic security status, technical challenges, and next-month priorities.
Contact
Email: [email protected]