Small Grant: Lume Web - LBRY Integration (Revised)

Grants Approved
1

Introduction

Project Name: Lume Web - LBRY Integration

Name of the organization or individual submitting the proposal: Hammer Technologies LLC

Describe your project.

LBRY is a peer-to-peer content sharing platform where files are shared among users. A significant challenge with this model is that content can become unavailable and permanently lost if no one is actively sharing it. This project will address this issue by integrating LBRY with the Sia network through the Lume Web portal. This integration will enable the Sia network to function as a decentralized and persistent storage layer for LBRY content, ensuring files remain consistently available for download, even when no peers are online.

It’s important to note that this integration focuses solely on storing the LBRY file data itself. It does not involve any interaction with the LBRY blockchain, thereby adhering to the grant guidelines that prohibit integration with non-Sia blockchains.

Project Background & The Opportunity for Sia

This section directly addresses the Committee’s feedback: “Given the uncertainty of LBRY’s active development, with the original project having moved to Arweave, the Committee would like more detail on how integrating with LBRY will be valuable to the Sia ecosystem.”

This feedback stems from a common but critical misconception regarding the LBRY ecosystem. The reality is:

  1. LBRY, the protocol, has not moved to Arweave. Odysee, a single application built on LBRY, was acquired by Arweave. The core open-source LBRY protocol and its community, guided by the LBRY Foundation, remain independent and are actively rebuilding.
  2. LBRY’s fundamental need for persistent storage remains unsolved. The protocol has always relied on peer-to-peer seeding, which lacks long-term data persistence. The separation from the Odysee application simply underscores that the core LBRY protocol currently has no integrated decentralized storage partner. This leaves a clear and unfilled need for a storage layer—an opportunity Sia is perfectly positioned to capture.

This project’s value to the Sia ecosystem is therefore direct and substantial: it onboards a mature creator economy with immediate, large-scale storage needs. Collaboration with the LBRY Foundation has quantified this opportunity:

  • Total Network Storage: Approximately 8,400 TiB of media content exists across all creator channels.
  • Top Creator Storage: The top 100 channels alone account for ~630 TiB of this data.

By providing the critical storage infrastructure LBRY currently lacks, this project positions Sia as the primary decentralized storage solution for this established data footprint, creating a clear and direct pathway to increased network utilization.

How does the projected outcome serve the Foundation’s mission of user-owned data?

True data ownership requires that your files are safe from being lost. Currently, LBRY creators risk their content disappearing, which undermines their control and ownership.

This project solves this by using Sia to ensure LBRY content remains persistent and reliably available. This provides LBRY creators with a complete solution for data ownership while bringing their entire creator economy and its storage needs to the Sia network.

Why Sia?

Sia was chosen for this integration because its core features provide a direct and robust solution to the specific challenges faced by the LBRY ecosystem.

  • Decentralized Redundancy: Sia’s architecture, which uses erasure coding to distribute encrypted file pieces across a global network of hosts, is the ideal technical solution for LBRY’s content permanence problem. It ensures high availability and durability without a single point of failure.
  • Cost-Effectiveness: The competitive marketplace for storage on Sia makes it significantly more affordable for independent LBRY creators than traditional centralized alternatives, making persistent storage economically practical.
  • Data Ownership and Censorship Resistance: Sia’s permissionless, user-controlled design aligns perfectly with the ethos of LBRY creators. It ensures that their data remains their own, free from censorship or de-platforming risks, directly fulfilling the Foundation’s mission.

Onboarding the LBRY Community & Enabling Future Growth

Bringing the LBRY creator economy to Sia will be achieved through a multi-faceted approach focused on direct support and enabling future, widespread adoption:

  1. Direct Onboarding Assistance: As the primary developer and a long-standing collaborator within the LBRY community, I will provide direct, hands-on assistance to any LBRY creators and community members looking to back up their content to Sia through the Lume Web portal. This personalized support ensures a smooth adoption process.

  2. Enabling Native Desktop App Integration: The LBRY leadership plans to add a feature to their official desktop application allowing users to back up content to reflector-compatible services.

    This grant will add the necessary reflector-compatibility to the existing Lume Web portal (operating at pinner.xyz). This positions the portal to be an immediate and practical storage destination for LBRY’s desktop user base, creating a direct pathway for their data to be stored on the Sia network.

We cannot provide grants to residents of jurisdictions under increased FATF monitoring, those that have active OFAC sanctions, or those that fail our bank compliance tests. We also cannot provide grants if your payment bank account is located in those same locations. Please review the following list.

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: $10,000

  • $9,330 - 2 months Developer fees for Derrick Hammer
  • $670 - R&D Infrastructure

What are the goals of this small grant? Please provide a general timeline for completion.

  • Month 1 (November, due 12/2/25): Build the protocol integration and the API
    • Tasks:
      • A new go library will need to be made based off the guts of GitHub - LBRYFoundation/reflector.go that will act as the foundation of the protocol backend support
      • A portal plugin portal-plugin-lbry will be made
      • Testing of the protocol integration and the various ways to pin data
    • Validations for this milestone will include:
      • Being able to pin a blob from the network over REST API
      • Being able to unpin a blob from the network over REST API
      • Being able to upload a small file as a blob and access it with LBRY CLI tools
      • Being able to upload a large file as a blob and access it with LBRY CLI tools
      • Being able to use LBRY tools to upload a blob to the portal using the LBRY native reflector protocol. This will require supporting device (IP based) whitelisting in the API (and GUI in Month 2).
    • All validations will be presented in the form of a CLI-based demo repo with instructions on testing each validation.
  • Month 2 (December, due 1/2/26): Build the frontend integration
    • Tasks:
      • Add LBRY as support for uploading data in the upload manager as a storage option
      • Add a pinning interface support for LBRY blobs
      • Add an approved device list interface support so that LBRY blobs can be uploaded via the reflector protocol and correctly associated to an account.
      • Testing functions and no obvious UX problems
    • Validations for this milestone will include (UI focused):
      • Being able to pin a blob
      • Being able to unpin a blob
      • Being able to upload a small file (post upload, defaults to max 100 MB)
      • Being able to upload a large file
      • Being able to use LBRY tools to upload a blob and see it show up in the blob list. Instructions for this validation will be provided in a demo repo.
  • All milestones will be testable at/against pinner.xyz

Potential risks that will affect the outcome of the project:

  • Any unexpected technical issues with the reflector protocol or other foundational LBRY P2P components.

    • Mitigation: My close working relationship with the LBRY Foundation’s leadership provides a direct line to the core community contributors best equipped to troubleshoot any protocol-level issues that may arise.

  • Any potential governance issues around cooperation with LBRY and the LBRY Foundation (lbry.org).

    • Mitigation: This risk is minimal. I have been actively collaborating with the LBRY Foundation leadership for over a year. They have been consulted on every aspect of this project, have formally approved the proposed integration, and view its completion as a key step forward for their ecosystem. This grant solidifies an already strong and established partnership.

Development Information

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

Leave a link where code will be accessible for review.

Do you agree to submit monthly progress reports? Yes

Contact info

Email: [email protected]

2

Thanks for your proposal to The Sia Foundation Grants Program.

After review, the Committee has decided to approve your proposal. Congratulations! They’re excited to see what you can accomplish with this grant.

We’ll reach out to your provided email address for onboarding. This shouldn’t take long unless your info has changed from last time, but you may still need to adjust your timelines.

Note: you will need to update your milestones to match the revised 25th of the month reporting expectation, but we will resolve this during onboarding.

3

Unfortunately, my report will be delayed by probably 1-2 days. Milestones for this month are completed, but I need to create the CLI demo and write some documentation per the grant development guidelines.

Thanks.

4

Thanks for the heads-up @pcfreak30 - please note given the American Thanksgiving holiday the deadline for reports in order to allow adequate time for review is Dec. 1 at 10am ET.

5

November Progress Report Form

What progress was made on your grant this month?

Please summarize your progress in 3-5 sentences or bullet points:

  • Forked LBRY’s DHT and python daemon
  • Created liblbry protocol library
  • Created portal-plugin-lbry
Milestone Task Pull Request(s) Additional Notes
1: Build Protocol Foundation LBRY DHT #1, #2, #3, #4, #5, #6 Forked to add missing core DHT functionality: node/routing/contact management, validation, expiration, and critical goroutine lifecycle fixes
1: Build Protocol Foundation LIBLBRY Protocol Integration #26, #27, #28, #29, #30, #31, #32, #33, #34, #35, #36, #37, #38, #39, #40, #41, #42, #43, #44, #45, #46, #47, #48, #49, #50, #51, #52, #53, #54, #55, #56, #57, #58, #59, #60, #61, #62, #63, #64, #65, #66, #68, #69, #70, #71, #72, #74, #75, #76, #77, #78, #79, #80, #81, #82, #83, #84, #85
2: Build Portal Plugin Create portal plugin portal-plugin-lbry #1, #2, #6, #10, #11, #18
2: Build Portal Plugin Pin/Unpin a blob from the network over REST API #5, #17
2: Build Portal Plugin Upload a small file as a blob and access it with LBRY CLI tools #3
2: Build Portal Plugin Upload a large file as a blob and access it with LBRY CLI tools #4
2: Build Portal Plugin Use LBRY tools to upload a blob to the portal using the LBRY native reflector protocol #7, #8, #9, #14, #15, #16 Requires device (IP based) whitelisting in the API

Milestone Demo

Summarize any problems that you ran into this month and how you’ll be solving them.

Please summarize your issues into a few sentences or bullet points:

I ended up spending several days having to deep dive into the LBRY DHT to figure out why blobs were not being circulated well and why a server that it should pick up on, wasn’t being found. This ended with me having to both heavily modify the DHT to have more control over it, implement things like a full network scan (IPFS calls it fullrt), and several other changes.

The end result of this was finding the DHT is immature, and having to implement a fixed peer support the same as the python daemon/node to act as a fallback. I was able to confirm fetching from the DHT, but it is fairly unreliable at-present such it is not relied on solely for tests or the demo.

What will you be working on next?

Please summarize your development goals into a few sentences or bullet points:

  • Work on frontend integration/UI.
1 Like
6

Hi there. I have completed your grant review for this month, so this question is not related to justification or scoring. I wanted to ask it for the month two reviewer (could be me, could be someone else) and for the foundation’s general understanding of the real world use of your work once it is complete.

Have you spoken with the LBRY Foundation team about the DHT issue you described? Is this something they consider to be in their area to address? I realize this is outside the scope of your grant, and I am not suggesting it is your responsibility. Still, though, it seems to me like it could be important for the long term success and reliability of what you are building, and I wanted to understand whether there is interest or alignment from their side. If you don’t know or don’t want to assume on their part, that’s okay, too, of course! You had mentioned you’ve been speaking to them in your initial forum post, so I thought I might ask.

Thank you for your detailed progress report. It makes understanding your work very straight-forward. All the best!

7

Yes, I have been in pretty consistent contact with the CTO of the foundation during the entire grant and he is aware of what I have run into. The foundation is a group that is not the founding team, so… much of the community as a whole is having to learn what got left over after LBRY hit their own SEC legal issues and get the ship upright and stable again.

My POV is the reflector (upload) and peer (dl) protocols matter more (lbry.tech - We came from the future to help you save the Internet), short-term and in the longer term it might make sense for LBRY to go multi-DHT for distribution of CID’s. But that is my opinion, and I know the LBRY foundation is immediately interested in just stabilizing the network and community before improving anything. It is also possible the python DHT impl is better then the golang, but no real comparison was made on that. I know they (original team) were trying, at-least based on what I saw, to create a vanilla Kademlia DHT direct from the spec papers?

I had a discussion in the LBRY community recently more philosophically that is related referencing Quickstart - Iroh and how they make discovery modular, and think that may be a useful path more broadly. But all of that is long in the future of how LBRY evolves. ATM, I had to do the same compromises that LBRY itself does within their daemon based on reading the codes concept of fixed peers.

Also something to note is, because LBRY got disrupted due to legal issues, and the community is rediscovering what was left over, a lot of ideas from the whitepaper and in progress were just left unfinished? An example is they actually have BitTorrent tracker support, but its not fully there, and their creator economy system is currently more of donations then anything requiring pay to unlock.

I will be involved in the future with them o/c to improve what LBRY is since Lume will be an invested actor in the LBRY community.

I was not really expecting the DHT to be a problem myself, but I will assume LBRY just has more rebuilding to do.

Hope this gives some more insight.

Thanks.

2 Likes