I'm so excited that Satellite is back. It's always had my favorite design of any Nostr app. View quoted note →

I've been quiet lately but I've just been very heads down trying to get Keydex ready for it's first alpha usability test, which I'm about to head to right now! I'll try to post a project update this week, as I passed the halfway point on my (relatively tight) 4 month timeline recently.

I just did a weird thing with gift wraps in Keydex and I want to make sure it's not dumb. I'm having a bug where lockboxes are showing back up on the devices of key holders after they have been removed. Like this: 1. Alice invites Bob to be a key holder for their lockbox 2. Bob accepts 3. Alice publishes a shard of the lockbox data for Bob to download, gift wrapped and addressed to Bob. 4. Bob changes their mind and deletes the lockbox from their device. 5. Later when Bob reopens the app it downloads the shard event again and recreates the lockbox. Of course I could maintain some local state about what has been deleted, but it would be better to just nuke the shard from the relay. We could ask the original publisher to do it, but we can't guarantee they are online. So what if we just include the ephemeral key used to gift wrap the shard in the seal? Now Bob can publish a NIP-09 deletion request to delete the shard. I could see this being useful in other places too. For instance you could have a type of direct message that gets deleted from relays as soon as it is downloaded by the recipient.

Fun milestone for Keydex today: I had my first successful restore of data. I was able to fire up several copies of the app and create a lockbox, break it into shares, distribute them to peers via Nostr, initiate recovery, approve the recovery request, and reassemble the data. There is still a ton of work to do but having the core flow working makes all the future changes feel small and incremental by comparison.

Keydex is going to be the first Nostr app I'm aware of that uses relays exclusively to relay data from one peer's device to another, not for long-term data storage. I'm going to use NIP-40 expiration tags on all events so that they only live on the relay for a few days, which makes Keydex closer to a peer-to-peer application that uses Nostr as the transport (and identity) layer.

Day 2 using Github's spec-kit for development did not go as well. The AI and I got lost trying to write reams of overly generic TDD test stubs. It felt like the AI couldn't really get a clear picture from just the spec requirements what it should be testing before the actual implementation code was written. So today I changed course and changed my constitution (the like underlying spec doc for the repo) to use an outside-in development approach instead of TDD and we made a lot of progress. I also got a new playwright MCP set up for browser automation and it's working a lot better than the last one I had. After some considerable setup the LLM was generally able to run the app in the web browser and click around to test its own changes.

"any kind of decentralized, democratic or liberal political structure thrives best when defense is easy, and suffers the most challenge when defense is hard - in those cases, the far more likely outcome is some period of war of all against all, and eventually an equilibrium of rule by the strongest." A good (but long) blog post on focusing our collective efforts on developing defensive technologies to slant the future away from dystopia.

d/acc: one year later

Thanks @Josh Brown for the link!

@Danie what tool are you using to cross post across Nostr, scuttlebutt, Mastodon, etc.? I have been using OpenVibe but it has been really buggy lately.