Matt Lorentz

This website speaks to the nerd inside me on so many levels. I think I'm going to give the "No S Diet" a try. https://everydaysystems.com/

I just posted a project update video for Keydex that shows the current features and future plans. Plus an announcement that I'm renaming the project from Keydex to Horcrux! Check it out: https://tube.tchncs.de/w/oyxzSzhocB3k6BNbVTdU7d

I'm so excited that Satellite is back. It's always had my favorite design of any Nostr app. nostr:nevent1qgs07f7srjc72ma4skqrqmrm5a4mqdalyyw9k4eu2mjwwr9gtp644uqqyp79f90q3xe5ae2d68z243m75uughr8eguqq4cpdtf58e5stjh9nw2y328t

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. https://vitalik.eth.limo/general/2025/01/05/dacc2.html Thanks nostr:npub1yl8jc6znttslcpj3p6p8vuq98awu6w0xh4lqtu0lkjr772kpx4ysfqvz34 for the link!

nostr:npub1g2jpj7x9rjcqd9dp3hnvja2tjr3q3hf362z3ulrfzpyfnsdw5qlqyayjj6 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.

The official word is "no" 😢 (from telegram) nostr:nevent1qvzqqqqqqypzp59pl7u8vxuhfnky5wlge09ja948pyxu73jll6kg8x4yegsvnfv7qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgwwaehxw309ahx7uewd3hkctcqypcqudfm6cpy2tx0qavunavv8sz0u8ratvedhs20vd6l7lfr63ekk0gg9q2

nostr:npub1u928yy8gxds7vcra6df0l55agjt7dnd9c3ffmclpehz3ensp0k8stnhr58 nostr:npub12hcytyr8fumy3axde8wgeced523gyp6v6zczqktwuqeaztfc2xzsz3rdp4 nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49 not sure where to report this but I am getting this error at https://zap.stream/nogood :( Unexpected Application Error! error loading dynamically imported module: https://zap.stream/assets/markdown-D8ImU_5Q.js

Spent a couple hours setting up the Keydex repo with Github spec-kit. No code yet but I have 1000 lines of markdown to show for it 🤷‍♂️ https://github.com/mplorentz/keydex

I'm back in the code editor for the first time in a few weeks. It feels good 😊 Trying out Github's spec-kit tool for spec-driven development with AI: https://github.com/github/spec-kit?tab=readme-ov-file#-core-philosophy

Sharing some wireframes I made for Keydex here, mostly because nostr:npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk asked to see them but I figured why not share them publicly. They have a watermark because I am using the trial version of the design software 😬 https://blossom.lorentz.is/938d7eabe684ee5a529f7a7d78feee31f0259d6ed674601baa4ba04cb3fa50e5.pdf Thanks for the feedback on these nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn, nostr:npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk, and nostr:npub1jr8sgwrpuk66n9evk76jnfd6wxept4k3uv2vwjw42fhvzvl3mdes38wwnw!

I’ve been noodling on my OpenSats projects and one thing I wanted to hear people’s thoughts on is the idea of lightly encrypted groups vs. relay-based groups. And by lightly encrypted I mean that all group data is encrypted with a shared key that gets rotated, but without end-to-end encryption, forward secrecy, post-compromise security, and all the fancy stuff you get with MLS. Basically the unmerged NIP-87 (https://github.com/nostr-protocol/nips/pull/875/files?short_path=ed261ea#diff-ed261eac15a3dc7dbd825342a3e89dc960824a52afd2dd032f30876fbfb25698) I know this idea has been discussed a lot, and I have been pretty convinced that NIP-29 made the most sense for the most groups. I also know MLS groups are in the works, but they have a lot of downsides. So a few things over the past month are making me reconsider. The main one was talking to nostr:npub1vjhrl4k2uj6sttu5y3xahz29esk2nfn274de8qtn5jkv06zwn7gs68ejkd from nostr:npub1j4g0z7t85s2sxkynvl84yeh0g7ekff8pjanta70s78n3ern4562sw9fuu4 who makes a good argument that groups should be a first class citizen on Nostr. This would enable groups of groups and potentially other innovations like putting the group master key in a FROSTR cluster. It also helps enable forkable groups and groups migrating between relays / sets of governing rules. (Great article from SocialRoots about their full vision https://www.socialroots.io/intimacy-gradients-the-key-to-fixing-our-broken-social-media-landscape/) Another factor is that people keep asking me if groups are going to be encrypted in my new client and I don’t like saying no to that 😅. Even though I think the confidentiality guarantees of NIP-29 are good enough for most groups - that’s not what people want to hear. I used to think that getting a bunch of Nostr clients to all implement key rotation the same way was too much to ask, and I still think MLS is overkill for medium to large groups. But if you allow some privileged software to run with some kind of group admin key to do the rotation (an allowance that NIP-29 already makes) then it hugely simplifies the complexity for client developers and now you can say the magic word ✨encryption✨. I also feel like I missed out a bit on the debate between these when it happened. What do you think?

Today I discovered https://frame0.app for making quick wireframes. I used to love Balsamiq but the desktop app has been discontinued. If you've never worked with this type of barebones wireframe before they are so valuable for getting feedback on high level UX without digressing into discussions about the size and colors and exact placement of things. When people see the handwritten font their brain switches into a different mode.

I've finished my first round of interviews for Keydex and they were so enlightening. I'm so addicted to user interviews now, I don't understand how I made so much software without them. The top insight from this round was clarifying the different use cases for Shamir's Secret Sharing. Here's what I came up with: - inheritance planning - corporate secret management for ultra-sensitive values i.e. root passwords - border crossings - web3/crypto/Nostr key backup The most interest by far was in the inheritance planning use case. People have some digital stuff they want to pass on, but don't want it sitting in plaintext in the hands of (generally very normie) friends and family. Keydex will work for all cases listed above but I'm going to keep the inheritance use-case top of mind while developing. Which already invalidates some of the design work I did last week. I was going to make a fun retro/gamey UI, but now I'm going to shift towards something more calm and reliable.

I'm looking for folks to interview for the new app I'm working on. If you've ever needed to back up some sensitive data (passwords, crypto wallet key, "legacy planning" docs) but didn't just want to print it out and hide it then I'd love to talk to you. Just let me know here and I'll be in touch: https://formstr.app/i/keydex