Large Grant: SiaStream - Developer-First Video Infrastructure on Sia

Grants Rejected
1

Introduction

Project Name: SiaStream

Name of the organization or individual submitting the proposal: Mert Köklü

Describe your project.

Building video infrastructure today means assembling expensive, vendor-locked pipelines across multiple cloud services, or accepting managed platforms that hold plaintext access to all uploaded content. SiaStream provides an alternative: a developer-first video infrastructure platform built natively on Sia. It delivers a complete pipeline for uploading, transcoding, storing, and streaming video content, comparable in developer experience to Mux or Cloudflare Stream, but backed by decentralized, encrypted, contract-enforced storage.

Developers interact with SiaStream through a REST API, a TypeScript client SDK, and a drop-in React player component. Behind these interfaces, the platform handles large file uploads via the TUS protocol, an open standard for reliable, resumable file transfers over HTTP. It performs adaptive bitrate transcoding through FFmpeg, producing multiple quality levels that players switch between based on network conditions. Each output artifact is stored on Sia, with dynamic HLS manifest rewriting and low-latency delivery through a byte-range-aware HTTP gateway with a caching layer. A management Studio provides a web dashboard for uploading, monitoring processing, browsing assets, configuring API keys and webhooks, and previewing playback.

Every video artifact is encrypted client-side by the Sia SDK before leaving the server, then erasure-coded and distributed across independent storage providers so that the original data can be reconstructed from a subset of hosts. The erasure coding parameters are configurable, allowing operators to tune the balance between redundancy and storage cost. The platform treats video as a durable, content-addressed data asset under the developer’s cryptographic control.

A working reference implementation has been developed, validated on the Sia Zen testnet, and is live at https://siastream.com. It is available for reviewer evaluation alongside a video walkthrough of the platform at https://youtu.be/-NnKGXTSVjw.

Who benefits from your project?

Application developers building video-enabled products gain a production-ready API that eliminates months of pipeline engineering. Instead of assembling separate upload, transcoding, storage, and delivery systems, a developer can upload a video, receive a playback URL, and embed the React player, all through a few API calls. Sia’s storage costs are roughly 5–10x lower than AWS S3, making a material difference for video workloads where storage and bandwidth dominate expenses.

The Sia network and its storage providers benefit from sustained, high-volume demand. Video is the largest category of internet traffic, and each video stored on SiaStream generates ongoing storage contracts and bandwidth utilization. A modest platform hosting 10,000 hours of content at three quality tiers would store approximately 36 TB on Sia, directly increasing network utilization and Siacoin demand.

The Sia Foundation gains a high-visibility demonstration that Sia can support bandwidth-intensive, latency-sensitive workloads beyond archival storage, serving as a tangible showcase for the v2 architecture.

Content creators and organizations using applications built on SiaStream inherit Sia’s structural privacy guarantees: all content is encrypted before leaving the server, and storage providers hold only unintelligible ciphertext. This makes SiaStream suitable for use cases requiring censorship resistance, data privacy compliance, or long-term integrity, from creator platforms and educational institutions to journalistic archives and enterprise tooling.

How does the project serve the Foundation’s mission of user-owned data? What problem does your project solve?

This project directly addresses the Grants Committee’s stated interest in funding tools for “sharing/viewing large single files (videos, data sets, high-res photos),” listed as a priority project idea in the April 2026 funding guidelines. It satisfies both required grant themes simultaneously: SiaStream is built with the official Sia SDKs for all storage operations and built on indexd for object tracking, health monitoring, and repair coordination.

Despite proven capability for video streaming, the Sia ecosystem offers zero production-ready video infrastructure. Previous attempts have not delivered a sustainable solution: the original SiaStream was lost with Skynet Labs’ shutdown in 2022, DTube abandoned decentralization entirely in December 2025 due to IPFS storage unreliability, and community proposals like StreamWeave and Sia Live Archive did not reach completion. The gap persists because no project has solved storage, transcoding, delivery, and developer experience together.

SiaStream solves this by providing a complete, abstracted video pipeline where all content is stored on Sia. The SDK encrypts data client-side before upload and distributes encrypted shards across independent providers via erasure coding, so no single entity can access plaintext video. Content ownership remains cryptographically with the application developer, a structural guarantee no centralized platform can offer.

The platform also makes Sia accessible to a broader developer audience. Web developers accustomed to S3 or Cloudflare Stream face a steep learning curve with Sia’s SDK and indexer workflows. SiaStream abstracts this behind standard REST APIs, TUS uploads, and HLS delivery, so every application built on SiaStream becomes an application built on Sia.

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 comprehensive breakdown of expenses:

Total requested: $80,000 USD over 5 months ($16,000/month)

This budget covers a single full-time developer working across the entire stack. The monthly rate reflects the specialized skill set required: concurrent expertise in video engineering, systems programming, full-stack web development, and Sia SDK integration.

Category Monthly Cost 5-Month Total Description
Developer compensation $15,200 $76,000 Full-time development across backend, API, SDK, player, Studio, Sia integration, and documentation
Infrastructure (development) $800 $4,000 Cloud server for development and testing, Sia storage contracts for mainnet operation, domain registration
Total $16,000 $80,000

No marketing, community engagement, or promotional expenses are included.

What is the high-level architecture overview for the grant? What security best practices are you following?

Architecture Overview

SiaStream separates a control plane from a data plane. The control plane handles uploads, transcoding, metadata, API keys, and webhooks. The data plane handles Sia storage, byte-range retrieval, caching, and HLS delivery. The following sections describe each layer of the pipeline from ingestion through delivery.

Ingestion. Clients upload video files through the TUS v1.0.0 resumable upload protocol. TUS guarantees resumability via its offset-tracking mechanism: if a multi-gigabyte upload is interrupted, the client queries the server for the current byte offset and resumes from that point. The embedded TUS server validates the API key, creates an asset record in PostgreSQL, and writes chunks to local staging disk. On completion, it enqueues a transcoding job.

Processing. A BullMQ worker, a Redis-backed job queue for Node.js, executes FFmpeg to produce HTTP Live Streaming output. HLS is the dominant adaptive streaming protocol, and SiaStream packages it in fMP4 containers, a segment-friendly variant of the MP4 format. The pipeline defaults to four renditions at 1080p, 720p, 540p, and 360p, customizable up to 4K. FFmpeg is configured with forced keyframe alignment, disabled scene-change detection, and the independent_segments flag to ensure clean quality switching between renditions.

A key optimization is the use of single_file output mode. Instead of producing hundreds of individual small segment files per rendition, FFmpeg writes each rendition as a single continuous .m4s data file. The HLS playlist then references specific byte ranges within that file rather than separate segment files. This reduces the per-video Sia upload count from hundreds of operations to just N + 2 for an N-rendition ladder: one upload per rendition data file, one packed batch for playlists and thumbnails, and one master manifest upload. Thumbnails are extracted at 25%, 50%, and 75% of duration.

Storage. After transcoding, each output artifact is stored on the Sia network using the official Sia Foundation TypeScript SDKs. In Sia’s architecture, upload and pin are separate operations. Uploading distributes encrypted, erasure-coded shards across storage providers. Pinning then registers the object with indexd so the indexer can monitor its health and trigger automatic repair if redundancy drops. Each stored object is identified by a 32-byte Object ID, a content-addressed hash that uniquely identifies the object on the network.

Large rendition data files are uploaded individually via uploadAndPin, as they naturally fill their own slabs. Sia stores data in 4 MiB sectors grouped into slabs, where total slab size depends on the configured number of data shards. Small artifacts like playlists, thumbnails, and the master manifest are grouped into a single uploadAndPinPacked call, sharing slabs to avoid wasting a full slab per small file. Every returned Object ID is persisted to PostgreSQL, mapping it to the parent asset, rendition, and role.

SiaStream uses two official Sia Foundation TypeScript SDKs. The sia-storage SDK handles control-plane operations such as connecting, pinning, deleting, and sharing. The @siafoundation/sia SDK handles data-plane operations such as uploading, downloading, and packed uploads. Object references are translated between the two SDKs using their built-in seal/open serialization, a round-trip encoding that converts one SDK’s object handle into a portable byte string and back.

Manifest rewriting. HLS players locate video data through playlist files called manifests, which list the available renditions and their segment locations. After artifacts are uploaded, the worker rewrites each rendition playlist to replace local file references with gateway URLs mapped to Sia Object IDs, preserving all byte-range offsets. The master playlist is rewritten to reference each rendition’s Sia object. Rewritten manifests are uploaded to Sia and the master Object ID becomes the asset’s playback entry point.

Delivery. An HTTP gateway bridges standard HLS playback with Sia’s decentralized storage. When a player requests a segment URL, the gateway resolves the Object ID via PostgreSQL, downloads the relevant bytes through the SDK, and serves decrypted content over standard HTTP with proper byte-range support.

An Nginx reverse proxy cache sits in front of the gateway with aggressive time-to-live values for immutable segment data. Cache warming after transcoding prefetches all artifacts through the cache, ensuring the first viewer receives cached content without hitting the Sia network.

Why this works on Sia. Sia’s storage architecture is uniquely suited to video delivery. Every slab is content-addressed, and each host serves its sectors over a range-request protocol. When the SDK receives a download(object, {offset, length}) call, it pulls only the sectors that overlap the requested byte range. No full-object reconstruction is required.

SiaStream turns this into a first-class delivery primitive. When an HLS player requests a byte range from a data.m4s file, the gateway passes that range directly into the SDK’s byte-range download, and Sia returns exactly those bytes from the relevant slabs. This is the same streaming contract that Mux, Cloudflare Stream, and every S3-backed video platform depend on. A viewer watching one minute of a two-hour video pulls only that minute’s bytes from Sia, not the whole object. First-frame latency is a single slab fetch rather than a full-file download.

Paired with single_file HLS output, per-video Sia operations drop from hundreds to N + 2, and viewer-facing bandwidth cost scales with what is actually watched. This is the core reason Sia is a viable video storage primitive and not just archival storage, and it is what lets SiaStream match the developer experience of centralized platforms without giving up decentralization, encryption, or content addressing.

State management. The Sia indexer does not provide directory hierarchies or metadata search because all object metadata is encrypted and opaque to the indexer. SiaStream therefore maintains a PostgreSQL database as the authoritative mapping between assets, renditions, artifacts, and Sia Object IDs. A background reconciliation worker periodically verifies database state against the indexer by paginating through tracked objects using cursor-based listing, flagging orphaned objects for cleanup.

SiaStream MVP
dashboard
dashboard4336×2804 615 KB
upload
upload4336×2804 511 KB
assets
assets4336×2804 729 KB
player
player4336×2804 668 KB
analytics
analytics4336×2804 613 KB
developer
developer4336×2804 590 KB
settings
settings4336×2804 573 KB
assets2
assets24336×2804 644 KB

Technology Stack

  • Backend: Node.js with Express, TypeScript
  • Database: PostgreSQL via Drizzle ORM
  • Job Queue: BullMQ backed by Redis with three queues for transcoding, upload, and finalization
  • Upload Protocol: @tus/server embedded in the Express application
  • Transcoding: FFmpeg invoked as a subprocess, producing fMP4 HLS with single_file output mode
  • Sia Integration: Official Sia Foundation TypeScript SDKs: sia-storage for the control plane and @siafoundation/sia for the data plane, bridged via seal/open serialization
  • Caching: In-memory LRU for manifests and thumbnails; Nginx reverse proxy cache for segment delivery
  • Frontend (Studio): Vite + React + Tailwind CSS + shadcn/ui, TanStack Query
  • React Player: hls.js wrapper with Safari native fallback, published to npm
  • Client SDK: TypeScript client wrapping the REST API with tus-js-client, published to npm
  • Container: Docker with Docker Compose

Security Best Practices

  • Client-side encryption. The Sia SDK encrypts all data client-side with per-slab stream ciphers before transmission. Storage providers and the indexer never see plaintext content.
  • API key security. Keys are SHA-256 hashed before persistence; the raw key is shown only once at creation. Granular scopes of upload, read, and manage are enforced per key, with rate limits via Redis sliding-window counters.
  • Webhook signing. HMAC-SHA256 cryptographic signatures on every webhook payload, computed with per-endpoint secrets, allowing receivers to verify payload integrity.
  • Signed playback tokens. JSON Web Token access tokens with expiration and optional IP restrictions, validated at the gateway before serving private content.
  • Sia key isolation. The Ed25519 application key, Sia’s digital signature key, is loaded only in the backend process from environment configuration and never exposed to clients.
  • Input validation. Upload size limits at the TUS layer, environment schema validation via Zod, and API input sanitization.
  • License-safe FFmpeg. Invoked as a subprocess rather than linked as a library, preserving Apache 2.0 compatibility.

Timeline with measurable objectives and goals.

The project spans 5 months with 5 milestones. Each produces independently verifiable deliverables.

Milestone 1 — Core Backend and Sia Storage Pipeline (Month 1, $16,000)

Objective: Deliver the backend service, video processing pipeline, and Sia storage integration, validating the complete upload-to-store path.

Deliverables:

  • Backend service with embedded TUS server handling resumable uploads.
  • FFmpeg transcoding pipeline producing fMP4 HLS output in single_file mode with default renditions at 1080p/5,000 kbps, 720p/2,800 kbps, 540p/1,400 kbps, and 360p/800 kbps, customizable up to 4K.
  • Sia storage integration via both official TypeScript SDKs: uploadAndPin for large rendition files, uploadAndPinPacked for playlists and thumbnails, with object handle bridging via seal/open.
  • HLS manifest rewriting engine replacing local paths with gateway URLs mapped to Sia Object IDs, preserving byte-range offsets.
  • PostgreSQL schema via Drizzle ORM for assets, renditions, artifacts, upload sessions, and processing jobs. BullMQ job queue with Redis for pipeline orchestration.
  • Thumbnail extraction and Docker Compose development stack with backend, PostgreSQL, and Redis.

Verification: Upload a video via TUS, observe transcoding to four renditions, verify all artifacts are uploaded and pinned on the Sia Zen testnet, and confirm PostgreSQL correctly maps each Sia Object ID to its parent asset and rendition.

Milestone 2 — Delivery Gateway and REST API (Month 2, $16,000)

Objective: Deliver the HTTP gateway for Sia-backed playback and the complete developer-facing REST API.

Deliverables:

  • HTTP delivery gateway with byte-range passthrough to the Sia SDK, returning 206 Partial Content with proper headers. Cross-Origin Resource Sharing configuration for embedded playback across domains.
  • In-memory LRU cache for manifests and thumbnails, Nginx reverse proxy cache for segments with X-Cache-Status headers, and cache warming on transcoding completion.
  • REST API designed spec-first with OpenAPI 3.1, a machine-readable API specification standard. Endpoints cover asset CRUD with cursor-based pagination and filters, upload session creation, processing status, playback URL generation, playback ID management for public and signed access, and per-asset Sia storage breakdown.
  • Scoped API key system with SHA-256 hashing, Redis-backed rate limiting, and scope enforcement for upload, read, and manage permissions.
  • Webhook system delivering lifecycle events (video.upload.created, video.asset.ready, video.asset.errored, video.asset.deleted) with HMAC-SHA256 signing, idempotency keys, exponential backoff retries, and a delivery log. Polling fallback at GET /v1/events.
  • Time-limited share URLs via the Sia SDK’s built-in sdk.share_object(obj, expires).
  • Background reconciliation worker comparing PostgreSQL state against indexer inventory via cursor-based sdk.objects().

Verification: Stream a video end-to-end via HLS, verify adaptive quality switching and byte-range requests, confirm cache hits via Nginx headers. Exercise the full API lifecycle: create an API key, upload a video, receive a webhook on completion, generate a signed playback URL, and confirm expired tokens are rejected with HTTP 403.

Milestone 3 — TypeScript SDK and React Player (Month 3, $16,000)

Objective: Deliver typed client SDKs and a production-ready React player component.

Deliverables:

  • TypeScript SDK (@siastream/sdk on npm) wrapping the REST API with typed methods for asset management, upload creation, playback URL retrieval, and webhook verification. Integrates tus-js-client for browser-side resumable uploads with progress events, pause/resume, and retry. Generated from the OpenAPI spec to ensure zero drift from the API contract.
  • React player component (@siastream/player on npm) wrapping hls.js with adaptive quality selection, loading states, error recovery with automatic retry, seek-preview thumbnails using WebVTT sprite sheets, and Safari native HLS fallback. Built with tsup for ESM and CJS module output, with a React 18+ peer dependency.
  • Python SDK (siastream on PyPI) providing an equivalent REST API wrapper with typed methods for asset management and playback URL generation.

Verification: Build a minimal web application using the TypeScript SDK and React player. Upload a video with progress tracking, poll for readiness, embed the player, and verify adaptive streaming and error recovery across Chrome, Firefox, and Safari. Confirm the Python SDK can list assets and generate playback URLs against the same instance.

Milestone 4 — Studio Web Application (Month 4, $16,000)

Objective: Deliver the management Studio for full visual control over the video lifecycle.

Deliverables:

  • Studio dashboard built with Vite, React, and shadcn/ui: asset totals, storage usage, latest uploads, cache statistics, and indexer status.
  • Upload page with TUS progress visualization, drag-and-drop, and live processing log timeline.
  • Asset library with search, filtering, sorting, and bulk operations.
  • Asset detail view: embedded player, rendition info, Sia storage breakdown showing Object IDs, slab and sector counts, host distribution, and redundancy ratio. Includes processing timeline and metadata editor.
  • Developer page with ready-to-copy integration snippets in JavaScript, Python, and curl.
  • Settings: API key creation and rotation, webhook configuration with delivery history, theme toggle.
  • Analytics page: asset counts, total duration, storage growth over time via recharts.

Verification: Upload a video through Studio, observe real-time processing status, browse the asset library, inspect per-asset Sia storage details, preview playback with quality switching, and manage API keys and webhooks.

Milestone 5 — Documentation, Testing, and Release (Month 5, $16,000)

Objective: Deliver documentation, test suite, production deployment configuration, and public release.

Deliverables:

  • Quickstart guide achieving first video playback within 5 minutes from Docker Compose.
  • API reference auto-generated from the OpenAPI 3.1 spec with interactive endpoint explorer.
  • Integration guides for React, Next.js, and plain JavaScript.
  • Architecture documentation with data flow diagrams, SDK integration patterns, and Architecture Decision Records.
  • Test suites covering the backend (route handlers, webhook signing, FFmpeg arguments, manifest rewriting, API key hashing, rate limiting), the SDK (client construction, error mapping, TUS integration), and the React player (hls.js wiring).
  • Docker Compose configurations for development, an optional local Sia testnet with indexd, walletd, and cpuminer, and production deployment with named volumes, restart policies, and TLS termination.
  • Asset deletion pipeline: soft-delete in PostgreSQL, asynchronous Sia unpin and prune, garbage collection for partial deletes.
  • Monorepo under Apache 2.0 with contributing guide.

Verification: Clone the repository, run docker compose up, follow the quickstart to upload and stream a video within 5 minutes. All test suites pass. Production guide covers TLS and Sia indexer connection for testnet and mainnet.

End-of-Grant Deliverables

At grant conclusion, the following components will be delivered under Apache 2.0:

  • Backend service handling TUS resumable uploads, FFmpeg transcoding to four-rendition HLS, per-artifact Sia storage via the official SDKs, manifest rewriting, and webhook dispatch.
  • HTTP delivery gateway with byte-range passthrough from Sia, Nginx caching, and cache warming.
  • REST API with OpenAPI 3.1 specification, scoped API keys, rate limiting, signed playback tokens, and lifecycle webhooks.
  • TypeScript SDK (@siastream/sdk on npm) for asset management, browser uploads, and webhook verification.
  • Python SDK (siastream on PyPI) for server-side asset management and playback URL generation.
  • React player component (@siastream/player on npm) with adaptive quality switching, error recovery, and Safari fallback.
  • Studio web application for visual asset management, upload monitoring, Sia storage inspection, API key management, and analytics.
  • Documentation including quickstart guide, API reference, integration guides, and architecture decision records.
  • Test suite covering backend, SDK, and player.
  • Docker Compose configurations for development, local Sia testnet, and production deployment.

Who is the target user for your project?

SiaStream targets application developers and engineering teams who need video capabilities without building custom video infrastructure. No knowledge of Sia’s storage internals, erasure coding, or indexer workflows is required to integrate or use the platform. This includes teams building creator platforms, educational technology, media archives, enterprise internal tooling, and consumer applications requiring video upload, processing, and playback.

The secondary audience is organizations with data sovereignty, censorship resistance, or content integrity requirements. These include human rights organizations, journalistic outlets, and enterprises under strict privacy regulations that need video infrastructure where no third party can access or remove their content.

What are your plans for this project following the grant?

SiaStream is not a grant-scoped project. It is the foundation of a long-term business I intend to build and operate. All core components produced during the grant (backend, API, SDKs, React player, and Studio) are open-source under Apache 2.0 and will remain so.

In parallel, I plan to operate a hosted version of SiaStream as a managed service, following the open-core model used by projects like Supabase, PostHog, and Firecrawl. The self-hosted version is fully functional and free. The hosted offering will provide managed infrastructure, managed transcoding, dedicated support, advanced analytics, and SLA guarantees for teams that prefer not to operate their own deployment. This gives SiaStream a sustainable revenue path independent of grants, directly tied to platform adoption: as more developers and content platforms integrate SiaStream, the hosted service grows with them. Every video processed through the hosted service generates storage contracts and bandwidth payments on the Sia network, creating a self-reinforcing demand loop for Siacoin that scales with usage.

Community engagement will be sustained through GitHub Discussions for technical issues, a Telegram channel for developer interaction, an X account for updates and ecosystem visibility, and monthly progress reports on the Sia Forum.

I am committed to this project because the opportunity is clear: video infrastructure on Sia has validated demand, no existing solution, and a monetization model that scales with ecosystem growth

Potential risks that will affect the outcome of the project:

Sia SDK stability. The TypeScript SDKs are pre-1.0 and may introduce breaking changes. Mitigation: all SDK interactions are isolated behind a bridging abstraction layer. Versions are pinned in package.json, and upgrades require passing a full upload, pin, download, and unpin integration test suite. The seal/open bridging between the two SDKs provides an additional buffer against changes in either SDK independently.

Cold retrieval latency. Uncached Sia downloads may take 1–2 seconds to first byte, since the SDK must contact multiple storage hosts and reconstruct erasure-coded slabs before serving data. Mitigation: the multi-layer cache combining Nginx reverse proxy and in-memory LRU absorbs repeated requests. The single_file HLS mode reduces per-playback Sia operations. Cache warming after transcoding ensures the first viewer hits cache. A CDN can sit in front of Nginx for production deployments.

Concurrent stream memory. Each cold Sia download requires RAM for slab reconstruction, the process of reassembling erasure-coded data from multiple hosts. Mitigation: Nginx absorbs 90%+ of requests, making concurrent cold downloads rare. Gateway instances scale horizontally for high-traffic deployments.

Development Information

Will all of your project’s code be open-source?

Yes. All code will be released under the Apache 2.0 license. All third-party dependencies are MIT or Apache 2.0 licensed. FFmpeg (LGPL 2.1+) is invoked as a subprocess only, preserving Apache 2.0 compatibility.

Leave a link where code will be accessible for review.

https://github.com/justmert/siastream (currently private; will be made public upon grant approval — reviewers can contact me for access)

Do you agree to submit monthly progress reports?

Yes. Monthly reports will be posted to the Sia Forum aligned with each milestone, detailing completed work, technical decisions, deviations, and next steps.

Do you agree to designate a point of contact for committee questions and concerns?

Yes. Mert Köklü — [email protected], Telegram: @mertkklu, Discord: mertkkl

Provide links to previous work or code from all team members.

Mert Köklü

Mert is an experienced software engineer with over four years of blockchain development experience, specializing in tooling, integrations, and backend infrastructure. He holds Bachelor’s degree in Computer Science and has led engineering teams focused on both AI and blockchain technologies.

He previously worked with ApeWorX, where he developed StarkNet plugins and compiler tools for the Cairo language. Before that, he served as AI Video Analytics Team Lead at an NVIDIA partner company, managing large-scale intelligent vision projects.

He is also a long-term Sia ecosystem contributor, having developed multiple grant-funded projects for the network.

Recent Grantee Projects:

  • SoroReveal: Decompile Soroban smart contracts back to readable source code (web)
  • Alerts dYdX: Monitor positions, alerts, and account status on dYdX in real time (web)
  • Kurtosis-Orbit: Tool for spinning up complete Arbitrum Orbit rollup environments (repo)
  • Arbitrum Python SDK: Python library for interacting with Arbitrum (repo)
  • ICP Agent Kit: Enables natural language interaction with the Internet Computer (repo)
  • Cosmic: Local Starknet block explorer (repo)

Have you developed a proof of concept for this idea already?

Yes. A working reference implementation is live at https://siastream.com, with a video walkthrough of the platform at https://youtu.be/-NnKGXTSVjw. The MVP demonstrates the complete pipeline end-to-end against the Sia network: TUS uploads, four-rendition fMP4 HLS transcoding with single_file mode, per-artifact Sia storage via both official TypeScript SDKs, byte-range delivery through a caching gateway, a REST API, a TypeScript SDK, a React player component, and a management Studio. On the Zen testnet, a single test video produces approximately 10–12 pinned Sia objects across tens of slabs, all independently verifiable on Siascan, with first-frame playback achieved within seconds via the range-passthrough gateway.

Do you agree to participate in a demo at our grants committee meeting at significant milestones or after the grant’s completion, or to work with our grants team to help showcase your project to the community?

Yes.

Contact Info

Email: [email protected]

Any other preferred contact methods:

Standard Grant: Sluby - Developer-First Video Infrastructure on Sia [Resubmission of SiaStream]
Sia Migration / ETL Tooling
2

Hi @mert - thank you for this proposal. The subject line didn’t include the grant type so I am editing it for clarity to properly indicate this is a Large grant.

Also, the developer fee amount listed per month is too high. You’ll note the informal standard for monthly developer fees is max. $8,000 in other similar proposal types. The amount you’ve listed here will be harder to justify. Please revisit your budget and, if needed, your timeline with this in mind.

3

Hi @mecsbecs — thanks for updating the subject line.

I submitted this as a Large Grant intentionally. The $16,000/month rate reflects the scope: five months of full-time solo work across backend, HTTP gateway, REST API, SDKs, Studio web app, docs, and test suite - delivering a production-ready platform comparable to Mux or Cloudflare Stream, with a working MVP already live at siastream.com. This is consistent with what I’ve worked at across other ecosystems on comparable grant-funded projects.

Per the published guidelines, monthly installments under $8,333 define a Standard Grant and Large Grants are specifically the tier where the rate exceeds that threshold - which is why I submitted as large grants.

I can stretch to a lower monthly rate if preferred, but that means the same deliverables over 9–10 months instead of 5: slower ecosystem impact, same total cost.

Happy to let the Grants Committee weigh the budget against the scope and working prototype, and revise based on their feedback.

4

Hi @mert - yes, your reference to the guidelines is correct and no upper limit has been outlined, so I will take this justification to the Committee at the April 28th meeting, and we’ll see their response.

1 Like
5

Hello i just upload a video, works really great. Awsome job !

1 Like
6

Hey, thanks for checking it out, great play with Illaoi :)

7

Thanks for your proposal to The Sia Foundation Grants Program.

After review, the Committee has decided to reject your proposal citing the following reasons:

  • A Small grant would be preferred to prove the concept first.

  • The project needs to prioritize making the MVP Sia-native.

  • The project name includes “Sia” which is not compliant with our brand guidelines.

We’ll be moving this to the Rejected section of the Forum. Thanks again for your proposal, and you’re always welcome to submit new requests if you feel you can address the Committee’s concerns.

8

Thanks for the review and for spelling out the feedback so clearly @mecsbecs. Before deciding whether to resubmit, I’d like to respond to each of the three points, because two of them seem to rest on assumptions about the project that don’t quite match the live MVP.

On Sia-native architecture.
The MVP is built directly on the official Sia Foundation TypeScript SDKs and indexd. Every video artifact is a real Sia object pinned through the SDKs, every shard is backed by a real Sia file contract on Zen testnet, and the delivery path pulls bytes back through the SDK’s byte-range download. The live demo at https://siastream.com surfaces those contract IDs and links each one to its on-chain entry on Siascan. If you have a moment to open it and click any contract chip, you can confirm this in seconds.

That said, if there’s a specific part of the architecture the Committee saw as non-Sia-native, I’d genuinely like to know. Beyond using the official SDKs and indexd, I’m not sure what “more Sia-native” would look like in practice, and that’s the gap I’d most like to close before resubmitting.

On the project name.
Entirely my mistake. I wasn’t aware of the brand guidelines when I picked the name. Happy to rename for any future submission.

On the Small-grant suggestion.
A working proof of concept already exists and is live. I’ve also been around the Sia ecosystem for some time as a contributor, so this isn’t a first-contact attempt to build on Sia. The “prove the concept first” framing doesn’t quite fit the project or the context.

The five-month budget covers the work needed to take the MVP from a working prototype into a production-grade platform external developers can actually adopt. That scope doesn’t compress into a Small grant without dropping deliverables that would leave the platform unfinished. But I’m flexible on the dollar figure itself. If a reduced budget would unlock a Standard grant, I’m open to that conversation.

Before I resubmit, would the Committee be open to a Standard-grant re-submission under a compliant project name, with the clarifications above incorporated?

Thanks again for the time spent on this.

9

image
image1241×205 18 KB

Excuse me, but the screenshot doesn’t confirm what you say.

Another question, what redundancy settings are you using with indexd, and how many contracts do you have there?

10

Hi,

The Settings card you screenshotted was a leftover label from the prototype days. Initial development was on renterd because the indexd docs hadn’t been published yet; once they were, I moved the stack to indexd and that single label slipped past the cleanup. The MVP deployment at https://siastream.com has been running on indexd from the moment it went live, with the official sia-storage SDK from npm as the entire storage layer: Builder.connected(appKey), sdk.uploadPacked(), sdk.pinObject(), sdk.download(). Every byte of media on the platform flows through that path. The renterd reference was just dead UI text that did nothing. I deleted the that component from the frontend now.

This is a prototype, so leftover bits like that label are part of the territory, which is why I shared the screenshot openly to begin with. It wasn’t on my mind that it could be read as evidence that the platform isn’t sia-native, because it isn’t. Here is what you can verify directly without needing my word for any of it.

Verifying the deployment is on indexd

  1. Live test asset: SiaStream — Decentralized Video Infrastructure

    Scroll to the “Verified on Sia” card. Each contract chip and host chip opens its on-chain page on Zen Siascan. Hit play and the player streams via byte-range requests; the gateway pulls only the chunks the player asks for, from the right Sia hosts.

  2. Per-asset Sia breakdown, copy-pasteable:

    curl -s https://siastream.com/api/v1/assets/5910f68a-8a5f-4790-b671-d58c40c6ff95/sia | jq .indexer

    Returns:

    {
  "url": "http://sia-indexd:9982",
  "network": "zen",
  "walletAddress": "07ef8584d779967d623fc1fdf408d0fd163f23bb575adfd690308c4cf4880497750804182252"
}

    That URL is the indexd application API the backend signs every upload, pin, and download against (via sia-storage’s Builder.connected(appKey) flow). Drop the | jq .indexer to see the full per-variant breakdown (hosts, contracts, sector counts, redundancy), all populated from indexd’s slab metadata.

  3. The wallet on Zen Siascan shows the actual on-chain activity indexd’s contract maintenance has been pushing (contract formations, account funding, the lot):

    Address 07ef8584d779967d623fc1fdf408d0...

Answer to your other question

what redundancy settings are you using with indexd, and how many contracts do you have there?

Redundancy: 2-of-6 erasure coding (2 data + 4 parity = 3.0×).

Active contracts: 6, one per Zen host that cleared indexd’s contract-maintenance host filter (pricing within maxStoragePrice / maxIngressPrice / maxEgressPrice, at or above minCollateral, at or above minProtocolVersion, acceptingContracts: true, and recent scan success). Contract IDs (all state=active, good=true):

a4d866bd65ff011344f83a2ade491de051494627502335ad1a1e2900d31d1677
abf7c261ffc0f6a6ee7ca131c54402e913182f3d3eec787b3313431a0a5e14e8
b2a101bb5f9ee58941d3929c71154301f17f3f33fe94f4fe3ea87084fea1fec5
c5cebe0c9a04475de77655fe594f57b18963e75cbe768c8cdcec5285bf2e87db
1f20c15db85095e235e398c633516da7dc0fecd58af01e1a18a0107da4f91956
7177be4392673b3aa5cdb37e97b10ae9e4959f8b5cef5b89f00db95b785b3845

Click any one on Siascan, e.g. Contract a4d866bd65ff011344f83a2ade491d...

The 2-of-6 ratio is forced by Zen’s pool: 27 hosts announced, 14 accepting contracts, but only 6 cleared the host filter above. Forming more contracts wasn’t possible: there were no more usable hosts. 2-of-6 uses every active contract (no cold ones being paid for) and tolerates losing 4 of 6 hosts before any data loss.

Patches applied, with feedback I’d like to surface upstream

Two hardcoded constants in the upstream code blocked 2-of-6 from working at all on Zen. I patched them locally to ship the prototype, and I’d like to file PRs against both repos with a proper fix. Can do it after the grant decision lands; happy to file now if you’d rather:

1. accounts/manager.go in indexd. ReadyHostThreshold is hardcoded at 30. An account is only marked ready: true after 30 host accounts have been successfully funded. Zen doesn’t have 30 usable hosts in total, so account.ready stays false indefinitely and the SDK refuses to upload. I dropped the constant to 4 in our testnet build. Mainnet should keep 30; the threshold makes sense at scale. Suggestion: expose this as a config flag (or a per-network default) so a mainnet to testnet move doesn’t require a fork.

2. slabs/slabs.go in indexd AND sia_storage/src/lib.rs in sia-sdk-rs (the Rust source the npm sia-storage package is published from). Both have the same hardcoded recoveryProbability = 0.75. The slab health validator computes P(X ≥ data_shards | n = total_shards, p = 0.75) and rejects the slab unless it clears minRecoveryProbability = 99.99. With 6 hosts and p = 0.75, 2-of-6 calculates to ~99.54%, under the bar, so indexd rejects every upload, and the SDK rejects it client-side before indexd even sees it. Bumping p to 0.90 lifts 2-of-6 to ~99.9945% (just over the bar) and uploads go through. I built a custom NAPI binary of sia-sdk-rs with the same change so the client and server validators agree.

A related rough edge worth filing: with the upstream constant in place, the SDK’s error surface is "i/o error: cannot add object to finalized upload" wrapped in UploadError::Io. It’s not really an I/O error and the upload isn’t really finalized; the underlying problem is the recovery-probability check failing. Cost me an evening to track down. An error like "not enough redundancy: P(...) below 99.99% threshold" would point straight at the cause.

Both patches are testnet-only adaptations. The mainnet build will revert to upstream defaults on a host pool that can satisfy them. The patches don’t trade away durability, they just let the validators acknowledge what’s actually on Zen.

If anything above leaves doubt that the platform is not sia-native, happy to set up a quick live meeting to walk through it.

11

@mecsbecs bringing this to your attention now that the sia-native question above is fully answered.

Quick recap on the original three points the committee raised:

  1. Sia-native: addressed in detail in the post directly above.

  2. Brand guidelines on the name: noted, happy to rename.

  3. Small grant preference: Prototype already exist on indexd end-to-end, and sia-native.

Would the committee be open to re-reviewing if I rework the proposal for the standard grant track with reduced budget? Thank you.

12

Hi @mert - thank you for addressing the concerns. I don’t see any issues with a new standard grant proposal.

1 Like
13

Thanks @mecsbecs. I’ve submitted the revised proposal as a Standard Grant with a compliant project name with your budget suggestion.

Appreciate the guidance throughout this process.

1 Like