Introduction
Project Name: Lume Web - IPFS Portal
Name of the organization or individual submitting the proposal: Hammer Technologies LLC
Describe your project.
This project has the goal of getting a polished, working service for IPFS hosting.
Background
The Lume Portal has been around since 2024 and Lume as a whole received three grants already. The portal consists of several plugins (like IPFS, S5, abuse, billing, admin, dashboard), and the core system. These plugins are in various stages of maturity due to both time constraints and several past re-architecture efforts being required.
Effort has already been spent to rewrite the IPFS portal plugin (the golang side). The efforts of this grant request is a mix of frontend efforts, and working on any remaining issues with the go plugin. As it stands, the plugin could be used via swagger/API and the basics would work.
This grant proposal aims to get the dashboard and IPFS plugins ready for a zen testnet beta.
Current State of the App
The image above illustrates the current state and starting point for this grant’s work. It shows the core Lume application shell after a user has successfully logged in. The foundational backend elements are in place: a working Go backend, user account management (registration, login, 2FA).
As annotated in the image, the main content area is intentionally blank. The primary goal of this grant is to build out the two key feature plugins—the user Dashboard and the IPFS Support—which will populate this space and create a complete, user-facing product ready for beta testing.
Some may also ask the question Did you not already do IPFS?. Yes, I did in 2024 (Standard Grant: Lume Web 2024 - #55 by pcfreak30). But, as major internal changes to the portal happened, I rewrote the IPFS plugin very recently as stated before, and I completely re-did how the webapps work… Effort is required to finish the IPFS integration in the new version of the portal, as well as the user account area, and bring this to something polished thats more than a MVP that the community has been vocal about.
How does the projected outcome serve the Foundation’s mission of user-owned data?
This will enable IPFS support for uploading users data to the Sia network. For users, this will mean they can use any app in the IPFS ecosystem, or any app in the Sia ecosystem that uses IPFS as a datarail, and have a reliable pinning provider. They of course, can also use the portal’s webapp as well.
Two Sia grants are planning to integrate with Lume when viable, Small Grant: DecaNotes - Private decentralized notes and Standard Grant: SecureSphere Decentralized Vault. Both are expected to via the IPFS Pinner API (helia).
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 Salary for Derrick Hammer
- $670 - R&D Infrastructure
What are the goals of this small grant? Please provide a general timeline for completion.
- Month 1: Rebuild the portal dashboard
- The shell for all apps is in place, but the dashboard experience needs to be re-created and old react code from the legacy app ported where it makes sense to.
- Tasks:
- Ensuring all account functions work correctly
- Ensuring a smooth UX
- Remove any serious remaining bugs found in the process before we get to the upload components.
- Get community feedback on the UI.
- Validations for this milestone will include:
- Can you register?
- Can you login?
- Can you reset your password?
- Can you setup 2FA?
- Can you update your profile info?
- Can you upload an avatar?
- Can you change your email?
- Can you reset your password?
- Can you manage API keys?
- Is the app responsive on mobile and tablet devices?
- A best effort basis will be made to catch all responsive design issues, but as this can be a very large matrix, it will be only reasonable to test the most popular devices and platforms. It is likely the community will continue to find small issues over time, but the goal is to get a polished UI.
- Month 2:
- Tasks:
- Build the upload UI, and the queue/operations manager UI.
- Ensuring we can upload small and large files properly.
- Ensuring we can browse the file manager, pin files, unpin.
- Use community feedback to find bugs in the IPFS golang side.
- Use community feedback to find bugs in the upload UI.
- Ensure compliance with GitHub - ipfs-shipyard/pinning-service-compliance: This repo checks the compliance of IPFS Pinning Services against the pinning spec · GitHub.
- Validations:
- Are we able to upload a small file (post upload, defaults to max 100 MB)?
- Are we able to upload a large file via TUS?
- Are we able to pin a file?
- Are we able to unpin a file?
- Are we able to browse and manage files via the file manager?
- Are we able to access a public IPFS gateway and view/stream the file?
- Are there any obvious UX bugs or is the UI polished?
- Is the API compliant with GitHub - ipfs-shipyard/pinning-service-compliance: This repo checks the compliance of IPFS Pinning Services against the pinning spec · GitHub?
- Tasks:
The end goal of this timeline is to get a polished service, in a zen beta status (not fully launched), ready for the Sia community to be able to use. The portal will talk to a renterd instance in the Zen network until it is time for live demand.
Lume will also submit itself to pinning-service-compliance | This repo checks the compliance of IPFS Pinning Services against the pinning spec as a compliant software/service and to the IPFS desktop this year, but that will not be considered as a milestone under this grant.
Potential risks that will affect the outcome of the project:
- Any unexpected issues with frontend development. I have done my best to proactively de-risk any frontend problems, but experience has shown me already you can’t predict unknown unknowns.
- Any issues with the IPFS protocol that I may not easily control. Over half of the IPFS protocol code base is a direct port of
fsd(thanks foundation
), and so I expect any issues I run into, fsdwould as well. - Any changes to renterd itself, however this is the least of my concerns since renterd is abstracted to a single class, uses the rest API (and has been pretty early on) and should be pretty easy to update.
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]
Any other preferred contact methods:
