OpenSats 270 day report #5
Description
Period: April through June 2024
Commits: ~150
During this period I:
- Created a new nostr client (https://humble.horse), there's a lot more work to do I plan to use this as one of the first example products build using Nostrocket.
- Created a new architecture for Nostrocket to address the problems identified in my last update and at the Sovereign Engineering Cohort.
Humble Horse
The goal of Humble Horse is to be a fun new nostr client that makes nostr feel like a giant self-guided group chat and to create a radically improved mechanism for discovery of people.
At the same time, there will be paid options which will allow me to demonstrate how sats flow through nostrocket from the user to contributors.
The reason I want it to be like a group chat is people act very differently in group chats compared to platforms that feel more disconnected like Twitter. I think this will lend itself to a friendlier environment and higher signal to noise ratio.
Hypergolic
The new implementation of Nostrocket (https://nostrocket.github.io/hypergolic) is an implementation of a much simpler event architecture.
Nostrocket previously used a high degree of consensus over the core state, which made it very difficult to interoperate with other clients and also requires fetching a large number of events without much tolerance for missing events.
After discussing with others at the sovereign engineering cohort earlier in the year I filled a notebook full of ideas on how to deal with this. During the weeks after my last report, I condensed this into some preliminary NIPs, and I've been working through these while implementing over the period of this report.
The new architecture is similar to a concept called Cells in the Mozart language.
I use replaceable events, but instead of discarding previous events they are retained and can be fetched by their ID. Each update to the current state includes the ID of the previous state, and a verifiable proof that can be used to derive the new state from the previous state.
This way, simplified clients can just get the latest replacable event as usual, but clients can also validate the whole history of the rocket if they wish by following the chain of replacements back to the first event.
I decided to create a new implementation for this architecture to make things cleaner.
Next Quarter
During the next quarter I'll be presenting my progress as Nostriga, so I have a lot of work to do to prepare for this.
I need to get hypergolic ready enough for other developers to use and contribute towards, there's a lot of work to do for this to happen.
After Nostriga I plan on resuming work on Humble Horse as the first example use case. I need Hypergolic to be very usable by this point so that other people can jump in and contribute.
Use of money
During this period, the funding was mostly used for living expenses and also some minor amounts being used to pay for a relay and to hire people to solve specific problems outside my domain of competence and to accelerate the process in cases where more hands make lighter work.