Standard Grant: Lume Web 2025

Grants Inactive
22

Progress Report for June

What progress was made on your grant this month?

  • Created a MVP of the admin side of the abuse.
    • Please note that I am considering the abuse work done for now and will revisit it once priorities deem it important to do so.
  • Redesigned and rewrote the config manager subsystem
  • Redesigned and rewrote the event bus subsystem
  • Moved from dbmate to goose for DB migrations
  • Added full unit testing and integration testing to core portal services. Majority of tests are passing, with low priority issues to be handled at a later date.
  • Started on re-design of IPFS plugin, especially with the data model.

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:

N/A

List repos worked on this month with links to PRs and relevant commits:

What will you be working on next?

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

  • IPFS plugin
  • User dashboard webapp
  • Getting lumeportal.com ready for test users
  • Nostr integration

Grant Timeline & Q3 Focus

This section details significant shifts in our development timeline and priorities for Q3, driven by recent challenges and strategic considerations.

Current State & Adjustments:

  • Delays: Grant progress has been heavily impacted by the foundational rebuild of the webapp portal, which required creating a new architecture.
  • Abuse Plugin: To prevent further derailing the grant and keep core priorities on track, the abuse plugin MVP is being considered completed and will be evolved when required.
  • atproto (Bluesky) Punted: Due to significant project and engineering risks, coupled with high complexity and unknowns, atproto will be the last integration tackled in Q3.
  • Billing: While not part of my milestones, I am not expecting to be doing any sales this year as that requires a few weeks of work that I likely no longer have a buffer for.

Improving Development Velocity:

Despite the initial delays, we’re building momentum:

  • Stable Portal Framework: I now have a robust and stable Golang-side portal framework, including a powerful testing library that has already delivered massive gains in efficiency. This means portal-side development should take less time moving forward.
  • Helper Library: I’ll be creating a helper Go library during the IPFS plugin rework, which will significantly speed up the development of subsequent integrations.

General Development Observations:

Through this process, I’ve consistently observed three key patterns:

  • Webapp Development Challenges: Webapp development often takes longer due to immature and evolving tooling that lacks features like Hot Module Reload (HMR), slowing down iteration cycles.
  • Protocol Integration Core: The majority of integration effort lies in enabling the portal to communicate with a new protocol and completing any necessary database modeling. Once that’s done, the rest of the work is far more standardized.
  • DevOps Overhead: DevOps efforts requiring new infrastructure components can consume up to 10x the time of typical R&D. Improving this area requires its own dedicated research.

Revised Q3 Integration Plan:

My broad aim is to complete each integration within 1-2 weeks, though some may extend to 3. atproto is currently estimated to require the most time. The current priority order is:

  • IPFS (Target: Mid-July):
    • Will include the dashboard, file manager, and API keys.
    • Will be compliant with the pinner spec, allowing use with IPFS desktop via an API key.
  • Nostr (Estimate: 1-2 weeks):
    • Based on NIP-96 and NIP-98 (if thats deemed needed), this is the simplest integration as it’s fully HTTP-based.
  • LBRY (Estimate: 1-3 weeks):
    • Research indicates a need to extract and adapt code from the reflector.go project to create a new library for network communication. After that, development should be similar to IPFS/S5.
  • atproto (Bluesky) (Estimate: 3-5 weeks):
    • Highest Risk: This integration currently requires running a separate server, as a feasible Go port isn’t possible within a reasonable timeframe (even if the grant timeline were on track :cry:).
    • Operational Complexities: The TypeScript reference implementation uses SQLite databases per account, which poses significant operational challenges in a cluster environment.
    • rsky Option: As previously mentioned, rsky is a potential Rust-based alternative, but it’s still in active development.
    • Research Focus: This quarter will require substantial research to determine the optimal design and infrastructure decisions for this plugin.

Q3 Strategic Shift: Delivering Tangible Results

Responding to community feedback and looking ahead to 2025 grant obligations, I’m restructuring Q3 to focus on tangible progress that the Sia community can actively use. While the grant to date has centered on compliance and foundational efforts, Lume will be delivering concrete, usable results this quarter.

S5 Integration on Hold:

The one exception to delivering “most” integrations is S5, which is being put on hold. This was not part of the milestones. However, Due to significant, ongoing changes to the S5 specification, I cannot risk spending 1-2+ weeks (or more) porting s5.js into a Go version only to have that effort rendered useless by a “rug pull” from a rapidly evolving spec. While supporting Vup is a very large, long-term priority for Lume, it’s currently too risky to build on until the specification stabilizes and provides a clear, dependable foundation.

1 Like