Standard Grant: Lume Web 2025

Grants Inactive
18

Progress Report for April

What progress was made on your grant this month?

  • Continued chipping away at the webapp framework and the Go aspects for plugin loading.
  • Made headway on the UI component library – building those essential legos.
  • Spent some time wrangling miscellaneous JS tooling.
  • Knocked out about 50% of the abuse webapp frontend.
  • Did a bit of recon on the Bluesky ecosystem and the current state of PDSs.

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

This month’s main blockers were some unforeseen engineering timesinks, mostly tangled up in React and getting those UI legos just right. Here’s the breakdown:

  • React Wrangling:

    • Hit several low-level architecture snags while building the report webapp.
    • Tooling Headaches: Module federation tooling sent me on a few goose chases. Had to sink a fair bit of R&D time over the last month or two to get it cooperating. The hope is to eventually migrate to Rolldown, as they’re building native MF integration which should simplify things.
    • Routing Shenanigans: Ran into issues with react-router, navigation, and how they mesh (or don’t) with module federation. Specifically, index routes aren’t playing nice, forcing manual layout management in some spots :upside_down_face:. I’ve patched things up with workarounds for now, but this needs a proper fix down the line to use the router correctly.
    • Context Fun: Also navigated a variety of fun issues related to React contexts along the way.

  • UI Component Deep Dive:

    • As mentioned before, I’m building out reusable UI legos. The long-term goal is clear: need the ability to spin up tables, dialogs, and forms rapidly without repeating myself (DRY!). Future plugins, like file managers, will also build on these primitives (especially tables).
    • To achieve this, I’ve been investing time in creating solid components and React-based APIs (like useDialog) to make future UI development faster and more consistent.
    • Where the Time Went: Honestly, most of the energy this month poured into this lower-level UI foundation rather than getting stuck on specific application logic. Given I foresee potentially up to 10 different portal plugins, each potentially needing its own web UI, this foundational work is crucial. My experience building monolithic apps tells me this upfront effort saves massive amounts of time avoiding repetitive basic UI builds later.
    • Looking Ahead: Assuming no more surprise React ambushes (famous last words, especially since I’m kind of inventing the plugin system integration as I go), I don’t think the abuse app has much longer. After that, porting the other UIs (Dashboard, IPFS) to plugins should be quicker.
    • The Vision: Over time, this library will likely mature into a more formal design system for Lume, similar in spirit to what the Foundation is building for the Sia apps.

To give the committee a concrete look at the components that have been taking up this foundational effort, here are direct links to the code as of today:

On a related structural note: I’ve also consolidated the apps down. Now there’s primarily just the portal-app-shell (https://github.com/LumeWeb/web/tree/2f5e8b1ad5220dc735582317d3bf454750eab467/apps/portal-app-shell). This shell can be configured at build time (basically just needs a page title and app name/ID) to become any of the needed webapps, as the actual functionality gets loaded via web plugins.

I know this section got lengthy, but I wanted to properly communicate the technical details behind the project delays, the reasoning for the decisions (especially the UI component investment), and what exactly has been consuming time.

Links to repos worked on this month:

What will you be working on next?

  • Finish the remaining abuse milestones (frontend, admin, and testing email processing & routing).
  • Get the existing dashboard and IPFS webapp code migrated into plugins.
  • Circle back to IPFS functionality and fix anything broken during the current refactoring chaos.
  • Dive deeper into Bluesky research and testing:
    • Current plan is leaning towards using rsky (https://github.com/blacksky-algorithms/rsky), a Rust-based PDS. Why? Honestly, the thought of managing distributed SQLite, even with Litestream, gives me a bad gut feeling about DevOps pain… and my plate’s pretty full already :P.
    • Need to grok the atproto data structures to map out the plugin plan. This likely means running both rsky and maybe the reference PDS side-by-side to experiment and learn.
    • rsky uses Postgres and S3-compatible blob storage, which sounds like a decent foundation to integrate with the portal.
    • The approach will likely be an atproto portal plugin that communicates with a separate PDS server (like rsky) via an API. Embedding isn’t really feasible since there’s no mature Go PDS :cry:.
    • Heads up: rsky is actively developed, so some Bluesky features might be in flux or missing (e.g., I saw OAuth support is still being worked on). The good news is the Blacksky project seems to have solid community momentum and funding (https://opencollective.com/blacksky). I believe the critical PDS functions are mostly there, but I’ll re-evaluate this path if major roadblocks appear.
  • Take a look at the billing and S5 tasks list and figure out what’s feasible to tackle soon.
  • Gather user feedback – if I can get updated systems deployed in May. This might slip depending on progress.

As requested previously, here’s a very short, unedited video demonstrating some tangible progress. It shows the abuse report submission flow working. Next steps for this feature are implementing login to view submitted reports, plus adding commenting and file upload capabilities (likely using uppy).

Apologies again if this report feels long, but transparency about the work, the roadblocks, the reasoning, and the path forward felt important. Hoping the foundational work being laid now pays off in faster progress soon!