Why I Wrote My Own Nostr Libraries

When I started building NostrKey, I made a decision that cost me time up front and has paid me back ever since. I would not glue it together out of other people's dependencies. The pieces it stood on, I would write myself.

Part of that was taste. If you are going to ship a thing that holds people's keys, you should be able to read every line underneath it, and "I trust the package" is not the same as "I understand the code." But most of it was simpler than that. I wanted to actually learn Nostr, and the honest way to learn a protocol is to build its pieces, not to import them.

One small library at a time

So I did it the slow way. A library for the cryptography. A library for turning a seed phrase into keys. A library for talking to relays over websockets. A library for sign-in on the server, and one for magic links sent over encrypted direct messages. Each one small, each one doing a single job, each one something I understood because I had written it.

They are all on npm now, under my profile there. nostr-crypto-utils for the primitives, nostr-nsec-seedphrase for keys from a phrase, nostr-websocket-utils for the relays, nostr-auth-middleware for sign-in, nostr-dm-magiclink-utils for the magic links, and a growing set beyond them as I needed new pieces. Getting my own name on npm, with real packages other people could install, was a quiet milestone I did not expect to care about as much as I did.

It led somewhere I did not plan

Here is the part I like best. Writing those libraries taught me the protocol well enough that I started wanting to hand the shortcut to other people. Nostr is genuinely good, and adding it to a website is more approachable than it looks once you have the right small pieces in front of you. So I built LoginWithNostr, a way to show other developers how to add Nostr sign-in to their own sites without having to walk the whole learning curve I did.

That is the loop I did not see coming when I started: learn by building the pieces, then package the pieces so the next person does not have to.

Quietly, on purpose

I am not the loudest voice in the Nostr room, and I do not want to be. I would rather build the muscle memory than win the argument. Every project I take on now, I look for the place where Nostr fits, and where it does, I reach for my own libraries and share the code that makes it possible. That is the whole strategy: not a campaign, just a steady habit of making open protocols a normal part of how I build, and leaving the pieces behind for anyone who wants them.

If you are a developer, the fastest way in is LoginWithNostr: see how Nostr sign-in works, then wire it into your own site. If you just want to hold your own keys and sign in with them across the web, install the NostrKey browser plugin. Both exist because of the same quiet decision I made a while ago, to write the clean version myself.