[Small Grant] RelayStream: Native Sia Media Orchestration & Storage Ingestion Engine

Grants Proposed
1

[Small Grant] RelayStream: Native Sia Media Ingestion & Storage Orchestration Engine

Introduction

Project Name:

RelayStream Open Ingestion Engine

Applicant:

Michael Lipson | Val IT Tech Solutions

Contact:

[email protected]
X: @RelayStream_net

GitHub:

https://github.com/tvmateocmd-design/open-strm-standard

Background

Lead Systems Architect focused on real-time data synchronization, self-hosted infrastructure, and distributed media delivery workflows.

Previous development work includes the EMS Companion App, designed around real-time synchronized data systems utilizing Firebase infrastructure.

Current development efforts are focused on creating open-source tooling for decentralized media ingestion, archival organization, HLS packaging workflows, and distributed storage orchestration using Sia-native infrastructure.

Project Description

The RelayStream Open Ingestion Engine is a self-hosted media ingestion and orchestration framework designed for operators utilizing the Sia storage ecosystem.

The engine automates the process of:

  • ingesting large media files

  • converting media into HLS-compatible segmented structures

  • generating retrieval manifests

  • coordinating distributed storage uploads

  • organizing redundancy workflows

  • managing retrieval metadata

The project is intended for:

  • self-hosted media archivists

  • distributed broadcasters

  • educational archives

  • public domain preservation projects

  • independent infrastructure operators

All processing occurs server-side on operator-controlled infrastructure such as VPS servers, dedicated servers, or local self-hosted deployments.

The project does not rely on browser-side transcoding or custodial SaaS infrastructure.

Target User

The RelayStream Open Ingestion Engine is intended primarily for technical operators and power users managing self-hosted infrastructure.

Target users include:

  • self-hosted media archivists

  • independent broadcast operators

  • distributed media infrastructure researchers

  • educational archival projects

  • advanced home lab operators

  • decentralized storage developers

Because large-scale video ingestion and FFmpeg processing are compute-intensive, the system is specifically designed for VPS, dedicated server, or operator-managed infrastructure environments rather than lightweight consumer devices.

Mission Alignment

This project aligns with the Sia mission of user-owned infrastructure and decentralized storage coordination.

RelayStream is focused on enabling operators to maintain direct control over:

  • infrastructure

  • storage coordination

  • retrieval workflows

  • redundancy management

  • deployment environments

The project is specifically being redesigned around current Sia architecture expectations and Indexd-compatible workflows.

Grant Specifics

Amount Requested:

$10,000 USD

Architecture Components

Component A — Media Ingestion Pipeline

Automated FFmpeg-based ingestion pipeline that converts large media assets into segmented HLS-compatible delivery structures.

Current Proof-of-Concept Status:

  • successful HLS segmentation completed

  • automated manifest generation operational

  • segmented media output confirmed

Component B — Storage Orchestration Layer

Node.js-based orchestration service responsible for:

  • coordinating uploads

  • organizing storage metadata

  • handling retrieval manifests

  • automating distributed storage workflows

  • integrating with Indexd-compatible SDK workflows

The orchestration layer is designed around self-hosted operator infrastructure and modular deployment environments.

Component C — Redundancy & Integrity Coordination

Distributed redundancy workflow coordination for archival durability and retrieval reliability.

Planned features include:

  • redundancy verification

  • integrity validation

  • retrieval consistency checks

  • distributed storage organization

The system will rely primarily on Sia-native redundancy mechanisms and operator-controlled deployment environments.

Component D — Open Documentation Standard

Creation of public open-source documentation for:

  • deployment workflows

  • ingestion pipelines

  • HLS packaging standards

  • storage orchestration setup

  • self-hosted deployment configurations

The objective is to simplify decentralized media archival workflows for the broader Sia ecosystem.

Security Best Practices

The project is designed around self-hosted and non-custodial deployment principles.

Operators retain full control over:

  • storage environments

  • deployment infrastructure

  • authentication systems

  • storage coordination workflows

All ingestion and orchestration processes occur server-side under operator-controlled infrastructure.

The project also plans to utilize existing automated storage management systems where appropriate instead of implementing unnecessary custom contract renewal systems.

Goals & Timeline

Month 1 — Core Ingestion Engine

Deliverables:

  • finalized FFmpeg ingestion pipeline

  • automated HLS packaging

  • manifest generation workflows

  • local metadata indexing

Success Criteria:

  • stable automated HLS output generation

Month 2 — Storage Orchestration

Deliverables:

  • upload coordination framework

  • redundancy workflow integration

  • retrieval manifest handling

  • storage metadata organization

Success Criteria:

  • successful distributed upload orchestration

Month 3 — Open-Source Release

Deliverables:

  • public repository release

  • deployment documentation

  • self-hosted setup guides

  • Docker deployment examples

  • operator installation documentation

Success Criteria:

  • publicly deployable ingestion engine release

Risks & Mitigations

Storage Coordination Complexity

Mitigation:

  • modular orchestration design

  • operator-controlled deployment workflows

  • staged redundancy verification

Large Media Processing Requirements

Mitigation:

  • server-side FFmpeg workflows

  • VPS and dedicated server deployment support

  • self-hosted infrastructure model

Distributed Retrieval Consistency

Mitigation:

  • retrieval manifest organization

  • metadata validation workflows

  • redundancy verification systems

Development Information

Open Source:

Yes — MIT License

RelayStream Repository:

https://github.com/tvmateocmd-design/open-strm-standard

Proof of Prior Development Work:

https://github.com/tvmateocmd-design/EMS_Overlay_MASTER_FINAL

Post-Grant Plans

Following the grant period, development will continue as an open-source infrastructure project focused on improving decentralized media ingestion and archival workflows.

Post-grant priorities include:

  • expanding deployment tooling

  • improving distributed redundancy coordination

  • optimizing large-scale ingestion performance

  • refining metadata organization

  • building broader community documentation

  • supporting additional self-hosted deployment environments

The long-term objective is to contribute reusable open-source tooling that simplifies media archival and distributed storage orchestration for the broader decentralized infrastructure ecosystem.

Previous Experience Building on Sia

Relevant experience and development work:

Current development efforts include evaluating Sia Storage workflows, bucket organization, object management, storage contracts, decentralized storage architecture, and media ingestion tooling as part of the RelayStream Open Ingestion Engine.

The attached demonstration includes active storage contracts, bucket management, object uploads, developer documentation review, and an overview of how Sia is being evaluated within RelayStream’s decentralized media coordination architecture.

Monthly Reports

I agree to submit monthly progress reports to the forum and provide ongoing development updates regarding milestones, deployment progress, and public repository activity.

2

Continuing on our short chat on the forums;

You said you are planning to use the Go SDK to interact with Renterd. The SDK is for Indexd, not Renterd.

On top of that, Renterd proposals are no longer accepted as per the new guidelines.

Why not use the autopilot for this? In your risks you’re mentioning using the Autopilot.

Your screenshot shows minting NFT’s on Solana, what’s the purpose of this? To add to this; building on top of other chains is also not funded.

1 Like
3

I have seen various spins of this over the years that can be seen in past proposals. as far as I can see your trying to create a media transcoder system that sends all data to Sia.

That idea alone IMO isn’t exactly bad, but the whole proposal is based around outdated assumptions and would need to be honestly binned and re-thought for how indexd works…

And broadly this type of thing would have to be self-hosted since doing media pipelines in the browser would not be a good idea as this lands in cloud/SaaS infra territory due to the compute needed… For the user to be in full control and not compromise their account (non custodial), it would have to be their infra running anything

Additionally you left out who the target user is and what your plans are for the project.

See Small Grant Proposal Template | Sia.

1 Like
4

HI @relaystream - welcome to the Sia community! Please let me know when the above from other community members has been addressed so this proposal can be re-reviewed - especially when the missing elements of our Small Grant Proposal template have been included.

We’ve reached capacity for next week’s Grants Committee meeting, so this proposal will need to be edited by May 20th to be considered for review at the next meeting on May 26th.

5

[Small Grant] RelayStream: Native Sia-renterd Media Orchestration & Ingestion Engine

Introduction

Project Name: Open-STRM Ingestion Engine (for RelayStream)

Applicant: Michael Lipson | Val IT Tech Solutions

Contact: [email protected] | X: @RelayStream_net

GitHub: GitHub - tvmateocmd-design/open-strm-standard: An open-source framework for orchestrating high-speed 'Relay Tunnels' between Solana and DePIN networks (Sia, Theta, RENDER). · GitHub

Background:

Lead Systems Architect with a track record in real-time data synchronization. Previously developed the EMS Companion App (linked below), orchestrating high-velocity data via Firebase. Current focus: The Open-STRM Indexing Standard, designed to eliminate the “Latency Paradox” of decentralized media streaming.

Project Description:

The Open-STRM Ingestion Engine is an automated bridge that moves Hollywood-grade 4K media from raw storage to the Sia network. It transmuxes heavy video files into HLS-compatible segments and utilizes the Sia renterd SDK to automate contract creation and encrypted chunk distribution. This eliminates the need for manual orchestration, allowing creators to host professional video libraries on Sia with a single command.

Mission Alignment:

This project directly serves the mission of user-owned data. By replacing centralized cloud giants (AWS/GCP), we empower creators to hold their own storage contracts directly. RelayStream solves the “Storage Latency Paradox” by combining Sia’s cost-effective storage with 0G Aristotle’s high-speed indexing.

Grant Specifics

Amount Requested: $10,000 USD

Architecture Components:

  • Component A - The Transmuxer: Automated FFmpeg pipeline that slices 4K MKV content into encrypted .ts HLS segments. (Status: Milestone 1 Proof complete—229 chunks created).

  • Component B - renterd Bridge: A Node.js service utilizing the Sia SDK to automate bucket creation, contract funding, and segment uploading.

  • Component C - Integrity Layer: 0G Merkle Root anchoring (0x2e6ac921b62d2) to provide tamper-proof verification for segments in transit.

  • Component D - Discovery Standard: Documentation of the Open-STRM standard for ecosystem-wide adoption of Sia-hosted video.

Security Best Practices:

We utilize Sia’s native encryption-at-rest. The engine is non-custodial; the creator retains full authority over private keys and storage contracts. Cross-network integrity is enforced via Merkle Root commitments.

Goals & Timeline:

  • Month 1 (Foundation): Finalize HLS-to-renterd uploader module logic. (Success: Confirmed Sia uploads via SDK).

  • Month 2 (Data Layer): Implement automated contract renewal and segment redundancy checks.

  • Month 3 (Standardization): Public release of Ingestion Engine, Open-STRM documentation, and public MIT repo.

Risks & Mitigations:

  • Sia Host Volatility: Mitigation via Reed-Solomon erasure coding (30/10) managed by renterd Autopilot.

  • Network Latency: Mitigation via 0G Aristotle indexing for sub-500ms segment retrieval.

Development Information

Open Source: Yes, released under the MIT License.

RelayStream Repo: GitHub - tvmateocmd-design/open-strm-standard: An open-source framework for orchestrating high-speed 'Relay Tunnels' between Solana and DePIN networks (Sia, Theta, RENDER). · GitHub

Proof of Shipping (EMS): https://github.com/tvmateocmd-design/EMS_Overlay_MASTER_FINAL

Screenshot (578)
Screenshot (578)1931Ă—1080 208 KB

Monthly Reports: I agree to submit monthly reports to the forum.

Thank you to the Sia Grants Committee and community members for the detailed technical feedback regarding the original RelayStream proposal.

After extensive implementation work, architecture revisions, and active deployment testing using renterd v2.9.1, we have substantially revised the RelayStream infrastructure design to align with the current renterd ecosystem and decentralized sovereign media delivery principles.

Below are the updated technical clarifications and revised milestone criteria.

Field A — Response to Feedback

We appreciate the direct technical feedback provided by the Sia Grants Committee and have substantially revised the RelayStream architecture to align with the current renterd/indexd ecosystem and the operational realities of decentralized media delivery infrastructure.

The original submission incorrectly referenced the Go SDK as the primary interface layer for renterd orchestration. After deeper implementation work and active deployment testing, RelayStream has transitioned away from that assumption entirely. Our production architecture now interfaces directly with the renterd Worker REST API exposed through localized authenticated worker endpoints running on Port 9980.

RelayStream no longer relies on browser-native compute pipelines for media orchestration. We agree that attempting to execute full decentralized media processing directly in-browser would create unacceptable cloud/SaaS bottlenecks, elevated compute costs, and custodial infrastructure concerns.

To address this, RelayStream now utilizes a sovereign self-hosted execution layer built around localized Mini-PC worker infrastructure running renterd directly on user-controlled hardware. Browser clients never directly interact with Sia storage endpoints. Instead, all streaming requests are routed through a hardened Next.js Reverse Proxy Tunnel (app/api/stream/route.ts) that securely brokers authenticated requests between the frontend playback environment and localized renterd workers.

This architecture eliminates:

  • Browser-side authentication exposure

  • CORS instability between decentralized storage origins

  • Direct compute pressure on the frontend

  • Reliance on centralized cloud transcoding pipelines

  • Custodial media routing architectures

The revised system architecture now treats Sia as the immutable decentralized storage and retrieval backbone, while RelayStream’s localized proxy orchestration layer handles authenticated manifest delivery, segment retrieval, and streaming session continuity.

The project has therefore evolved from a conceptual browser-centric architecture into a sovereign decentralized edge-compute orchestration model built directly around renterd Worker API interaction.

Field B — Architecture & Sovereign Compute Description

RelayStream operates as a sovereign decentralized media orchestration layer built on top of renterd and Sia decentralized storage infrastructure.

The current production environment is deployed on Windows-based Mini-PC hardware functioning as localized master nodes. Each node runs:

  • renterd UI Desktop Application (v0.36.0)

  • renterd daemon (v2.9.1)

  • localized authenticated worker instances bound to secure localhost interfaces on Port 9980

RelayStream does not depend on centralized cloud compute providers for primary media delivery orchestration. Instead, the localized node infrastructure remains fully user-controlled and non-custodial.

The core playback architecture operates through a Next.js Reverse Proxy Tunnel layer (app/api/stream/route.ts) which performs:

  • authenticated Basic Auth handshakes with renterd Worker APIs

  • manifest routing

  • HLS segment orchestration

  • secure browser-safe streaming abstraction

Media assets are stored inside deeply structured decentralized bucket hierarchies under the primary storage namespace:



relay-vault/

Example structure:



relay-vault/series/Landman/Season 01/Episode01/chunks

RelayStream serves streaming-native HLS manifests (.m3u8) and segmented transport stream chunks (.ts) rather than attempting to deliver monolithic media objects directly to browser clients.

The architecture also incorporates a layered DePIN redundancy strategy:

  • Sia renterd serves as the decentralized immutable source-of-truth storage layer

  • Pinata IPFS gateways provide hot-edge cache acceleration

  • Lighthouse/Filecoin provides cold archival persistence and metadata permanence

This multi-network fallback topology allows RelayStream to maintain stream continuity even during renterd worker re-indexing events or temporary retrieval latency spikes.

The result is a decentralized sovereign streaming architecture capable of:

  • localized non-custodial execution

  • decentralized storage redundancy

  • authenticated streaming delivery

  • browser-safe playback abstraction

  • globally distributed edge-assisted retrieval

without requiring centralized hyperscaler media infrastructure.

Field C — Target Audience & Long-Term Strategy

RelayStream is specifically targeting three core market segments:

  1. Independent Production Studios

  2. Content Creators and Digital Rights Owners

  3. Decentralized IPTV and Media Distribution Operators

The primary economic problem RelayStream addresses is the unsustainable cloud egress fee model imposed by centralized providers such as AWS, Google Cloud, and Azure.

For many independent media operators, bandwidth and streaming delivery costs represent over 90% of recurring infrastructure overhead. Traditional cloud-based streaming systems force creators into custodial environments where:

  • media licensing is platform-dependent

  • content delivery is centrally controlled

  • storage costs scale aggressively with audience size

  • egress pricing destroys long-term operational sustainability

RelayStream replaces this model with decentralized infrastructure coordination.

Our long-term strategy is to establish RelayStream (.strm protocol) as a decentralized media routing and licensing layer where:

  • Sia provides sovereign decentralized storage

  • Solana provides cryptographic ownership and settlement

  • IPFS/Filecoin provide metadata permanence and edge accessibility

  • future Theta integration provides decentralized edge delivery acceleration

Content is represented through tokenized Digital DVD-style NFT licensing models, allowing creators to maintain direct ownership and programmable distribution rights without depending on centralized streaming platforms.

The protocol is intentionally designed to support self-hosted sovereign media infrastructure where operators maintain direct control over:

  • storage

  • retrieval

  • licensing

  • playback infrastructure

  • monetization

RelayStream is therefore not merely a streaming application. It is a decentralized media infrastructure protocol intended to reduce hyperscaler dependency and establish sovereign digital media ownership at the infrastructure layer itself.

Field D — Revised Milestone 2 Criteria

Milestone 2 will be considered successfully completed upon achieving the following measurable technical benchmarks:

1. Authenticated renterd Worker API Orchestration

  • Successful automated Basic Authentication handshake finality between RelayStream’s Next.js Proxy Tunnel and localized renterd Worker API endpoints bound to Port 9980

  • Stable authenticated retrieval of decentralized media assets from Sia-backed renterd infrastructure

2. Streaming Manifest Delivery

  • Successful delivery of HLS streaming manifests (.m3u8) through the RelayStream proxy orchestration layer

  • Correct routing and retrieval of segmented .ts transport stream fragments from decentralized storage infrastructure

  • Verified browser-safe CORS header injection and manifest compatibility across modern Chromium-based browsers

3. Decentralized Playback Validation

  • Sustained visual playback of 4K video content inside a React-based frontend player environment

  • Maintenance of sub-500ms segment retrieval latency under normal operational conditions using:

    • localized renterd workers

    • Sia decentralized storage

    • IPFS edge fallback caching

4. DePIN Redundancy Validation

  • Successful fallback retrieval testing between:

    • renterd/Sia storage

    • Pinata hot-edge caching

    • Lighthouse/Filecoin archival mirrors

5. Sovereign Local Infrastructure Validation

  • Demonstration that RelayStream media orchestration can operate fully from user-controlled Mini-PC infrastructure without dependency on centralized cloud transcoding or centralized streaming delivery providers

The completion of these benchmarks will validate the operational viability of RelayStream’s decentralized sovereign media delivery architecture and establish the foundation for expanded protocol deployment.

6

You’re still proposing to use Renterd while Renterd proposals are no longer accepted. The same goes for multi chain solutions.

7

Thank you again for the clarification and technical feedback. I now better understand the distinction between the Foundation’s current funding priorities versus the broader RelayStream protocol architecture.

The revised proposal was intended to address the original technical concerns around browser-side orchestration, sovereign infrastructure, and renterd Worker API assumptions. However, I understand now that the Foundation’s current grant focus is specifically moving away from renterd-centric proposals and multi-chain ecosystem integrations.

RelayStream itself will continue evolving as a broader decentralized media infrastructure project, but I recognize that the Sia Foundation grant scope likely needs to be narrowed substantially toward ecosystem-aligned tooling, indexing, or SDK-focused infrastructure directly related to current Indexd priorities.

I appreciate the candid feedback and ecosystem guidance from everyone involved. It has been extremely valuable in helping refine both the technical architecture and the long-term direction of the project.

8

It is very simple. Read about Quickstart - Sia Developer Docs and stop pitching renterd in your grant. Whatever you do needs to use the sdk libraries instead.

It is also unclear why filecoin is even mentioned as well, and if you want to do something IPFS related, I can tell you there has been grant funding towards that as well already, which may be of interest to you.

It is really not clear at all what your trying to pitch given the mixed signals in your proposal and I would recommend you read the docs I linked and try again.

Thanks.

9

Hi @relaystream - thank you for these revisions but please see the comments from community members above. Additionally, please make all edits in your original proposal for ease of reference, instead of adding new updates in the replies.

Please tag me again when the above has been resolved.

1 Like
10

Hi @mecsbecs — I’ve now fully updated and restructured the original proposal directly in the main post based on the community feedback provided.

The revised proposal removes outdated architectural assumptions and now focuses specifically on a self-hosted, Sia-native media ingestion and storage orchestration framework aligned around current Indexd-compatible workflows and open-source infrastructure tooling.

Thank you for the feedback and re-review consideration.

11

Some feedback.

The project is shifting toward Indexd-compatible workflows and operator-controlled orchestration instead of relying on outdated renterd assumptions.. I would just pitch what you want to do rather then referring to your previous revisions. Keep it strictly indexd & sdk and don’t add any confusion IMO.

Thanks.

12

You also seem to be missing the grant request component about the projects plans post-grant as well as the target user.

And, can you clarify that the intention is for power users to be running this infra since video processing infra is always going to be compute heavy?

Thanks.

13

Thanks for the feedback — I’ve updated the proposal again to clarify the target user, self-hosted infrastructure requirements, post-grant plans, and Indexd-compatible SDK workflow structure.

14

Great! This proposal will be reviewed by the Committee at next Tuesday, June 9th’s meeting and the response will be posted here before the end of next week.

15

Hi @relaystream - since I’m getting an error message when clicking on the above, which means the Committee will be unable to see your proof of previous work, this proposal won’t be able to be reviewed at Tuesday’s meeting after all.

It’s a 404 error message:

image
image891Ă—358 63.8 KB

To save everyone’s time, please edit ASAP and then tag me to review again by June 17th so this can be brought up at the June 23rd meeting.

16

Hi @mecsbecs,

Thank you for the heads-up. I discovered the issue was caused by the EMS Companion App repository being accidentally set to private.

The repository visibility has now been corrected and I have verified that the link is publicly accessible.

Please let me know if there are any additional issues accessing the repository or supporting materials.

Thank you for your continued review and consideration.

Michael Lipson
RelayStream

17

Hello @relaystream - thanks for amending this and this proposal will be going ahead to the June 23rd meeting.

18

@relaystream - please note, as of yesterday, we now require proof of experience building on Sia to demonstrate technical understanding of the Sia network to the Committee. Details can be found on the Grants webpage and reflected in the revised Small Grant proposal template.

Please tag me when the above has been incorporated into your proposal.

Thank you for your understanding.

19

@mecsbecs

Thank you for the clarification regarding the updated requirement.

I have updated the proposal to include links demonstrating previous experience working with Sia, including:

  • RelayStream GitHub repository

  • Prior forum discussion and development activity

  • A proof-of-work video demonstrating active Sia usage, storage contracts, bucket organization, object uploads, and developer portal review

Proof of Work Demonstration:
https://drive.google.com/file/d/1VuuyzLitoo4b0RU0JrZN9Bp7imweyOox/view?usp=drive_link

Please let me know if any additional information would be helpful for Committee review.

Thank you for your time and consideration.

20

RelayStream Development Update – Live Proof of Functionality

Hello Sia Grant Committee,

As part of our continued development efforts, I wanted to provide a new proof-of-functionality update for RelayStream.

We have completed a working demonstration of the RelayStream media pipeline operating in real time.

The demonstration includes:

âś“ FFmpeg HLS Generation

âś“ Real-Time Chunk Creation

âś“ HLS Manifest Generation (index.m3u8)

âś“ Local HTTP Delivery

âś“ Browser Playback

âś“ End-to-End Media Workflow Validation

This video demonstrates the current operational state of the RelayStream prototype and provides visual evidence that the core ingestion, packaging, and playback workflow is functioning.

Development Progress Since Submission:

• Continued HLS packaging development

• Additional storage testing across decentralized storage providers

• Successful archival testing using Filecoin/Lighthouse

• Expanded redundancy experimentation

• Ongoing Sia-native orchestration design work

Video Demonstration:

https://drive.google.com/file/d/153GZn-YHH8Wi-_6fqpJsAq_up9k0FHH9/view?usp=drive_link

Thank you for your time and consideration.

Michael Lipson
RelayStream
https://relaystream.org