Corny Chat
Corny Chat is best understood as a Nostr-aware audio-room server, not as a timeline client, wallet or ordinary group chat. It combines WebRTC rooms, a Jam-derived backend, NIP-07 login, Nostr profile reuse, live activity events, room chat, Lightning value flow and operator tooling that needs careful privacy and infrastructure review.
What Corny Chat really is
Corny Chat is a live audio spaces application for Nostr people. The simplest mental model is a web room where people can gather, speak, listen, use text chat and send value. That makes it feel familiar if you have used Twitter Spaces, Clubhouse, Discord stages or podcast backchannels. The important difference is that Corny Chat does not stop at a web account. It brings Nostr identity, relay-published room signals and Lightning payment behavior into the room.
The public repository describes it as an open source audio space built on Jam that integrates Nostr and Lightning. That description is accurate, but it undersells the number of moving parts. The code is a JavaScript and React application with a pantry backend, Redis state, WebRTC media, optional coturn and SFU services, Nostr relay publishing, LNbits integration, zap goals, subscriptions, ads, room roles and personal settings for Nostr Wallet Connect.
That combination explains why Corny Chat belongs in Live Streaming on the Apps Hub rather than in wallets or generic social clients. You are not opening it primarily to manage sats. You are opening it to participate in an audio room. The wallet and Nostr pieces serve the room: identity, profile display, scheduled discovery, live activity announcements, chat-linked payments and value for value.
For you as a reader, the useful question is not whether every Nostr feature is elegant. The useful question is what data and authority the app touches when you join or host a room. Corny Chat touches your microphone, browser, Nostr signer, relay graph, Lightning address and possibly an NWC connection. That is powerful when configured well and risky when treated casually.
The live site surface
The live site at cornychat.com presents itself simply: a room-oriented audio experience with an about page, manifest metadata, a favicon hosted through nostr.build and a page configuration that exposes Jam, pantry, STUN, TURN, SFU, relay and Lightning settings to the frontend. A page check on June 13, 2026 showed default general relays including nos.lol and thebarn.nostr1.com, SFU enabled, GIFs enabled and a value-for-value Lightning address for the server.
That live configuration is useful because it shows the hosted product is not only a static front page. The browser receives enough information to join rooms, talk to the pantry service, use WebRTC infrastructure and interact with Nostr-backed room features. You should treat the page as an active communication app, not as a passive article page.
The official metadata is deliberately modest. The Open Graph title is Corny Chat and the description says to join an audio room. That is a fine public doorway, but the deeper story is in the code and docs. Corny Chat is a room server that can publish Nostr events, maintain room state, update live activity records, verify Nostr identities, display profiles and support payments.
The first practical check is therefore basic: before joining any room, know whether you trust the server you are using. A room URL can be shared broadly. A browser can ask for microphone permission. WebRTC can reveal network information depending on browser behavior, TURN use and network conditions. A Nostr signer can be asked to sign events. A wallet connection can pay. Those are not reasons to avoid the app; they are reasons to be deliberate.
Jam lineage matters
Corny Chat is not a from-scratch audio stack. The README says it is forked from Diego's Jam, which itself was forked from the original Jam Systems project. You can still see that ancestry in package names, scripts and update instructions that refer to Jam. That history is good to know because it explains both the maturity and the rough edges of the project.
Jam gives Corny Chat a working concept for browser-based rooms, identity inside a room, room URLs, WebRTC communication and backend state. Corny Chat then adds Nostr and Lightning behavior around that base. In practice, the room experience is the foundation and the Nostr layer is an extension of it, not a separate native protocol replacing all web infrastructure.
That distinction matters for expectations. A Nostr event can announce a live room, identify a speaker or link to a scheduled audio space, but the audio stream itself is still a web media experience. It uses the browser, WebRTC, STUN, TURN and optionally an SFU. If those pieces fail, your Nostr keys will not magically fix the call.
The lineage also matters for maintainers. Forked software often carries inherited assumptions. Corny Chat's UPDATE document still has some older naming residue, and package metadata still says Jam in places. That is not a scandal. It is a reminder to read current code, not only high-level docs, before self-hosting or writing integrations.
Nostr login and profile reuse
The Nostr login path is concrete. The frontend checks for `window.nostr`, gets a public key from a NIP-07 browser extension, builds a short kind 1 login event with the room identity as content and asks the extension to sign it. The signature is not primarily a public post; it is a proof that the browser session controls the Nostr key. The backend then verifies the signature and connects the room participant to an npub.
After login, Corny Chat reads the user's kind 0 metadata from relays. That lets the room display the same name, picture, about text, banner, NIP-05 identifier and Lightning address that other Nostr clients use. This is one of the strongest parts of the product: you do not need to rebuild your identity for one audio app if your Nostr profile is already useful.
The app also verifies NIP-05 and uses LUD16 or LUD06 fields when it needs a Lightning address. That means a user's public profile can affect both social trust and payment routing inside a room. If your Nostr profile contains an old Lightning address, a room zap flow may discover that old address. If your NIP-05 is broken, the room may show weaker trust signals.
The user advice is simple. Before using Corny Chat with a serious npub, open your Nostr profile in another client and check the basics: name, picture, about, NIP-05 and Lightning address. Then log in with a browser signer you trust. Do not paste private keys into random room flows. Corny Chat's extension path is the safer normal path.
Rooms, roles and npubs
Corny Chat has normal room concepts such as owners, moderators, speakers and participants. The Nostr-specific part is that room roles can be connected to npubs as well as internal room user identifiers. Release coverage for v2024.05 described room owners, moderators and speakers being assigned by npub, and the current backend code checks Nostr identities when building live activity participant tags.
That matters because an audio room has social authority. Who can speak? Who can moderate? Who owns the room? If role assignment can follow a Nostr key, a community can use its existing public identities instead of relying only on a fresh local account. A recognizable npub becomes a practical access-control anchor.
The tradeoff is that Nostr identity is not the same as human identity. If a private key is lost, compromised or shared among a team, the role model inherits that problem. If a room grants power to a typo-similar npub, the room may grant power to the wrong person. If someone logs in anonymously, the room may have less Nostr context for that participant.
For hosts, the check is boring and important: verify the exact npubs you assign to owner, moderator and speaker roles. Test a room with a second browser before a public event. Confirm that private and closed room settings stop live activity publication when expected. Room safety in a live audio product is mostly preparation, not clever protocol language.
Live activities through NIP-53
Corny Chat's strongest protocol fit is live activity discovery. The backend publishes kind 30311 events for live rooms. Those events include tags for a durable identifier, title, summary, end time, status, current participant count, talk-related topics, a label namespace, the room URL and relays. It also adds participant `p` tags for Nostr users in the room, with roles such as Participant, Speaker, Moderator and Room Owner.
That aligns with NIP-53, which defines live activity events and live chat messages. The point is not to stream audio through relays. The point is to make the live room discoverable and socially legible through Nostr. Another client can see that a room is live, who is associated with it, where to open it and which relays were advertised.
The live event updater is also active, not one-shot. It checks rooms, creates or updates live activity events, marks rooms ended when they close or become private, deletes older events and can periodically announce rooms through a server account. That is the operational glue a live directory needs. Without updates, a room list becomes stale almost immediately.
For users, this means Corny Chat rooms can appear in Nostr-aware discovery surfaces beyond the original site if those surfaces understand kind 30311. For hosts, it means privacy settings matter. If a room should not be public, do not rely on vibes. Confirm that the room is private or closed before assuming it will stop being announced through Nostr relays.
Scheduled audio spaces
Corny Chat also handles scheduled rooms. The README describes Nostr calendar time events using kind 31923, and the backend code has functions to publish and delete scheduled events. It uses a stable event identifier based on the host and room, publishes deletion requests with kind 5 when a schedule changes and keeps a cache of scheduled events for discovery.
The schedule reader is intentionally broader than only Corny Chat. The code comments say it looks for calendar events tagged as audio space so other services, including Nostr Nests, could be included. It also falls back to planned live activities from other services such as Nostr Nests and zap.stream, turning some of those into links with naddr identifiers. That makes the landing page more of an audio space directory than a single-instance room list.
This is an important product idea. Live audio is hard to discover if you only learn about it after it starts. Scheduled Nostr events let a host announce the room ahead of time, let clients show a calendar-like list and let participants decide whether to attend. It gives audio rooms a public social object before the microphone turns on.
The caution is that scheduling standards and implementations are uneven. Corny Chat filters old, deleted, too-long and malformed events, but relays differ in what they store and return. If you are hosting a serious event, publish the schedule, then verify it from another browser and another Nostr client or relay tool. A scheduled room that only appears on your own machine is not a schedule.
Room chat is a Nostr bridge
Corny Chat has room text chat, but it should not be reduced to ordinary public chat. The README describes live chat tied to live activities with kind 1311, and the backend publishes an initial kind 1311 message when a room goes live. The RoomChat code also handles local room chat commands, text chat state and special actions such as GIF help, target selection and zapping.
The NIP-53 relationship is the key point. Live chat kind 1311 is meant to attach chat messages to a live activity. That keeps the chat connected to the room context instead of becoming a free-floating timeline note. If a client understands the live activity, it can display the chat in the right place.
Room chat also becomes a payment interface. The `/zap` command appears when a user has Nostr and NWC configured. It can target one participant or all peers in the room, discover their npubs, read their kind 0 metadata, find Lightning addresses and prepare zap invoices. That is not a wallet interface in the abstract; it is an audio-room gesture.
You should treat that as both clever and sensitive. A chat command that pays multiple people is convenient, but it needs tight wallet limits. Use small NWC budgets, low daily caps and a wallet you can revoke. Do not connect a high-value wallet to a noisy public room just because the feature feels social.
Lightning, zaps and zap goals
Corny Chat has several Lightning surfaces. The profile path can read a user's LUD16 or LUD06 field. The zap path can create a NIP-57 zap request, fetch an invoice from a Lightning Address endpoint and then pay it through WebLN or NWC. The app can read zap receipts of kind 9735 for events. The server can publish zap goals of kind 9041 for infrastructure support.
Zap goals are especially concrete in the backend. The server can publish a yearly infrastructure-cost goal, set an amount in millisats through the `amount` tag and periodically check LNbits wallet balances through the LNbits API. Old zap goals can be deleted through kind 5 requests. This turns server support into a Nostr-visible object rather than a hidden donation page.
The frontend also includes value-for-value logic. The V4V helper prepares a zap request when a target pubkey exists, falls back to direct LNURL payment when needed, and then uses `@getalby/sdk`'s Nostr WebLN provider to pay through an NWC URL. That is a real NWC flow in code, and it is why Corny Chat appears in NWC-adjacent maps.
The boundary is important. Corny Chat is not a Lightning wallet. It is a live audio app that can ask a connected wallet to pay invoices. Your wallet remains separate. That separation is good, but only if the NWC connection has limited permissions, a small budget and an obvious revocation path.
NWC is useful but high trust
Corny Chat lets users enable Nostr Wallet Connect in personal settings. The settings UI accepts a full `nostr+walletconnect` connection string, parses the wallet service pubkey, relay and secret, and stores the connection details encrypted in local storage using a key derived from the local identity state. The payment code then reconstructs that NWC URL when it needs to pay.
That is convenient because it lets a room action become a payment action without opening a separate wallet window each time. It is also exactly the kind of integration that needs discipline. A connection string includes authority. If a malicious script, compromised browser profile or careless app flow can use that authority, your wallet can spend within whatever limits the connection allows.
NIP-47 exists to make this less dangerous than handing a web app a wallet login. A NWC wallet service can expose scoped methods, budgets and relays. Corny Chat's code uses the Nostr WebLN provider from Alby's SDK to issue `sendPayment` calls. The security of that experience depends on your wallet's permissions and your local browser environment, not only on Corny Chat.
The practical rule is to create a room wallet, not connect your main wallet. Give it a low spending limit. Test one payment. Confirm revocation. Then decide whether automatic room zaps or V4V payments are worth enabling. A social audio room is one of the easiest places to forget that small repeated payments can add up.
WebRTC, SFU and network reality
The audio side is ordinary web infrastructure, and that is a compliment. Corny Chat relies on browser media, WebRTC, STUN/TURN and optional SFU support. The live configuration exposes a STUN server, a TURN server and SFU enabled. The deployment examples include coturn and mediasoup-related profiles. This is how browser audio rooms work when participants are behind different networks.
That also means the privacy and reliability risks are web media risks. WebRTC may expose local or public network details depending on browser protections and transport path. TURN servers relay media when direct peer connectivity fails, so the operator of that infrastructure becomes part of the trust boundary. An SFU can improve scale but also concentrates media handling at the server.
For a casual listener, the main checks are browser permissions and room URL trust. Grant microphone permission only when you intend to speak. Use a browser profile you are comfortable using with Nostr and wallet extensions. Prefer HTTPS, check the room domain and be cautious with rooms sent through private messages from unknown people.
For an operator, the checks are heavier. Configure coturn deliberately, set the external SFU IP correctly, monitor CPU and bandwidth, test mobile networks, test NAT edge cases and document what data the server stores. Audio apps fail in public when one assumption about network traversal is wrong.
Privacy policy in plain terms
Corny Chat's privacy file is unusually useful because it describes the room model directly. It says the project does not use an analytics provider, does not store IP addresses in logs and does not give user data to third parties. It also says profile names and pictures can be stored when set, and that room name, description, URL, speakers and moderators are stored.
The most important line is about room URLs. Anyone who knows a room URL can listen, and the instance administrator can listen because room URLs are stored on the backend. That is not a surprising claim for an audio room server, but it is the kind of fact users often forget. A room URL is not a cryptographic secret just because it is not on a front page.
The policy also points at WebRTC IP leak considerations. Even if Corny Chat does not intentionally log IP addresses, browser-to-browser or browser-to-server media paths can reveal network information in ways users may not expect. This is not unique to Corny Chat. It is a WebRTC reality that matters more when the room feels informal.
The honest takeaway is that Corny Chat is suitable for public and semi-public community rooms. It should not be treated as a private secure meeting system unless you have audited the deployment, room settings, network behavior and participants. For sensitive conversations, use tools designed and operated for that threat model.
Self-hosting is serious operations
The INSTALL guide is detailed enough to show that self-hosting Corny Chat is real, but it is not a one-click toy. It expects Ubuntu 20.04 or later, Docker and Compose, Node 20, Yarn, DNS records for the main host and wildcard domains, optional STUN and TURN records, environment files, build steps and service profiles such as web, coturn, metrics, SFU, LNbits and backup.
The server can use a `SERVER_NSEC` to publish Nostr events for status, live activities and server profile information. The docs explicitly warn not to use a personal nsec and to create a fresh key for the server. That is the correct warning. A server private key is automation infrastructure. It should have a narrow identity and limited blast radius.
Relay configuration is also part of operations. `RELAYS_GENERAL` handles most relay reads and writes, while `RELAYS_ZAPGOALS` is specifically for zap goals. There is also optional ACL relay support for relays compatible with Relay Tools-style grants and revokes. Relay choices affect discovery, publishing, moderation and persistence.
If you self-host, treat Corny Chat like a small communications service. Keep backups. Keep keys separate. Patch dependencies. Test updates on a copy. Watch disk, Redis, logs, TLS, TURN credentials and room abuse. A Nostr-aware app still needs old-fashioned operations discipline.
LNbits and macaroon risk
Lightning support can involve LNbits. The deployment docs include an optional LNbits service and a separate LNbits domain. The guide points operators to LNbits wallet documentation, then shows how to connect LNbits to LND through macaroons. It distinguishes invoice-only macaroon permissions from a fuller macaroon that can also send payments.
This distinction is not cosmetic. An invoice-only setup can receive and inspect invoices, which is already sensitive. A full payment macaroon can send payments through LND. If you give a web-adjacent service too much Lightning authority, a mistake becomes a money movement problem, not just a broken chat feature.
Corny Chat's subscription and zap goal code also stores useful payment metadata. The subscription router comments talk about invoice data, payment hashes and LNbits lookups. The zap goal updater can tally wallet balances through LNbits API keys. These are practical features, but they create secrets and operational data that must be backed up and protected.
For operators, the safest path is to start with the least authority needed. Use a separate node or wallet where possible. Prefer invoice-only permissions for receiving flows. Keep API keys out of public repos. Rotate secrets if a deployment is exposed. Document exactly which features require send authority before enabling them.
Ads, subscriptions and room economics
Corny Chat is not only a protocol demo. The deployment example includes ad toggles and paths for square entry ads and chat ads. No Bullshit Bitcoin's v2024.05 coverage described ads that can appear periodically unless a user opts to support the service, and it mentioned value-for-value payments being shown in text chat. The environment file also describes a subscription system for restricting some features to paying users.
That economic layer is worth reading with nuance. Community audio infrastructure costs money: domains, servers, TURN bandwidth, SFU load, backups, relays and time. Zap goals and value-for-value payments are a Nostr-native way to make those costs visible. Ads and subscriptions are a more traditional way to keep the lights on.
The user-facing question is transparency. Does the room show when an ad is an ad? Does a support payment change the product behavior? Do subscription features require a Nostr identity? Are payment limits clear? Can a user participate without connecting a wallet? These details decide whether the economics feel fair or surprising.
For operators, the same question becomes governance. If you run a community audio server, decide how you will fund it before rooms become busy. If you use ads, label them clearly. If you use subscriptions, define what is paid and what stays open. If you use zap goals, publish honest targets and keep the server wallet separate from personal funds.
Standards and custom kinds
Corny Chat uses a mix of standard Nostr patterns and app-specific behavior. Standard pieces include NIP-07 browser signing, kind 0 profiles, NIP-05 identifiers, kind 5 deletion requests, NIP-52-style calendar events, NIP-53 live activities and live chat, NIP-57 zaps and NIP-47 NWC payments. Those are understandable to other Nostr software when implemented and indexed correctly.
It also uses or references more specialized event kinds and labels. The code works with kind 30000 follow lists under a Corny Chat name, kind 9041 zap goals, kind 31990 handler metadata, kind 33388 score events, custom emoji set relationships and sound-effect lists. Some of these are app conventions rather than universal social-client expectations.
That is normal for a real Nostr app. Standards cover shared objects, while products still need local state, UI choices and app-specific lists. The risk comes when users assume every object is portable. A live activity may be portable. A room-specific sound set or score event may be meaningful mostly inside Corny Chat.
The best way to judge interoperability is by object. Ask what you expect to survive outside the app. Your Nostr profile should. A live activity should be inspectable by NIP-53-aware clients. A scheduled event should be queryable by relays. A room role, subscription state or game-like room feature may be more local. Do not demand false portability, but do not accept vague claims either.
What to test before joining
If you are joining a Corny Chat room as a user, start with the domain and room URL. Make sure you are on the site you intended to visit. Open the page before granting microphone access. If you only plan to listen, deny or postpone microphone permission until you need to speak. Use headphones if you are moving between rooms or joining from a public place.
Next, test Nostr login with a browser signer and a low-risk key if you are new to the instance. Watch what the signer asks you to sign. A login proof should not be a broad permission to publish unrelated events. After login, check that your display name and picture appear correctly and that the app did not expose more profile information than you expected.
If you plan to use zaps, make one tiny payment first. Confirm whether the app used WebLN, NWC or a manual invoice flow. Check that the payment reached the intended Lightning address. If a zap command targets multiple room participants, confirm the amount, recipients and wallet limits before using it in a busy room.
Finally, treat room chat as semi-public unless you know the deployment and participants. Room URLs can spread. Room operators may have backend visibility. Live activities can be published to relays. Corny Chat is built for open community audio, and that is where it is strongest.
What to test before hosting
If you are hosting a room, create a private rehearsal first. Assign owners, moderators and speakers by exact npub where relevant. Join from two browsers and one mobile device. Test mute, hand raise, speaker promotion, room close, private-room behavior and room description changes. Then inspect whether the room appears as a live activity when it should and disappears or ends when it should.
If the event is scheduled, publish a schedule and verify it from outside your logged-in browser. Check the title, image, start time, end time and room link. Delete or change it once and confirm that deletion behavior is visible. Calendar and live activity events are only useful if other clients and relays can see the current truth.
If money is involved, separate testing from production. Use a small test wallet, a test Lightning address and a low NWC budget. Try a room zap, a participant zap, a server zap goal and any subscription behavior you plan to offer. Check whether zap receipts appear and whether failure messages are understandable.
If you operate the instance, rehearse updates and backups. The update guide stops containers, pulls code, rebuilds images and restarts services. That is normal, but live communities notice downtime. Back up Redis and LNbits. Keep server nsecs and macaroons out of shared notes. Write down how you will recover if a disk, wallet, relay or DNS setting breaks before a public room.
When Corny Chat is a good fit
Corny Chat is a good fit when a Nostr community wants live voice without surrendering all identity and payment context to a closed platform. It is especially interesting for open meetups, dev chats, Bitcoin and Nostr rooms, live podcast backchannels, event office hours and community spaces where public identity and value-for-value support are useful.
It is also a good fit for builders who want to study how a real Nostr media app stitches standards together. The project shows the practical connections between NIP-07 signing, kind 0 metadata, NIP-53 live activities, NIP-52-style schedules, NIP-57 zaps, NIP-47 wallet payments, WebRTC media and operator services. That is more instructive than a clean demo that handles only one event kind.
It is less suitable if you need private enterprise meetings, medical or legal confidentiality, guaranteed support, polished mobile apps, full moderation tooling at large scale or a wallet experience designed for high-value funds. Corny Chat can be useful and still not be the right tool for those jobs.
The healthy expectation is this: use Corny Chat for open or semi-open rooms where Nostr identity, discovery and Lightning value are part of the culture. For anything more sensitive, run your own instance, audit it and test it like communications infrastructure.
The reader takeaway
Corny Chat is one of the more concrete examples of Nostr moving beyond timelines. It takes a familiar social format, live audio rooms, and gives it Nostr-shaped identity, discovery and value flow. A room can have npub-aware participants, public live activity events, scheduled audio spaces, Nostr-linked chat and Lightning payments that fit the moment.
The project is also a reminder that Nostr does not remove normal engineering tradeoffs. Audio still needs WebRTC. WebRTC still needs network traversal. Payments still need wallet permissions. Self-hosting still needs backups and secrets. Relays still differ. A server nsec can still be mishandled. A room URL can still leak.
That is exactly why Corny Chat deserves a careful article rather than a generic app blurb. It is useful because it is specific. It is risky because it is specific. The best way to use it is to match the room to the trust model: public community talk, low-risk signer, limited wallet authority, clear room roles and tested live activity behavior.
If those pieces line up, Corny Chat can make Nostr feel more present and conversational than a feed. You hear people, see familiar npubs, follow the room through relays and send small value in the same social moment. That is a real product shape, and it is worth testing with both curiosity and caution.
Sources worth opening
Start with cornychat.com, the about page, the vicariousdrama/cornychat repository, README, INSTALL, PRIVACY and deployment examples. Then read the pantry Nostr service, live event updater, room chat, personal settings and V4V payment code, plus the NIP-07, NIP-47, NIP-52, NIP-53 and NIP-57 specs.
- Corny Chat live site
- Corny Chat about page
- Corny Chat manifest
- vicariousdrama/cornychat repository
- Corny Chat README
- Corny Chat INSTALL guide
- Corny Chat UPDATE guide
- Corny Chat privacy notes
- Corny Chat UI package metadata
- Corny Chat pantry package metadata
- Nostr backend service
- Live event updater
- Zap goal updater
- Nostr identity verification
- Frontend Nostr helpers
- Room chat payment code
- Personal NWC settings UI
- V4V helper code
- Invoice payment view
- Invoice event payment view
- Corny Chat data types notes
- Deployment environment example
- Docker Compose deployment
- LNbits deployment example
- No Bullshit Bitcoin Corny Chat v2024.05 coverage
- OpenSats August 2024 Nostr grants
- Diego's Jam repository
- Jam Systems upstream project
- NIP-01 basic protocol flow
- NIP-05 identifiers
- NIP-07 browser signer capability
- NIP-09 event deletion
- NIP-47 Nostr Wallet Connect
- NIP-52 calendar events
- NIP-53 live activities
- NIP-57 Lightning zaps
- Nostr Wallet Connect website
- Alby SDK package
- nostr-tools repository
- nostr-relaypool package
- mediasoup project
- coturn project
- MDN WebRTC API
- LNbits documentation
