Skip down to the
NIP-05 & Zola section if you already know about nostr and want to get right into the technical
specifics about nostr DNS verification with zola.
For the past few weeks, I've been doing some research on nostr, a new approach for decentralized social-networking.
What I appreciate about nostr is how radically simple the protocol really is. Anybody who is reasonably technical can understand the protocol at a high-level in just a few minutes, and it's fun to think about all the challenges and possibilities that will arise as it scales to millions of users.
I love how straightforward and to-the-point this answer is from the protocol FAQ, which I think is really getting at where all the hype is coming from.
This is very simple. Why hasn't anyone done it before?
I don't know, but I imagine it has to do with the fact that people making social networks are either companies wanting to make money or P2P activists who want to make a thing completely without servers. They both fail to see the specific mix of both worlds that Nostr uses.
Sometimes the best solutions are a blend of various approaches that, on their own, were optimized too far in one direction or another, as noted in the answer above. Nostr takes a different approach. It uses well-defined and standardized technology that has been around for quite some time, but never put together in this specific way. I think a lot of people see that same magic in bitcoin as well.
I'll save more philosophical rambling about nostr for another time. Now that I've finally setup a key-pair and
started posting to relays, I wanted to make a quick post about how I setup DNS verification of my public key using
zola, the static site generator this blog is rendered with.
The nostr protocol development process has the notion of a "NIP", or a "Nostr Implementation Possibility", in a similar vein to bitcoin's BIPs ("Bitcoin Improvement Proposals"). These are ways the community can propose new ideas or extentions to the base nostr protocol. Some may be mandatory, but most are optional, and can be specified for relays, clients, or both.
NIP-05 describes how clients can use DNS and a simple
GET request to add an extra mapping for a user on nostr. This can give some extra assurance to a follower
that who they are following is legitimate, or mark them as part of an organization (maybe a company or development group).
Basically, a user can sign a nostr event published to relays that sets metadata about their "account"
(technically, their public key). One of those fields that may be set is a
nip05 field, containing a
value. Clients can make a request to
https://domain.com/.well-known/nostr.json?name=name and if the public key returned
matches the public key of the signed metadata event, that "account" is a considered verified against that domain.
To be fair, if that domain is ever compromised in some way, the key mapping could also be compromised, misleading followers. But, it's a reasonable level of assurance, considering we're operating in a decentralized context.
Since I happen to own a custom domain, and I use
zola to render my content as a static site, I
wanted to figure out a way to add
NIP-05 verification to my nostr profile.
zola can do this pretty easily, but the setup is not immediately obvious. We know that for page content,
we should have markdown files and folders under our
content/ directory, and that these map to URL paths during the
NIP-05 specification, we need to have a path like
/.well-known/nostr.json under our domain we want
to verify against. If we create that file at
content/.well-known/nostr.json, build our site and try to navigate there,
we actually get a
This is because zola won't build any directory or include files in the final path structure if there isn't a
present in that directory. To get around this, we can create one at
content/.well-known/_index.md that looks like,
+++ title = "nostr.json" render = false +++
Looking at the section configuration options here
we can see that the
render option is used to prevent any actual template from being rendered into the final path,
but still leaves
/.well-known/nostr.json available to request.
nostr.json are present under
content/.well-known/, we're ready to build, re-publish our site,
and set our
nip05 identifier in a nostr client that supports it. (I used iris.to)
If you want to see the final result for this site, checkout nickmonad.blog/.well-known/nostr.json
Access-Control-Allow-Origin: *as a response header to all
"_"as the "name" in your
nostr.json. See the link above for this site as an example.