Nostr Is Infrastructure

On the first afternoon of Imagine IF in Nashville, I stood in a lobby with Jesse Posner and walked him through Nostr. Jesse knows keys better than almost anyone. He did FROST threshold signature work, he was lead engineer on Bitkey at Block, and he just gave a talk called "Imagine IF… you held the keys to everything." His company, Vora, is building Aegis, a private AI that runs on hardware you own.

We talked for a long time, and we never talked about social media. We talked about identity, remote signers, relays, file storage, websites, git, small apps, and a mesh network that uses Nostr keys as network addresses. All of it mapped onto a box like Aegis. By the end he was amazed at what Nostr does once you look past the social layer.

The next day I talked with Obi Nwosu, the CEO of Fedi. Obi told me Fedi uses Nostr as what I like to call invisible plumbing. He said that to him, Nostr was a "decentralized AWS" or a "decentralized Google Cloud". He said that's Nostr's strong point. That was the value proposition. I went and read Fedi's public code afterwards, because it has been a while, and he's right.

Two different founders over two days and they both had the same conclusion. Most people still think of Nostr as a Twitter alternative. The people building serious things on it think of it as infrastructure. This post is my attempt to explain what that means, what the pieces are, where to learn more or run them yourself, and how they fit together.

What "Nostr as infrastructure" means#

Nostr has three basic parts:

• Keys. Your identity is a keypair. The public key (npub) is your address. The secret key (nsec) signs everything you publish. No company issues it and no company can take it away.
• Signed events. Everything on Nostr is a small JSON object signed by a key. A post, a file listing, a git branch, a website manifest, a server advertisement. Anyone can check the signature, so anyone can verify who said what without asking a server.
• Relays. Simple servers that store events and hand them to anyone who asks. Because events are signed, a relay can't forge or alter them. You can use one relay or twenty, run your own, and switch any time.

Social media is one thing you can build with those three parts. It happens to be the first thing everyone built. But keys, signed events and dumb interchangeable servers are a general-purpose stack. They give you:

• Identity without an account server
• Messaging and pub/sub between people, apps and machines
• Discovery, so one party can advertise something and others can find it
• Permissions, because "who is allowed to do this" becomes a signed event you can check anywhere
• Exit, because no single provider holds your data hostage

That's what I mean by infrastructure. Nostr becomes the layer that says who you are, what you published, who's allowed to change it, and where to find it. Other systems do the heavy lifting underneath, and they all trust the same keys.

How Fedi uses it#

Fedi is a good example because it's a funded Bitcoin company and nobody using its app would ever know Nostr is involved.

Fedi's public Manifold repository is a protocol for forming Fedimint federations through a decentralized registry. Its architecture doc says it in one line: "Four protocol roles interact over Nostr (discovery/trust) and iroh (control plane); none of them requires a public IP, DNS name, or TLS certificate." (source)

Here's what runs over Nostr in that code:

• Service advertisements. Federation managers and liquidity providers publish signed events (kinds 37701 and 37702) saying what they offer and how to reach them. The "how to reach them" part is an iroh endpoint, a direct peer-to-peer connection. Nostr does the finding. iroh carries the traffic.
• Credentials and revocation. Fedi's PeerBadge credential system publishes the issuer's authority and any revoked credentials as signed events (kinds 37703 and 37704). Anyone can check whether a credential is still good.
• Encrypted backups across relays. When someone sets up a federation, Fedi builds one fixed 32 KiB encrypted recovery document and writes that exact signed event to every relay in its relay list, confirming each one separately. In Fedi's words, "relay failures never block FI operations." To restore, the client reads the copies back and keeps the newest one with a valid signature. (source)
• Keys derived from one root. The backup keys and service keys are derived from a single seed, so one secret recovers the whole set.

If you translate that into cloud terms, the picture Obi described shows up:

• Relays work like a storage bucket plus a message bus that no one company runs.
• Signed advertisements work like a service registry and a marketplace listing.
• Signed credential and revocation events work like a key management and certificate revocation service.
• The relay list is the config file that says where all of it lives.

None of it needs Fedi to run a central server for it to work. That's the decentralized AWS.

The building blocks#

These are the pieces I walked Jesse through. For each one: what it is, why it matters, and where to learn more or run your own. Some are finished standards. Some are proposals that people are already shipping. I'll say which is which.

Keys, identity and remote signers#

Your npub is your identity everywhere on Nostr. NIP-05 lets a domain vouch for a key, so derek@example.com can stand in for a long npub. Self-hosting it is one static JSON file at /.well-known/nostr.json on your domain.

The hard part of keys is keeping them safe while still using them. That's what remote signers are for. With NIP-46, your secret key lives in one place, the signer (often called a bunker), and apps ask it to sign. The app never sees the key. Requests travel over relays as encrypted events, and permissions can be scoped, so an app might only be allowed to sign one kind of event.

FROSTR goes further. It splits a key into shares across several devices, and any k of n of them can sign together. No single device ever holds the whole key, and the result is a normal Nostr signature that relays and clients can't tell apart from any other.

This is where Nostr gets interesting for AI. Block's Buzz, launched in July, gives every AI agent its own Nostr keypair, and a second signature ties each agent to the human who owns it. Agents with their own keys can sign, get paid and build a reputation without a platform issuing them API keys.

• Run a signer: Keycast (self-hosted, per-app policies, built for people, families and small teams), Amber (Android)
• Threshold keys: FROSTR on GitHub, including igloo-server to self-host

Relays#

A relay stores signed events and serves them. That's the whole job, and the simplicity is the point. Because the events carry their own signatures, the relay doesn't have to be trusted, only available.

Two things make relays work as infrastructure. NIP-65 lets every user publish a list of the relays they write to and read from, so clients know where to find you without a central directory. And NIP-86 gives relay operators a standard management API: ban and allow keys and events, roles, and as of this month, invite-code claims. That's what you need to run a relay for a company, a community or a family.

• strfry: fast C++ relay, the workhorse behind a lot of the network
• Ditto Relay: from Soapbox, built on OpenSearch for scale and full-text search, and it publishes user and event stats as signed NIP-85 trusted assertions
• Haven: a personal relay bundle (private, chat, inbox and outbox relays plus Blossom) in one install
• khatru: a Go framework for building a relay with your own rules

Blossom#

Blossom is file storage for Nostr. It's plain HTTP, with one twist: every file is addressed by the SHA-256 hash of its contents. You fetch a file with GET /<hash> from any server that has it, and you can check that you got the right bytes.

You publish your preferred Blossom servers as a Nostr event (kind 10063). If one server goes away, clients look up the same hash on your next server (NIP-B7). Uploads are authorized with a signed Nostr event, not an account, and servers can mirror each other's files.

So your images, videos, PDFs and app bundles aren't tied to one host. If the host disappears, the hash still points to the same file on the next server.

• Specs: the BUD documents (BUD-01 through BUD-12)
• Run your own: blossom-server or route96
• Hosted: blossom.band

nsite#

An nsite is a static website stored on Nostr and Blossom. The files live on Blossom servers. A signed Nostr event, the manifest, maps each path (/index.html, /about/index.html) to a file hash. Any gateway can read the manifest, fetch the files and serve the site. Nobody can change it without your key. The spec is NIP-5A.

The gateway at nsite.lol says it hosts over 4,000 sites. You can deploy one in a couple of commands, and you can run your own gateway so your site doesn't depend on anyone else's.

• Deploy: nsyte
• Run a gateway: nsite-gateway

napps and napplets#

These two names sound alike and get mixed up. I mixed them up myself while writing this. They're related, but they're different things.

A napp is a whole app. It's an nsite that also works as a Nostr app, plus a listing event with a name, icon, screenshots and categories, so app stores can show it. The website part is still a NIP-5A nsite; the napp spec only adds the listing and release notes on top. It's an open proposal, NIP-5B (PR #2282), and 44billion.net is an app store built on it.

A napplet is a small piece that runs inside another app. It's a single-purpose web app (a feed, a chat widget, a profile editor) that runs in a locked-down iframe inside a host app, called the shell. The napplet never touches your keys, storage or relays. It asks the shell, and the shell decides. One shell can combine many napplets into one experience. It's also an open proposal, NIP-5D (PR #2303), and the PR lists implementations in Amethyst, Grimoire, Myco and others.

Both are distributed as signed Nostr events pointing to files on Blossom, so you can verify them and anyone can host them.

• napps: NIP-5B proposal, 44billion.net
• napplets: napplet.run, the NAP extension specs, a demo runtime, hzrd149's napplelets

ngit and GRASP#

NIP-34 puts a git project on Nostr. The repository announcement, the current branch state, patches, pull requests and issues are all signed events. The project belongs to the maintainers' keys, not to a forge.

ngit is the tool. It installs a git remote helper, so nostr:// URLs work with plain git clone, git push and git pull. Opening a pull request is pushing a branch that starts with pr/.

GRASP is the hosting side. A GRASP server is a git host and a Nostr relay at the same address. It doesn't need your account. It serves whatever your latest signed state event says your branches are. Announce several GRASP servers and they all carry your repo; if one goes down or drops you, the others don't care. Switching hosts means updating one event.

ngit v3 and the GRASP spec reached what the project called "graduation day" in September. ngit itself is developed this way at gitworkshop.dev.

• Install: ngit.dev/install
• Browse repos: gitworkshop.dev
• Run a GRASP server: ngit.dev/self-host, or use relay.ngit.dev

FIPS#

FIPS, the Free Internetworking Peering System, is the one that surprised people most. It's a self-organizing, encrypted mesh network where every machine's address is its Nostr public key.

It runs as an overlay on the regular internet, or straight over WiFi, Ethernet or Bluetooth with no ISP and no DNS. Traffic is encrypted twice, once per hop and once end to end. Nostr relays are used, optionally, so nodes can find each other and get through NAT. On your machine, any normal program can reach a peer at <npub>.fips, so SSH and HTTP just work. It even runs on OpenWrt routers.

FIPS is early. The README says the protocol and APIs are not yet stable. It's also already running a public test mesh, and other projects are building on it. Myco is an Android app that shares nsites and napplets phone to phone over a FIPS mesh, tested fully in airplane mode.

• Learn and install: github.com/jmcorgan/fips

How the pieces fit together#

Nostr is the control plane. FIPS is the data plane.

The control plane decides who you are, what's allowed and where things are. Nostr is good at that, because everything is a small signed event any relay can carry and anyone can verify. The data plane moves the heavy stuff: big files, video, model weights, live connections. That goes over Blossom for files and a direct link for traffic. Fedi uses iroh for that direct link. FIPS is a Nostr-native option, because its addresses are npubs.

Stack it up and you get:

• Identity: a keypair, held by a remote signer or split with FROSTR
• Discovery: signed advertisements on relays, found through NIP-65 relay lists
• Trust: web-of-trust scores calculated from follows, mutes, zaps, reports, and more, so apps and agents can rank and filter without a central moderator
• Permissions: signed events that say who may push, publish, or use a service
• Storage: Blossom for files, relays for small structured data
• Publishing: nsite for websites, napps and napplets for apps, ngit for code
• Transport: FIPS or another peer-to-peer link for the heavy traffic
• Payments: Lightning through Nostr Wallet Connect and zaps

Every layer trusts the same key. Every layer can be self-hosted, and every layer has more than one provider.

What people are doing with it#

Already running:

• Fedi runs service discovery, credentials and encrypted backups over relays, as above.
• Block's Buzz gives every AI agent its own Nostr key and runs its workspace on a relay.
• Zapstore is an Android app store where developers sign every release with their Nostr key, so you can verify an app came from who it says it did.
• Nostr Wallet Connect lets apps talk to your Lightning wallet over relays, without the app holding your money.
• KG's apps. KG (Kgothatso Ngako, of Machankura) demoed apps at Imagine IF where a group of curators shares a FROST key, so publishing to a list takes a quorum instead of one admin. curare.to, bitcoin.mov and the Bitcoin necropolis, a graveyard of dead Bitcoin companies where every gravestone is a Nostr event, are all built on curated Nostr lists.
• nsite.lol serves thousands of websites stored on Nostr and Blossom.
• ngit develops itself on GRASP servers.
• bitchat sends messages over Bluetooth mesh and uses Nostr when there's internet. It was the top app in Uganda during the January 2026 internet shutdown, after hundreds of thousands of downloads.

What could be built:

• A home AI server that runs its own stack. Picture Aegis with its own relay, Blossom server and remote signer on the box. The owner's agents get their own keys, signed through the box. The owner's site is an nsite and their code lives on a GRASP server at home. Their boxes and their family's boxes find each other over FIPS. Nothing leaves the house unless the owner wants it to. Jesse and I talked about exactly this. Further out, each box could run its own web-of-trust calculations. Today most apps that use web of trust rely on a service to calculate the scores. An Aegis could crawl its owner's own social graph, work out who the owner and their agents should trust, and publish the results as signed events other apps can read. The AI runs on hardware the owner controls, and so does the trust graph.
• An archive that can't be taken down. A library of historical documents published as signed events, the PDFs on several Blossom servers, the website as an nsite, a relay the organization runs, and new additions signed by a quorum of editors with FROSTR. If the main server disappears, every copy is still verifiable.
• A local marketplace built on trust. Farmers and buyers list goods as classified events, rate each other, and pay over Lightning. Reputation comes from the web of trust, not a platform's star ratings, and nobody can delist a farmer.
• A market for spare compute. A machine with an idle GPU posts its availability as a signed event. An agent that needs compute finds it, pays in sats, and sends the job over a direct FIPS link. The signed receipt becomes part of both parties' reputation.
• A community that runs its own infrastructure. One small server per community: a relay with NIP-86 roles and invite codes, Blossom for files, a signer for members who don't want to manage keys, and an nsite for the public face. If the community splits or moves, the data and identities go with it.

The honest part#

Some of this is mature and some isn't.

Solid today: keys, relays, NIP-65 relay lists, Blossom, nsite, NIP-46 remote signers and Nostr Wallet Connect. People run these in production every day.

Early: napps and napplets are still open proposals. GRASP and ngit just hit v3, which is a big step, but expect rough edges. FIPS says plainly that its protocol isn't stable yet. FROSTR is real and shipping, but setting it up still takes more care than a normal login.

The hard problems: key management is still the biggest one. Losing a key is still too easy and recovering one is still too hard, which is exactly why remote signers and FROSTR matter. Discovery is the other one. Finding the right relay, the right server or the right app without a central directory is solvable, but every app has to do it well. Web-of-trust calculations help here, because the same graph that tells you which people to trust can rank relays, servers and apps.

Where this goes#

Most of the conversation about Nostr is still about feeds and follower counts. The conversations I had at Imagine IF were about something bigger: Nostr as the layer that holds identity, permissions and discovery for everything else.

If you want to try it, pick one piece. Run a relay. Put a Blossom server behind your images. Publish your website as an nsite. Push a repo to a GRASP server. Each one takes an afternoon, and each one is one less thing you rent from someone else.

Social was just the first app built on Nostr. 💜🤙🏻🫂