Nests
Nests is where a voice room becomes a Nostr object. The app uses signed Nostr events for rooms, live chat, presence, reactions, zaps and roles, while the microphone stream moves through a separate MoQ audio relay that hosts can choose or run.
What Nests really is
Nests is a Nostr-powered live audio-room app. The short version on the official site is direct: host and join live audio conversations on the decentralized Nostr network, with no algorithms and no gatekeepers. The GitHub repository describes the same product in builder language: an audio space for chatting, jamming, micro-conferences, live podcast recordings and similar real-time rooms, powered by Nostr.
That makes Nests different from a normal social client and different from a simple Discord replacement. A Nests room is not just a URL with a voice server behind it. The room record, live chat, presence state, reactions, zaps, roles, themes and preferred audio-server information are represented through signed Nostr events. The microphone audio uses a separate media path, but the social surface around the room is designed to be portable and inspectable by Nostr clients that understand the relevant event kinds.
For the Crays map, Nests sits in Apps because it is a product people open and use. It also belongs in the Communities shelf because the job it does is community-shaped: rooms, hosts, speakers, listeners, chat, moderation and shared live moments. A reader should not expect a wallet, a relay monitoring tool or a text-only client. Expect a live-room app where Nostr identity and relay-published room state matter as much as the voice channel.
The architecture is split on purpose
The most important technical fact is the split architecture. The README says the frontend is a React single-page app that handles rooms, chat, reactions, theming and all Nostr interactions directly from the browser. It also says the frontend is fully static and that all Nostr data, including rooms, chat, presence and reactions, flows through public Nostr relays. That is the part that makes Nests feel native to Nostr rather than merely Nostr-branded.
Audio is handled separately. The same README describes an audio server made of a MoQ relay and auth sidecar for real-time transport via WebTransport and QUIC. The only backend a self-hoster runs is the MoQ audio server. That distinction is healthy. Nostr relays are good at signed event propagation. They are not a low-latency microphone transport. Nests uses Nostr for state and MoQ for sound instead of pretending one layer should do everything.
This split also gives users a practical way to reason about failure. If chat does not appear, you may be looking at Nostr relay selection, room relay hints, signer state or event publishing. If audio fails, you may be looking at WebTransport support, TLS, firewall rules, MoQ relay availability, auth or network conditions. A good Nests article keeps those layers separate because debugging a live room is easier when the pieces have names.
The official site is the public doorway
nostrnests.com is the user doorway. Its metadata describes Nests as live audio rooms on Nostr and says the app lets people host and join conversations on the decentralized Nostr network. The login page uses the same frame: log in with your Nostr identity to join and create audio rooms. The PWA manifest identifies the app as Nests, sets the start URL to `/lobby`, and registers a `web+nostr` protocol handler.
Those details matter because Nests is not only a research repo. It is a web app intended to be opened like a product. The manifest categories are social and entertainment, and the app can be installed as a standalone web app. The public product promise is therefore simple enough for a non-developer: enter with a Nostr identity, join or create rooms, speak and listen live.
The product promise still needs the technical footnote. A hosted web app can make onboarding easy, but a live audio room is not fully decentralized just because room metadata is on Nostr. Someone runs the web front end. Someone runs or chooses the MoQ relay. Someone moderates the room. Someone's signer authorizes events. Nests is interesting because it makes those boundaries more visible than most social audio tools, not because the boundaries disappear.
Room records use NIP-53 ideas
NIP-53 is the standards backdrop. It introduces event kinds for live streaming and spaces, including meeting spaces that contain audio or video rooms. The NIP describes a meeting space event as kind `30312`, with fields such as room identifier, display name, summary, image, status, service endpoint, hashtags, participants and preferred relays. Nests uses kind `30312` as its room event, with room-specific tags for title, summary, image, status, start time, streaming URL, auth URL, relays, role-bearing `p` tags and theme colors.
The Nests README calls the room event a NIP-53-based variant, and the source constants define `ROOM_KIND` as `30312`. That is a precise clue for readers. Nests is not inventing a random room object; it is building on the live-spaces family of Nostr event patterns while adding product-specific needs around MoQ and themes.
Room roles are expressed through participant tags. The README names host, admin and speaker roles. NIP-53 itself talks about providers and roles such as host, moderator and speaker. In practice, that means a Nests room can have a structured authority model: who owns the room, who moderates it and who is allowed to speak. That model is only as good as the client and relay behavior around it, but it is far better than hiding room power inside an opaque central database.
Live chat is an event stream
Nests live chat uses the NIP-53 live chat kind `1311`. The NIP says live chat messages include an `a` tag pointing back to the live activity. The Nests README gives the same shape for a room chat message: kind `1311`, tagged with the room address, content as the chat body. The source hook for chat messages queries kind `1311` with the room's `a` tag and fetches recent messages for the active room.
This is the small detail that makes a Nests chat different from the chat column in a closed streaming app. A message is a signed Nostr event tied to a room address. Other clients can theoretically read or display it if they know the room and support the event shape. The room conversation is not merely a transient socket message owned by one server.
That does not make chat magically permanent or universally visible. It still depends on relays. The Nests publishing hook explicitly routes events through the room's effective relay set, including user NIP-65 relays, the room event's `relays` tag and naddr hints. If participants are on different relays, visibility can vary. The open model helps, but live rooms still need thoughtful relay selection.
Presence is visible and temporary
Presence is one of the places where Nests feels most like a live room. The README describes kind `10312` as a replaceable event signaling a user's presence in a room. Tags can indicate the room address, whether a hand is raised, whether the user is publishing audio, whether the mic is muted and whether the user is onstage. It also says clients publish presence every two minutes as a heartbeat and that presence can only be indicated in one room at a time.
The source code matches that model. The presence hook builds and auto-publishes kind `10312` events with `hand`, `publishing`, `muted` and `onstage` tags. Another hook queries recent presence events for a room and refetches quickly so stage and hand changes feel responsive. NIP-53 also defines room presence and says clients should ignore presence events older than a chosen time window.
The practical meaning is simple: Nests presence is useful, but it is a public social signal. If you join a room, raise your hand or move onstage, that state may be visible as a signed event on the relevant relays. For public rooms this is expected. For sensitive rooms it matters. Hosts and participants should understand that Nostr presence is not the same as a private server-side status hidden inside a closed app.
Audio runs over MoQ
Nests uses MoQ, Media over QUIC, for real-time audio transport. The README says the audio relay and auth sidecar handle real-time audio via WebTransport and QUIC. The Nests source package includes MoQ libraries such as `@moq/hang`, `@moq/lite`, `@moq/publish` and `@moq/watch`, which confirms that the current implementation is not a LiveKit-only relic or a generic WebRTC room.
MoQ is still an emerging media transport area. The IETF Media over QUIC draft describes MOQT as a publish-subscribe protocol running over QUIC and WebTransport, using streams, datagrams, priorities and partial reliability, and capable of point-to-point or relay-mediated low-latency delivery. W3C WebTransport defines browser APIs for sending and receiving data between browser and server. Nests is using that family of technology for a very practical reason: live audio needs low latency, and Nostr event relays are not audio relays.
This is also where operational reality enters. A MoQ relay needs certificates, open ports and browser support. The README says the MoQ relay handles its own TLS on port 443 or 4443 depending on setup and should not be reverse-proxied like the web frontend. It also says firewall rules need TCP and UDP open for the relay subdomain. If you self-host Nests and skip those details, the room may exist on Nostr while nobody can hear anything.
Audio servers can be user chosen
Nests has a specific event for preferred audio servers. The README calls this an audio server list, kind `10112`, where users publish preferred MoQ relay servers. The source hook for MoQ server lists describes each entry as a relay URL plus an auth URL, using tags shaped like `server`, `relayUrl`, `authUrl`. That is an important sovereignty feature: a room can use infrastructure chosen by the host rather than only the default service.
The README says anyone can run a standalone MoQ audio server and then add its URL as an audio server in any Nests client under Settings > Audio. It also says users can publish their preferred audio servers to Nostr so rooms automatically use their own relay. This makes Nests more interesting than a pure hosted audio product. The web app can be public, but the audio infrastructure can be moved.
Do not overread that as effortless decentralization. Running a low-latency audio server is still server work. You need DNS, TLS, firewall rules, monitoring, bandwidth, updates and a plan for abuse. If a room depends on a fragile home connection, it may fail at exactly the moment people arrive. The value of the server-list model is choice and transparency, not a promise that everyone should become a media operator overnight.
Login uses real Nostr signing paths
Nests is not asking for a normal email account. The official login page says users log in with Nostr identity. The source code around current users and login supports several Nostr paths: nsec login, NIP-46 bunker login and NIP-07 browser extension login. That gives the app a real Nostr authentication surface rather than a username/password account with an optional pubkey field.
Those options have different risks. A browser extension signer is usually safer than pasting an `nsec` into a web app. A bunker can keep signing authority elsewhere, but introduces its own availability and trust model. Pasting an `nsec` gives the app or browser environment direct access to the secret. A serious Nests user should prefer a signer flow they understand and reserve direct secret-key entry for disposable or carefully controlled keys.
This matters because live audio feels casual. People join a room quickly, talk, react, zap and move on. But every room creation, chat message, presence update and reaction is still signed. A room app has to make signing feel low-friction without turning key custody into an afterthought. That is the hardest product balance in Nostr social apps, and Nests sits right in the middle of it.
Zaps are part of the room culture
The NostrApps listing highlights instant zaps as one of Nests' features, and the source has specific zap components and hooks. Reactions are queried as kind `7` events and zap receipts as kind `9735` events tagged to the room. The zap button hides itself when the user is not logged in, when the viewer is the author or when the author has no Lightning address. That is a product clue: Nests expects appreciation and value-for-value behavior to live next to the room.
NIP-57 is the relevant background for Lightning zaps. In a Nests room, zaps can become social signals around a speaker, host, room or moment. That can be delightful for live podcasts, music jams, workshops and small communities because value can move while the conversation is happening. It also means room participants need to understand what is public, what is payment metadata and what their wallet is authorizing.
Nests itself is not an NWC wallet and should not be read as a wallet backend. Zapping may involve Lightning addresses, wallet prompts, external wallet flows or other app-specific payment paths. The safe rule is the same as elsewhere in Nostr: test with small amounts, know which wallet is paying, know who receives, and do not let live-room energy rush you through payment prompts.
Moderation is not solved by protocol
Live audio makes moderation concrete. A text client can ignore a note or mute an account after the fact. A voice room has interruptions, microphones, stage control, hand raises, host judgment and audience pressure in real time. Nests has host, admin and speaker roles, presence tags that reveal stage state, and admin-command code watching for commands targeting the current user. These are useful controls, but they do not replace human hosting.
A good Nests room needs a host who understands both the product and the social situation. Who gets speaker access? What happens if someone starts recording? Are zaps encouraged or distracting? Are chat messages part of the show or just backchannel? Can a public room handle raids? Which relays does the room publish to? If the room is for a sensitive community, should it be public at all?
Nostr gives Nests portable identity and signed room state. It does not guarantee social safety. Hosts should rehearse moderation before the important event, test mute and stage behavior, keep another admin available for larger rooms and be honest about the public nature of room events. The app can provide tools; the room still needs stewardship.
Self-hosting is possible but technical
The README gives a clear self-hosting path. The full stack uses a static web frontend, a MoQ relay and an auth sidecar. A reverse proxy such as Caddy or nginx can sit in front of the frontend and auth service, but the MoQ relay handles its own TLS and should not be proxied. DNS must point the relevant subdomains to the server. TCP and UDP on the MoQ port must be open.
The docker-compose files reinforce the same model. One stack names the web frontend, MoQ relay and MoQ auth service. The development stack includes a local strfry Nostr relay, a MoQ relay and auth, with the UI dev server running outside Docker for hot reload. For a technically comfortable host, this is approachable. For a non-technical community, it is still infrastructure work.
The unofficial nostrnests.org installation guide is useful as a clue but should be treated cautiously. It says the guide will walk users through installing the open-source software and setting up an audio server, but several links still say GitHub coming soon. The official repository and current README are stronger sources. If you are actually operating a room, trust the maintained repo before a thin third-party install page.
The older LiveKit context still matters
Nests has history. A 2024 No Bullshit Bitcoin article covered Nostr Nests 2.0 beta and described it as a Twitter Spaces or Clubhouse-like app for Nostr, with direct Nostr authentication, discoverability across clients supporting live events, PWA installation, permission settings, audio recording, custom relays, moderation tools, zaps and multilingual support. It also explicitly called the release beta software.
The current repository now emphasizes MoQ and WebTransport, but the broader Nostr ecosystem also has a LiveKit pattern. NIP-29 describes relay-based groups and includes an optional live audio/video model where a relay can expose a LiveKit token endpoint authenticated with NIP-98. That is not the same thing as Nests' MoQ architecture, but it shows that Nostr live rooms are an active design space with more than one transport choice.
For readers, the lesson is to check current implementation before assuming the stack. A blog post from 2024 may describe a feature or direction that changed. A repo updated on June 11, 2026 with MoQ dependencies and server-list code is a stronger indicator of the current technical path. Historical sources are helpful; current source and docs decide how you should test.
What to test before hosting
If you want to use Nests seriously, start small. Log in with the signer you intend to use. Create a private or low-stakes room. Join from a second device and a second account. Confirm that the room appears, chat messages publish, presence updates, hand raises and stage state behave as expected, and the audio path works across the browsers your audience will use.
Then test infrastructure. If you are using the default MoQ relay, know whose server carries the audio. If you use your own, confirm TLS, DNS, auth URL, relay URL, TCP/UDP firewall rules and monitoring. Check whether your network permits WebTransport. Try a mobile connection and a desktop connection. If people will arrive from Safari, older browsers or locked-down corporate networks, do not assume the demo path will work.
Finally test the money and moderation path. Send a small zap if zaps are part of the room. Verify the recipient. Try muting, moving onstage, lowering a hand, leaving and rejoining. Make sure a second admin can help. Decide whether chat is public enough for your event. A live room is a social contract plus software; both need rehearsal.
What Nests proves about Nostr
Nests is valuable because it stretches Nostr beyond timelines. A room can be an addressable object. Chat can be a signed event stream. Presence can be replaceable and time-windowed. Reactions and zaps can attach to the room. Preferred infrastructure can be published as a list. Themes can move through events. None of that is the old feed model with a microphone bolted on.
It also proves that Nostr apps do not have to be pure relay toys. Real products can combine Nostr events with specialized infrastructure. Blossom can separate file storage from event metadata. NWC can use relays for wallet requests while Lightning moves value. Nests can use relays for room state while MoQ moves audio. This layered design is likely how many serious Nostr products will work.
The risk is marketing simplicity. A phrase like decentralized audio can hide the real operational pieces. Nests is more honest and more interesting when you say the whole thing: decentralized room state, signed identity, relay-published chat and presence, user-selectable audio servers, and a real-time media path that still needs servers. That is not a weakness. It is the architecture.
Closeout
Nests belongs in the Crays Nostr Hub because it shows the community layer becoming a real product surface. People do not only want to post notes. They want rooms, voices, stage energy, live chat, zaps, presence and a sense of place. Nests tries to make those things Nostr-native without forcing audio through a protocol that was not built for microphone packets.
Use Nests with clear expectations. It is a live audio-room app, a Nostr client surface and a media-infrastructure experiment. It is not a wallet, not a general relay, not a guarantee that every client will see every room the same way, and not a substitute for human moderation. The more serious the room, the more you should test signer flow, relay visibility, MoQ audio, zaps, roles and fallback plans.
The project is worth studying even if you never host a room. It gives a concrete pattern for layered Nostr products: signed events where portability matters, specialized infrastructure where real-time performance matters, and enough openness that a community can inspect and move parts of the stack. That is a much stronger future than copying closed social audio inside another locked account system.
Sources worth opening
Start with nostrnests.com, the GitHub organization, the main Nests repository, the README, the NostrApps listing and the current source files for constants, room presence, MoQ server lists, chat, reactions, zaps, login, Nostr publishing, room helpers and MoQ auth. Then compare NIP-53, NIP-98, NIP-07, NIP-57, NIP-65, NIP-29, the MoQ project, the IETF Media over QUIC draft, W3C WebTransport and the older Nests 2.0 beta announcement before treating a live room as production infrastructure.
- Nests official site
- Nests login page
- Nests PWA manifest
- Nests favicon asset
- Nostr Nests GitHub organization
- nostrnests/nests repository
- Nests README
- Nests package file
- Nests constants file
- Nests room helper file
- Nests MoQ server-list hook
- Nests room presence hook
- Nests presence publishing hook
- Nests chat messages hook
- Nests room reactions hook
- Nests Nostr publish hook
- Nests current-user hook
- Nests login dialog
- Nests MoQ authentication code
- Nests Zap button
- Nests zap hook
- Nests admin commands hook
- Nests Docker Compose
- Nests MoQ Docker Compose
- Nests livekit-audio-egress repository
- NostrApps listing for Nests
- NIP-53 Live Streaming and Spaces
- NIP-98 HTTP Auth
- NIP-07 browser signer capability
- NIP-57 Lightning Zaps
- NIP-65 relay list metadata
- NIP-29 relay-based groups
- MoQ project
- IETF Media over QUIC draft
- W3C WebTransport specification
- No Bullshit Bitcoin Nests 2.0 beta article
- Nostr Nests installation guide
