Grant Proposal: Lume Web

Grants Complete
31

December Progress Report

Repos:

Progress:

Progress so far has been switching to the Protomux and Protomux-RPC libraries and building a new RPC protocol based off of it from the original RPC design. This has the benefit of enabling any plugin to define a custom protocol due to the new PluginAPI.protocols at relay-types/plugin.ts at 7c3c193b4ac571dd7e66a56e2289cfcb5c29d9ae - relay-types - Lume Web Git Service and relay-types/swarm.ts at 7c3c193b4ac571dd7e66a56e2289cfcb5c29d9ae - relay-types - Lume Web Git Service

The entire PluginAPI has been redone as well and now supports namespaced events via eventemitter2 relay & plugin wide. Example: relay/plugin.ts at 1b78d0e696f57520fb717d839c648e400d7bbe83 - relay - Lume Web Git Service

Next, various DHT libraries have been created and will likely continue development. It is still being determined if all will be used, so testing is needed to determine the best RPC cache performance strategy.

The RPC client side is split between two packages. The rpc which overrides a few things from protomux-rpc, and rpc-client, which used to be dht-rpc-client and has been near-completely rewritten.

Several DevOps packages/repos have been created for CI that are docker tooling or other automation and are deployed and hosted by the Git server itself (Gitea).

Next, I have started on a peer discovery system that is very simplistic in design and modular. I started with what felt most common sense, BitTorrent, but utilizing the DHT BEP44 spec did not work in the browser because the relay needed a WebSocket proxy. Using torrents for this would be too easy to DDoS and abuse the tracker systems based on a dummy INFOHASH, so this is being abandoned but not deleted since it can still serve use outside the browser, even if that’s redundant.

The first helpful peer discovery source as I call it, is IRC. There are IRC servers that support websockets now! This means browsers can directly talk to a supported IRC network. Lume has found an initial IRC network willing to partner with and host the project and is fully informed of our mission.

At the core, all a discovery source does is return a host and port for a given pubkey. So you could theoretically go as far as using snail mail to “dial in” to the network. In the future, I look forward to finding many out-of-the-box/unorthodox methods to enable censorship resistance. As long as the browser can directly connect and do so without an account, API key, or security restrictions, it can be used as a means to discover a peer/relay.

Lastly, work has started on a registry relay plugin. This will replace the Sia registry for everything. The Sia registry may find use in the future, but as it is very niche and economically expensive at scale, it can only have very targeted use cases. What is being designed is an implementation of @redsolver’s registry system in S5, which itself is still a WIP. This is DHT based, and it is expected that paid sia portals and other actors who can afford to host some or all registry entries will be the ones to take on the burden.

The plugin will support Memory, LMDB, and Redis backends.

One final thing to know is Lume is now operating with BIP39 and BIP44 and has registered a coin ID at Add Lume Web to SLIP-0044 by pcfreak30 · Pull Request #1469 · satoshilabs/slips · GitHub to ensure adoption and interoperability with the industry. Lume will not be using “MySky” in its current form, and anything moving forward will just be a “Lume Web” account. Specific components or approaches of MySky tech may be used, but they will only be internal details.

The coin ID was not randomly picked, so kudos to the person who solves the puzzle :wink:

Outreach

I have done outreach to a few early projects to make them aware of Lume Web and the tech being built to onboard and partner with them in the coming year or later. One established naming project also outreached to me.

What’s next

Continue developing the registry plugin, refactor ecosystem libraries as needed, and then start on the browser side of development, which will require much rebuilding to shift to the new primitives.

It has also been confirmed by @nemo that getting trustless, A.K.A. verified streaming will be possible in sia. S5 currently uses blake3, and while it has been stated that blake2b is possible for this, blake3 would be the ideal route and ensure unity given its nature and the GitHub - oconnor663/bao: an implementation of BLAKE3 verified streaming library.

The sooner this can be ready, the better for the project.

Renterd will either need to be forked, or, if possible, a plugin system created so projects such as Lume or @mike76’s Sia Satellite can extend without forks or needing to use the renter as a library.

The direction of Lume is pivoting such that almost nothing will be compatible with what I now consider Skynet v1. S5 is doing the same and is breaking compatibility. The future “Skynet” idea will likely turn into a fork as a Layer 2 project with a unique name. Those details are still undecided, but it is clear Skynet is dead in its current form, and only the bones, if any, will be picked.

As such, future timeline plans have changed such that there will be no plans to maintain the existing portal software after the hard fork or keep uptime for it. Two parallel systems will likely exist. The new software can be ported to the Skynet v1 portal stack to maintain continuity at a fundamental level, if practical. Otherwise, the portal will be shut down until it is ready, which will also mean partial Lume downtime.

The current primary focuses of Lume as of now are:

  1. Web3 Hypercore P2P network and related ecosystem software
  2. Browser extension and related ecosystem software
  3. Educational and Community Sites
  4. A new web portal software stack

The portal stack will overlap @mike76’s Sia Satellite or use some of the code. It is too early to say. This may also become a project for 2024. But it will be required for Lume as a network to function since web accounts will use sia for the browser extension. If it is done this year, it will take priority over the extension work since it is effectively the backend service that the browser needs to save data. The extension will have already had its initial release.

Overall these unknowns are the bright red line initially outlined for Q2 of 2023 (this year now) on where things may go crazy.

There have already been many bumps in the road, and many more are expected, given the unknown. The overall vision and goals of the project are the same, but how we get there has changed and may continue to change to ensure we can get the best outcome.

This concludes my report :upside_down_face:

32

Thanks! The committee appreciated the extensive update and is pleased with your progress.

33

January Progress Report

Repos worked on

Progress:

Progress this month has felt somewhat slower, but some crucial achievements have been made.

I successfully got Handshake SPV (HSD node) to sync over the P2P network to a full node using a new library that acts as a SOCK proxy. This is very important as it will form the basis (with PluginAPI.protocols) for other nodes (blockchain and non) to communicate/bridge on the network. This took a while to do (and slowed me down) because, like sia, the node takes time to sync before I could proceed. I attempted to shortcut it, but I have found that future work on the HSD node software will be needed to improve the sync process (not utreexo) for relay operators, as this is a critical aspect of deploying a node for web3 users. This may be through supporting a bootstrap download of the chain.

Next, I got peer (p2p) node discovery working over IRC. This is the first of many peer discovery methods long term. This is also specifically working in the browser. It takes around 1 second to do the discovery actions.

Next, I have rewritten much of the p2p browser code (kernel modules and related libraries). I have also started forking some of the Skynet kernel code. However, not all of that will be used as a fork, possibly until after the L2 has been completed.

Other things done are creating misc library helpers and other aux client code.

Next:

  • Continue browser development.
  • Get Handshake syncing and querying in the browser, then work on the DNS system and integrate it back into the extension.
  • Start on UX development when far enough along, and hopefully have an MVP out by the end of Q1.

This concludes my report

34

Thanks @pcfreak30! This is a great report and we’re going to model our monthly report criteria after this moving forward.

35

Thanks pcfreak30! Going forward, please submit your monthly report ideally by the 2nd of every month. Thank you!

36

February Progress Report

Repos worked on

Progress:

I have gotten handshake syncing and querying fully working in the browser. This includes querying it with the DNS layer/kernel modules.

Significant work has been done on the DHT communication as well as the related client libraries that are used for DHT and DNS. Redundancy/resiliency and connection retries/reconnecting were added to the different layers up to the HNS module itself.

Next, I have started researching and implementing IPFS. I actually got a decent-sized roadblock with doing this and got no real help solving it. I made a breakthrough today (3-2-23) and so I hope that can get finished this month.

Next, I started on a website rebranding and redesign via contracting. This will hopefully finish within 1-2 months.

Next:

  • Implement IPFS support
  • Implement ETH RPC support and ENS DNS
  • Test HNS, IPFS, and ENS together and integrate them into the extension
  • Work on extension UX once all subsystems are functional

A Q4 release may not be hit due to the roadblocks encountered, especially if ETH takes 1-2 weeks of work to figure out.

This concludes my report

37

The committee has reviewed your report and is pleased with your progress. The committee did note that they would like to better understand Lume’s progress as it relates to Sia, as this report was largely unrelated to Sia development.

38

So let me clarify some things:

  • The kernel modules are stored on sia via my portal. Given the current ecosystem crash with Skynet and renterd being made, I plan on whitelisting specific kernel CID’s to have the extension modules operate. So sia is being used practically in the backend. This has not changed from how Taek designed it.
    • Nearly everything in the extension is powered by the kernel system. IPFS, HNS, ENS, DNS, IRC discovery. All modular logic is done like this vs. embedded in the extension code itself. So sia is storing nearly all code that is powering the system.
  • I have decided to not do anything related to web3/lume accounts on the portal or further develop the sia integration on the L3 browser side given the hard fork and the fact that I have to build a new L2 and completely dump Skynet v1. It is a waste of energy to do so. I am waiting on renterd to be in beta too.
  • Much of what is required right now is at high level to interop with the wider ecosystem to achieve Lumes goal and to promote sia in the industry. HNS, IPFS, and ENS will be the base minimum required for a usable web3 extension and experience (DNS) for a tech demo/prototype release. Other integrations will come but at a later time. Playing that by ear mostly.
  • I will be getting the extension out, the relay out, and marketing sites for awareness for both of them. That is the current roadmap.
  • After doing this, I will be switching back to building the L2 layer, building the client code needed for that, and wiring that back up to the L3.
  • I am taking this route to stick to getting the extension out as planned in an MVP, as a semi-centralized service, with the expectation of things breaking in a few months and having to transition to the new tech being built by the foundation, me, and the community.
  • I will also be looking to see at what point the community/education/news sites make sense this year. Given the rapid ecosystem and community changes, I am focusing on getting the extension, basic relay, and new branding/awareness for the project done before asking what is next.

I hope this makes it more clear why I am not directly focusing on sia right now, even though it has involvement and will be a foundational aspect of the project mid to long term, as I originally proposed in my grant.

Kudos :wink:

39

From a technical perspective, great, I’ll let other delve into the usability of this. What I want to know, is how you’re going to attract users to pay money?

Early on in the Sia project, Lightspeed essentially laid out a business model that at the time was Filebase. We were then and still are too busy to take creating something like Filebase, so we’re very excited they did. In the end though, the thing they did that others have not, is (a) have a way to pay that users already know and use (credit cards and paypal etc) and then (b) give them tools they’re use to using to interface with the medium of storage.

These two things we said from the beginning would be required for Sia to be successful and they failed to do those things, and still fail to do those things. Providers who have, have gained traction and customers.

Lastly, of that $80k, how do you intend to the market the end result?

1 Like
40

Thanks for asking what’s often seen as the elephant in the room.

I did touch on this in my original grant, and just to be clear in case you only skimmed this thread, my grant was approved and I’m several months into development.

First, know that I’m largely anti-VC based on my own experience and observations from the past few years. I think VCs are a good route to build tech fast, if they do not end up controlling it, the IP, or have direct power. They often blow up though, so the risk in some cases is more theoretical and principled. I might compare that with the AI wars we have now where everything is closed source in a few AI labs. The tech rapidly evolves, but it stays owned by the few.

Now. I know every VC crypto/web3/etc company does develop in the open thanks to the foundational ethos, but in exchange, they often find other means of control or keeping power or ROI’ing that’s not in the interests of the community.

This is not a hard rule that VCs are evil… But it is a guideline based on what I see as the crypto/web3 VC playbook, so there are going to be exceptions and good-faith VC-funded projects. But there are very few of them IMHO.

Due to this… and the fact I come from a Linux FOSS background in my views, I just rather avoid all that shit show altogether and stick to the community to ensure what we build is by and for the community.

So, I am doing things with the community giving me a chance to make their investment, if you want to call it that, give them something that can solve a LOT of issues with Sia and the wider ecosystem.

And yes, I am aware of a lot of Sia’s history, drama, etc. I was not involved in the early days but after a year of being initiated into the cult… I mean community (just kidding guys :P), I have found all of Sia’s skeletons and why Sia has had a rough decade.

That said, unlike what many seem to have made into a meme, sia being allergic to marketing, I am realistic and I straddle both the worlds of Web2 and Web3.

Sia to an extent, I see as always a background player, and marketed to bigger players, and power users, but not retail.

So as for the how? One large route is FOSS/grassroots marketing. By creating public good services that are also hosted on sia, or store data on sia… The project solves a number of wider issues that start with education. In the process, Lume Web as a brand creates awareness for our mission and starts the needed network effect.

This is why I have invested in many web3/blockchain and ICANN assets. Creating open, community-driven, and community-built resources that serve as onboarding for new users and those skeptical or frankly calling us all scammers, as well as advancing the education of those in the community by crowdsourcing those who can help, but that may not be devs.

I have already spent a good % of the foundation grant on a new project brand/logo, website, and 2 other marketing websites, one for users, and one for those who want to support/host the infra of the new web.

I have a lot more planned as well. I have long-term ideas too, but they can only happen once Lume is actually fully working.

As for the business model of Lume as a community-focused business, I will be starting at some point (no ETA) by simply offering web accounts (private data encrypted by your identity key, which I can never decrypt) on the portal for a small yearly fee, and scale the storage plans offered as the project grows. Eventually, it will be webapps (aka dapp) too.

So simply put, web3 hosting services.

This is one prong of sustaining the project long-term outside having grant funding.

The other is that I will be creating a web3 domain registry with assets that I have acquired on Handshake. This, of course, requires the tech to be stable for the domains to be useful, just like in the current web.

I may get other revenue streams from services, but that’s more of an unknown, unknown right now.

I have also disclosed all my plans on the longer-term business aspect to the foundation and gotten guidelines of what they are ok with. So I have been fully transparent with the community regarding my plans and actions.

I hope this answers your criticism, which based on Sia’s history, is warranted to ensure we don’t fall into the same traps with failed experiments and some community members who have left or are exiled due to their own actions.

Kudos!

1 Like
41

March Progress Report

Repos worked on

Progress:

Development

This month has been focused on getting IPFS completed, getting IPNS support, getting ETH support, as well as getting the supporting libraries updated. I have also been focused on marketing/branding and website design tasks.

IPFS is working and currently uses both delegated routing and DHT. It uses the relay as an outbound socks proxy, and since libp2p encrypts with noise as does hyper, it is a black box and you cannot see what is being requested.
IPFS has over 40 bootstrap peers to mitigate issues with finding content outside the delegated routing nodes by IPFS.

IPNS was much simpler to implement and uses DHT to operate. It has its quirks though that will get ironed out later.

IPFS also stores the data to indexeddb in the browser, so when you fetch something, it can become instant afterward.

Next, ENS. This turned out to be a very hard issue to deal with, especially since I wanted to use the helios client in rust and hit MANY roadblocks. rust and wasm still have a lot of maturity to do with interacting with JS.

So my concerns about ETH taking 1-2 weeks turned out to be a reality.

Even after going through all of that, I ended up forking the code into a new branch and using a TS (TypeScript) client called kevlar. I took a bunch of its components and ended up creating a custom light client implementation between the relay and the browser. I also ran into issues with slow RPC and had to hop providers a few times after realizing that it was not the code.

After this, I created a new ETH DNS resolver and client library, which should be able to function as an ethers.js provider in the future. The ETH module and the DNS resolver are separate kernel modules.

Design, Marketing, and Websites

This month has been spent on designing lumeweb.com, and web3extension.io. web3relay.io is being designed as well but will be getting re-prioritized based on the upcoming tasks.

The project has, however, gotten its new branding finished to go with the new sites. They have been designed together and I am excited to see the new image of Lume launched soon.

The files of all branding (SVG) will be published on the GIT server by the time the sites launch, including the site code too, of course (and figma files). The project discord server was involved in the whole process of the design work and gave feedback. A Twitter poll was created too, to pick the final logo. I also invited the Sia community to come and look.

Next:

April is going to be a busy month:

  • I have started working on the extension code again
  • UX design of the extension will start this month, and hopefully, finish, but work may drag on into May. The UX is a large unknown on where things will go, and what engineering will be required to support the UX.
  • Development of the sites will start this month and hopefully, most will get finished based on the designs.
  • Relay development work is needed as is some possible DevOps work, but this might get pushed to May as well.

This concludes my report

1 Like
42

The committee is overall pleased with your proposal and the amount of work being completed towards the Lume ecosystem, but is still excited to see Sia-specific (core software) work resume as you mentioned directly interacting with renterd soon. Thanks!

Regards,
Kino on behalf of the Sia Foundation and Grants Committee

43

As soon as I can get the initial software out I will, as that’s the next step big picture. It does not mean I won’t do work on the extension/relay while doing the portal, but it does mean the portal is the next required puzzle piece.

Additionally, I have ideas on how to use the lume network to build the sia portal. So that means all hypercore/relay work becomes sia development.

Kudos.

44

April Progress Report

Repos worked on

Progress:

Development

This month started with a painful roadblock on the P2P networking stack inside the web browser that took roughly a week to solve.

After that, I ended up doing refactoring changes to the libhyperproxy library to support two modes. One where it has a single socket to talk over, and another where the client can request an outbound socket to any allowed port. This was adapted from the IPFS work.

I then took that and rewrote the HNS support to use this and use the network as a DHT proxy like IPFS, rather than have the relay run a full node.

The result from this lower-level work means being able to proxy sockets in for any service, both as single communication and in a DHT or similar style.

Next, I was able to get the extension code back up to speed using the new systems. Though I did have a fair amount of issues getting things to stream over correctly. I also had to add in some basic caching for IPNS as it’s still fickle.

However, on April 12, ETH hard forked which broke the ENS support. Upstream fixes have been made, but it is on the to-do to port them over to get ENS running again.

Other miscellaneous library changes have been made as well.

Next, I have also done work in DevOps and am outsourcing some services. CI is handled now by CircleCI as a FOSS project, and package management is handled by CloudSmith, also as a FOSS project. I decided that right now the priority was ensuring the code could not be subject to censorship, but could accept the other infra to be censored since the time/effort to get them fully operational does not make sense right now.

Next, I have also switched development practices to try and use https://semantic-release.gitbook.io.

Next, I have started the development of the portal and hope this will be quicker than expected due to the existence of an object API. This will be an all-in-one binary with a plugin system in Golang.

This has been started earlier than expected due to my team having to work on the other project priorities (design and websites) which is a blocking issue for me.

Lastly, I am also actively attempting to port or otherwise get running blake3 verified streaming in Golang. This may cause a large delay since I frankly have no idea what I’m doing and have to figure this one out slowly.

Design/Websites

Development work has been started on lumeweb.com. This is expected to be ready this month and will launch with the extension release. web3extension.io will get built after, and has equal priority with the extension work.

UX work on web3relay.io has been completed as well.

UX work on the extension started and has mostly been completed, subject to community feedback.

Next:

May will hopefully have the following:

  • lumeweb.com completed and ready to launch
  • web3extension.io completed and ready to launch
  • The extension ready to launch
  • More development work on the portal in between the above. Will hopefully have blake3 figured out in May, assuming I have the time.

This concludes my report

45

Thank you for the report, everything looks good so far!

46

May Progress Report

Repos worked on

Progress:

This month I have had to switch to only the portal development priority as all browser and website development were roadblocked by labor delays. I had to hire a new front-end developer and am now playing catch up to get the browser and marketing side of things up to speed.

The hardest issue with the portal so far has been blake3 and BAO support in Golang and I have had to jump through many experiments. @nemo has, however, got the core basics ported to Golang, and I am awaiting the rest to ensure compatibility with S5 and other ecosystems that may use it.

Some of the core API/db structure of the portal is in, including accounts, and auth, but not much has been heavily tested yet. Basic file uploads and downloads work. TUS (large file uploads is working as well), however, it needs a lot more stressing and finding bugs.

TUS is using a local cache/buffer approach rather than streaming direct to the network based on the community advice from Filebase. This is expected to evolve over time.

This month has been an odd one development-wise, so the amount of code work in git reflects that since a lot of other tasks had to be done instead.

Design/Websites

All website and extension designs are done minus any tweaks needed or community feedback. lumeweb.com is nearly done and will be having content and any needed improvements completed this month.

Next:

June will hopefully have the following:

  • lumeweb.com ready to launch.
  • web3extension.io ready to launch. web3extension.com will be a redirect.
  • Browser extension ready to launch as an MVP demo that uses a server I host as a relay and the Skynet v1 portal for browser code downloads. This might go into July depending on any complexities, but hoping it can get completed this month.

web3relay.io will get built after the extension as the marketing and relay release for the P2P net is currently a lower priority than the end user release.

This concludes my report

47

Thanks for the monthly report PCFreak!

48

June Progress Report

Repos worked on

Progress:

Core development

This month has been another mixed bag of unexpected priorities, but lots of progress has been made, even if it wasn’t the progress predicted.

Portal

The portal has had further development. First renterd has been split away and is no longer embedded into the software. This is for both simplicity and enables scaling possibilities in the future.

Large code refactors have been done, basic pinning support has been added, and many account, db, and TUS related bugs have been fixed. Additionally, a proof API endpoint has been added for trustless download verification.

Browser

I ran into a fair number of issues due to technical debt on Skynet v1, so I decided to not waste time on getting it to work and instead pivoted and focused on getting the browser code compatible with the new portal system/renterd. This actually turned out to go much faster than I thought as the largest change was just the uploads, downloads, CID’s and verification of data.

Initial libraries libportal, libweb, and libkernel have been created for browser/frontend development. libportal Has a golang-wasm based streaming verification for BAO based on @nemo blake3. This is not yet compat with the rust, and requires that be worked on upstream by nemo to make use of either a golang or rust client implementation.

libweb is equiv to the former libskynet, with no dedicated node.js version. I decided to make it isomorphic since most use cases will always be using bundlers which can just polyfill or exclude NPM code. Much of the old code has been ported into the new library as well.

libkernel is equiv to both the former libkernel and libkmodule and is isomorphic too. It is combined for simplicity.

Other things to note are that work has been done to get ETH support fixed, but upgrading to the latest hard fork is untested.

CI/Tooling

More time than I would have liked has been spent on further CI and tooling related development. Due to the fact Circle CI has frankly stupid limitations that require manually managing some secrets/passwords/keys per repo vs at an org level, I deemed it was going to become a liability and migrated back to Github Actions. This was a security risk & admin mess waiting to happen if any secrets were compromised and needing to manually update 20-50 repos with no API to automate.

Most repos have been setup to use both the NPM presetter tooling and semantic-release, but this migration is still ongoing. Many packages have been forked and customized for my needs to re-use across the project. This will ideally also form a future foundation for scaffolding new plugins/modules/integrations.

One notable tool I will mention is publish-kernel-module which is a very crude CLI tool but is fully working to upload modules to sia using an ed25519 private key to login/register.

Most packages are being auto-published now to https://npmjs.com under the @lumeweb namespace.

New Portal

A new testing portal has been deployed at alpha.web3portal.com This portal is on a small server compared to web3portal.com and is subject to being reset at any time right now. As the portal software currently has no UI, only way to use it is via API.

There are currently no anti-abuse systems in place outside the fact everything is account-only. Any abuse of this will just force me to divert time in a cat-mouse game to stop it, wasting time away from development. So please play nice :).

Design/Websites

lumeweb.com is roughly 95% done, and web3extension.io is also completed subject to further content review. I have had further labor delays/logistics issues and may have to find a new frontend developer again soon’ish.

The UX of the extension has been coded/ported from Figma and is ready to be integrated. A decent amount of work though will be needed to merge all of it together.

Next:

July will hopefully have the following:

  • lumeweb.com ready to launch.
  • web3extension.io ready to launch.
  • Browser extension ready to launch. Given the new pivots… this would be on-top of the new portal software and all major technical debt would be completely gone.

This concludes my report

49

July Progress Report

Repos worked on

(Given the number I am not making them links)

https://git.lumeweb.com/LumeWeb/extension
https://git.lumeweb.com/LumeWeb/hosted-kernel
https://git.lumeweb.com/LumeWeb/hyperswarm-web
https://git.lumeweb.com/LumeWeb/interface-relay
https://git.lumeweb.com/LumeWeb/kernel-discovery-irc
https://git.lumeweb.com/LumeWeb/kernel-dns-client
https://git.lumeweb.com/LumeWeb/kernel-eth
https://git.lumeweb.com/LumeWeb/kernel-handshake-client
https://git.lumeweb.com/LumeWeb/kernel-handshake-node
https://git.lumeweb.com/LumeWeb/kernel-ipfs
https://git.lumeweb.com/LumeWeb/kernel-network-registry
https://git.lumeweb.com/LumeWeb/kernel-network-registry-client
https://git.lumeweb.com/LumeWeb/kernel-peer-discovery
https://git.lumeweb.com/LumeWeb/kernel-peer-discovery-client
https://git.lumeweb.com/LumeWeb/kernel-protomux-client
https://git.lumeweb.com/LumeWeb/kernel-rpc-client
https://git.lumeweb.com/LumeWeb/kernel-sandbox
https://git.lumeweb.com/LumeWeb/kernel-swarm
https://git.lumeweb.com/LumeWeb/kernel-swarm-client
https://git.lumeweb.com/LumeWeb/libethsync
https://git.lumeweb.com/LumeWeb/libhyperproxy
https://git.lumeweb.com/LumeWeb/libkernel
https://git.lumeweb.com/LumeWeb/libportal
https://git.lumeweb.com/LumeWeb/libweb
https://git.lumeweb.com/LumeWeb/peer-discovery-irc
https://git.lumeweb.com/LumeWeb/presetter-kernel-module-preset
https://git.lumeweb.com/LumeWeb/presetter-preset-rollup
https://git.lumeweb.com/LumeWeb/presetter-relay-plugin-preset
https://git.lumeweb.com/LumeWeb/protomux-rpc-web
https://git.lumeweb.com/LumeWeb/relay
https://git.lumeweb.com/LumeWeb/relay-cfg
https://git.lumeweb.com/LumeWeb/resolver-module-cid
https://git.lumeweb.com/LumeWeb/resolver-module-eth
https://git.lumeweb.com/LumeWeb/resolver-module-handshake
https://git.lumeweb.com/LumeWeb/rpc
https://git.lumeweb.com/LumeWeb/rpc-client

Progress:

Core development

This month has been extension/browser, relay, and infrastructure stack development.

Extension

The UX has been mostly been integrated with the extension. There are still some issues to fix, and things are still buggy/quirky. The UX is currently coded in React to ensure development is fast due to the mature ecosystem, but could change in the future.

The extension also notably uses X25519 (ECDH) key exchange such that when you sign in/create an account it encrypts the key data over postMessage to the backend part of the extension where it is put in localStorage. This makes the exact ed25519 key used agnostic in the long term, since the backend does not compute the master key.

ETH

ETH has been fixed and is fully working again from upstream changes. This has been mostly a rewrite in the process and now uses the libethsync library.

HNS

HNS DNS has been rewritten such it take advantage of HSD’s internal DNS code and uses the libhyperproxy to pipe DNS (port 53) requests over the relay net, when no other request type (such as HIP5 or content) can be met.

CID Loading

A new simple resolver resolver-module-cid has been made which enables [CID].ipfs.lume and [CID].ipns.lume special subdomains. These require URL friendly CID’s such as base32. This will enable generic IPFS access without a domain, while staying trustless/p2p.

Dev Ops and Tooling

Further development has been made on developer experience (DX)/CI tooling by creating a presetter config for relay plugins and working on the kernel preset as well as other presets.

A new tool has been created as well kernel-sandbox which is a refactored version of a tool I have had for a while, and enables you to run kernel API/RPC commands in chrome to test and debug modules with a new pubkey + portal account.

To mach this hosted-kernel is also released that enables a hosted version of the kernel outside the extension, mostly for development for now.

Kernel

Development has been done on the kernel framework as well mostly to remove the need for using eval and ensuring libkernel supports the multiple environments it needs to be in. It has been extended as needed for the extension code.

Design/Website

No work has been done this month on the websites.

Next:

August will hopefully have the following:

  • lumeweb.com ready to launch.
  • web3extension.io ready to launch.
  • Browser extension ready to launch.

This concludes my report

50

Hello @pcfreak30,

Thank you for your July progress report! It looks great.

The Committee has voted to create a progress report template which should make it easier for both you, the Grantee, to provide monthly updates as well as to enable the Committee to quickly review progress without spending too much time on minute details.

For August’s progress report (which should be provided in September), please follow the template outlined in this post: About the Grants category - #8

Thank you for your help and cooperation.

Regards,
Kino on behalf of the Sia Foundation and Grants Committee