HiveTalk

Media25 min readNostr-aware video rooms, Honey dashboard, Vanilla WebRTC SFU, Lightning zaps and Swarm relay context

HiveTalk

HiveTalk is not a wallet, not a timeline client and not just a relay. It is a video-room product family around browser calls, Nostr login, room identity, Lightning zaps and Nostr-adjacent infrastructure. The key is separating today's Honey hosted app from the open-source Vanilla SFU and from the separate Swarm relay.

What HiveTalk really is

HiveTalk is best understood as a video-room project for Nostr communities, not as a normal Nostr client. You do not open it primarily to scroll a feed, write a note, manage relays or hold funds. You open it to start or join a browser call with audio, video, screen sharing, room links, participants, chat-like interaction and optional payments around the live moment.

That makes its Apps Hub placement slightly tricky. It belongs in Live Streaming because the user action is live video and real-time rooms. It also belongs on the Media route because the product is about live communication, not wallet custody. Its Nostr relevance comes from identity, room access, scheduled or permanent-room context, public Nostr links and adjacent relay infrastructure. Its Lightning relevance comes from zaps and support flows, not from being a wallet.

The name can also mislead if you do not separate the generations. The open-source repository is Vanilla HiveTalk, a fork of MiroTalk SFU with Nostr and Bitcoin Lightning enhancements. The current public site is Honey, which is described as HiveTalk 2.0 and is still beta. Swarm is a separate Nostr team relay and Blossom server under the same HiveTalk umbrella. Those pieces are related, but they should not be collapsed into one vague app description.

For you as a reader, the useful question is practical. Which surface are you using: Honey, Vanilla or Swarm? Which keys or wallet permissions does that surface ask for? Which server carries the media? Which relay carries Nostr metadata? Which payment path moves sats? HiveTalk becomes much easier to judge once those boundaries stay visible.

Honey is the current front door

A live check on June 13, 2026 showed `https://hivetalk.org/` returning a 301 redirect to `https://honey.hivetalk.org/`. The Honey landing page describes HiveTalk as video conferencing reimagined, with the short promise Nostr-native, Lightning-powered and built for the swarm. It also advertises permanent rooms, schedules, real-time zaps, Nostr sign-in and room-scale claims.

The dashboard page is more concrete than the marketing line. It presents `Hivetalk Honey Dashboard`, a room-code form, active rooms, all events, support, help, a release-note card, a zap goal card and a prompt to log in with Nostr for the best experience. The page also says guests without a Nostr account can join some public permanent rooms, while Nostr login improves the experience.

That matters because Honey is the product most users will see first. If someone follows the old `hivetalk.org` link from an NWC map or a Nostr app list, they are not landing on the older Vanilla front page. They are landing on the newer Honey application. The article therefore has to treat Honey as the current hosted experience, even though the inspectable open-source code is mostly in the Vanilla repository.

The trust model follows from that split. Honey is a hosted web app. You should treat it as an active browser application that can request camera, microphone and screen permissions and can interact with Nostr login state. It may be a good fit for public or semi-public Nostr rooms, but you should not infer its exact code from the Vanilla repo unless a specific Honey source file is public.

Vanilla is the inspectable codebase

Vanilla HiveTalk is the public codebase at `HiveTalk/hivetalksfu`. The README describes it as a fork of MiroTalk SFU with Nostr and Bitcoin Lightning enhancements. It also says that `vanilla.hivetalk.org` was previously known as `hivetalk.org`, and that users looking for HiveTalk 2.0, called Honey, should go to the Honey dashboard.

The repository metadata is useful context. On June 13, 2026, the GitHub API showed the repository as AGPL-3.0 licensed, with 58 stars, 21 forks, zero open issues, default branch `main`, and a push timestamp of June 1, 2026. The package metadata identifies version 1.6.31, Node.js 18 or newer, Express, Socket.IO, mediasoup, OpenID Connect, JWT, Sentry, ZBD-related dependencies and several real-time media features.

The MiroTalk SFU inheritance is not a footnote. Vanilla gets a mature browser conferencing base from MiroTalk SFU: rooms, media transport, WebRTC, host protection, lobby, password protection, REST API, RTMP options, screen recording, polls, file sharing, whiteboard, rich text editor, device selection and mobile behavior. HiveTalk then layers Nostr and Lightning behavior around that base.

That is why Vanilla should be read as infrastructure software, not a tiny Nostr demo. It has real deployment surface: Node, Docker, config files, API keys, TLS, TURN-like network concerns, media ports, JWT secrets, OIDC settings, optional integrations and payment-related environment variables. If you self-host it, you are operating a communications service, not copying a static website.

The Honey beta caveat

The official `HiveTalk/honey-issue-tracker` repository is explicit: it is an issue tracker for HiveTalk Honey, and Honey is not yet open source. It also says Honey is still in beta and points people looking for the Vanilla repository back to `HiveTalk/hivetalksfu`. That short README is one of the most important sources for understanding the current product split.

This caveat is not an accusation. A project can have an open-source predecessor, a hosted beta and an issue tracker without publishing every current source file. It does mean a reader should be precise. Claims about Vanilla code are claims about Vanilla. Claims about Honey should come from the live Honey pages, the Honey issue tracker, visible product behavior, release notes and direct project statements.

The Honey issue list also shows the questions the project wants to answer publicly: how Honey works, how it differs from Zoom or Jitsi, and how related tools such as Posta Nota explain drafts and scheduled notes. That tells you HiveTalk is positioning itself as more than a call link. It wants to be a Nostr-flavored room, event and creator communication environment.

For users, the beta label should shape expectations. Test a room before relying on it for a public event. Check whether guests can join the room type you intend to use. Confirm lock, lobby and moderator behavior. Know that the open-source audit path is weaker for Honey than for Vanilla until Honey source is published.

Room types and access

Honey's dashboard release notes describe three room shapes. Public permanent rooms can use Lock and Lobby so joiners wait for approval, and approved access lasts 24 hours. Private permanent rooms are limited to the owner and moderators. Ephemeral rooms can start instantly without an account and do not give one host the same persistent control surface.

Those distinctions matter in a live-video app because room links spread quickly. A public permanent room is good for communities, office hours and scheduled gatherings, but it needs visible moderation. A private permanent room is better when continuity matters but entry should stay restricted. An ephemeral room is useful for quick calls, but it is not the same governance model as a persistent hosted space.

Vanilla has its own access model. The README describes host protection, user authentication, JWT-based direct join tokens, room password protection and a room lobby. The server code passes host protection settings, user API endpoints and Nostr API endpoint placeholders into the runtime configuration. Direct join can include room, room password, display name, audio, video, screen, notification, token and a `nip98` query parameter.

The practical test is simple and easy to skip. Before a public event, create the exact room type you plan to use and join from a second browser. Test what a guest sees, what a Nostr-logged-in user sees, what a moderator can do, and what happens when the room is locked. In a live call, unclear room authority becomes a moderation problem immediately.

Nostr identity in the room

The Vanilla code contains concrete Nostr identity fields. `Peer.js` stores `peer_pubkey`, `peer_npub` and `peer_lnaddress` as part of peer information. `ServerApi.js` exposes meeting peer data with name, presenter status, npub, pubkey and Lightning address. `RoomClient.js` reads those fields when drawing video elements and participant UI.

The room UI adds a Nostr icon when a participant has an npub. Clicking it calls a helper that embeds a profile view from `https://njump.me/?embed=yes` inside a modal. That is a modest but real Nostr integration. It does not turn the video stream into Nostr data, but it lets a room participant carry recognizable Nostr identity into the meeting surface.

That is useful for Nostr communities because many participants already know each other by npub, profile picture, display name and Lightning address rather than by email or workplace account. A call room that can show a profile link can reduce ambiguity, especially in public Nostr events where a handle alone may not prove much.

The risk is equally ordinary. Nostr identity is only as strong as the signer and key control behind it. A stolen key, shared team key, fake profile or typo-similar npub can still mislead a room. Profile display is context, not magic authentication. For high-trust rooms, verify the exact npub and use moderation controls, not only profile pictures.

NIP-98 is present but unfinished in Vanilla

HiveTalk's code references NIP-98, but the exact state matters. The `app/api/nip98/nip98_client.js` file starts with the comment that it is sample code only and does not work in production. It sketches a `window.nostr` flow that creates a kind 27235 HTTP-auth event, signs it with a browser signer and sends it as a `Nostr` authorization header.

The server-side sample at `app/api/nip98/nip98_server.js` is also commented as sample code only. It shows the expected checks for a NIP-98 event: kind 27235, timestamp window, URL tag, method tag, optional payload hash and signature verification through `nostr-tools`. That is educational, but it is not evidence that the hosted Honey app or the Vanilla join route fully enforces NIP-98 today.

The main `Server.js` join route reinforces that caution. It parses a `nip98` query parameter and has a TODO saying to finish NIP-98 auth for direct join, with a commented-out validation block. There are duplicate `/nauth` stubs with comments about Nostr-protected login rooms and a Nostr auth API endpoint. The direction is visible; the production claim is not.

The right reader takeaway is careful. HiveTalk has a clear NIP-98 design trail and Swarm uses NIP-98 for scheduled notes and Blossom upload authentication, but Vanilla's direct-join NIP-98 code should not be described as finished unless a current deployment proves it. If a room claims Nostr-authenticated entry, test the signer prompt and denial path before depending on it.

Lightning inside HiveTalk

HiveTalk's Lightning behavior is more concrete than a logo on a landing page. Vanilla's `Room.html`, `landing.html`, `active.html` and support views import Alby's Bitcoin Connect package and the Lightning Address helper. The client code can request an invoice from a Lightning Address and open a payment modal. The landing page zap flow uses `donate@hivetalk.org` for support.

Inside a room, `RoomClient.js` adds a zap button when a peer has a Lightning address. The modal asks for a sats amount, offers presets such as 21, 100, 500 and 1000 sats, requests an invoice and broadcasts a message after the payment flow. That is a social payment surface attached to a participant, not a separate wallet dashboard.

The server also exposes ZBD payment endpoints. `/api/zbd/charge` creates a ZBD charge using `ZBD_API_KEY`, amount, description and an internal zap id, then returns a BOLT11 invoice request. `/api/zbd/charge/:paymentHash` checks whether the charge is completed. That is a different Lightning path from Lightning Address, and it adds another API-secret and provider trust surface.

The boundary is important. HiveTalk is not a wallet and does not become a Nostr Wallet Connect node just because it can request or check invoices. It is a video-room app with Lightning support. Treat any wallet connection or invoice modal as money movement. Use small amounts, a wallet with clear limits and a separate test flow before using zaps in a busy room.

Zap goals and support pressure

Vanilla includes a zap-goal gate that is unusual for a video app. The server middleware reads `ZAP_GOAL_SATS` and `ZAP_GOAL_API_URL`, checks the current balance through an API, and on the last day of the month can redirect room creation and joining to `/zapgoal` if the monthly goal is not met. The code allows access on API errors to avoid downtime.

The `zapgoal.html` page explains the user-facing version of that logic. It says room creation and joining will be re-enabled when the Vanilla zap goal is met, shows a progress card, and links users toward Honey. The page also imports Bitcoin Connect related code for payment handling. Whether an operator enables this feature depends on environment configuration, but the code path is real.

There are two ways to read this feature. On the generous side, live video infrastructure costs money, especially when TURN, SFU, bandwidth and time are involved. A visible zap goal makes support concrete. On the caution side, gating room access around a monthly payment goal can surprise users if they did not expect it or if the support API misreports state.

For operators, the lesson is transparency. If you use zap goals to fund a HiveTalk instance, say so before users depend on the room. Keep support wallets separate from personal funds. Test the last-day behavior. Make sure the error path cannot lock everyone out because of a provider issue. For users, know whether the instance is community-funded, commercial, beta or personal.

Swarm is adjacent infrastructure

Swarm is part of the HiveTalk ecosystem, but it is not the video conference room. The live Swarm page calls it a Nostr relay and Blossom server for the HiveTalk team. It advertises the WebSocket relay endpoint `wss://swarm.hivetalk.org`, a Bouquet client for blobs, a Curator client for relay inspection, scheduled notes APIs and Blossom upload, list and mirror endpoints.

The Swarm GitHub repository describes the software as a Nostr team relay forked from Bitvora's team-relay with modifications for `Swarm.hivetalk.org`. Its README describes team-domain access control, public and team-member allowed kinds, trusted-client support, rate limiting, spam protection, delete capabilities, Docker support and a Blossom media server with S3-compatible storage.

Swarm's scheduled-note and Blossom endpoints use NIP-98 authentication. That is an important contrast with Vanilla. In Swarm, NIP-98 is part of the documented relay and media API surface. In Vanilla, NIP-98 appears as sample or unfinished direct-join work. A reader should not transfer one claim to the other without checking the route.

This adjacent infrastructure helps explain HiveTalk's broader direction. The project is not only building a call UI. It is experimenting with Nostr rooms, team relay policy, Blossom media, scheduled posts, support zaps and creator communication tools. That makes the ecosystem interesting, but it also means every component has its own trust boundary.

Standards and what they do not cover

HiveTalk touches several Nostr standards, but the video itself is not carried by Nostr relays. NIP-01 explains the basic event and relay model. NIP-07 explains the `window.nostr` browser-signer capability. NIP-11 explains relay information documents. NIP-47 explains Nostr Wallet Connect, which is relevant to wallet automation generally but not proven as HiveTalk's core payment path from the code inspected here.

NIP-98 is the most visible protocol candidate in the Vanilla code and Swarm docs. It can authenticate HTTP requests with signed Nostr events. That fits room access, scheduled notes and Blossom upload flows. But a commented sample and a TODO are not the same as a production feature. The article therefore treats NIP-98 as a design and audit point, not a finished Vanilla guarantee.

NIP-53 live activities are relevant to live rooms in the Nostr ecosystem, but HiveTalk should not be casually described as a NIP-53 publisher unless current Honey or Vanilla code proves kind 30311 or kind 1311 behavior. Honey's landing page says permanent rooms and scheduled events; it does not by itself prove NIP-53 interoperability. This is exactly where careful wording matters.

The bigger point is that Nostr can identify, announce, authenticate and pay around a live room without replacing WebRTC. WebRTC, mediasoup, Socket.IO, TURN-like traversal, browser permissions and server configuration still do the media work. Nostr adds portable identity and signed intent around the call. It does not remove normal video infrastructure.

WebRTC and SFU trust

A HiveTalk call is a browser media session. Vanilla inherits MiroTalk SFU concepts and depends on mediasoup for selective forwarding. That gives the app a practical path beyond tiny peer-to-peer calls. It can route media through server infrastructure, support screen sharing, device selection, recording options, RTMP-related paths and room features that a basic WebRTC sample would not provide.

The cost is that the SFU and related infrastructure become part of the trust boundary. A server that helps forward media can affect availability, quality, metadata and sometimes recording or monitoring behavior depending on configuration. TURN or relay infrastructure can carry traffic when direct connectivity fails. Browser permission prompts control access to camera, microphone and screen.

This is not a HiveTalk-specific weakness. It is how browser video works. The mistake is treating a Nostr login as if it makes the media layer decentralized or private by default. A Nostr key can prove who is joining or authorize an action. It does not automatically encrypt the room end to end against the SFU or make screen sharing safe.

Before joining, inspect the domain and permissions. Before hosting, test audio, video, screen sharing, mobile networks, bandwidth, browser compatibility, room lock, lobby and recording expectations. For sensitive calls, use a tool and deployment model designed for that threat model. HiveTalk's strongest natural fit is public or semi-public Nostr community video.

Privacy and analytics clues

The public Honey pages include an Umami analytics script from `umami.hivetalk.org`. That does not automatically mean invasive tracking, but it is a visible analytics dependency and should be treated as part of the hosted-site privacy surface. Vanilla also supports Sentry error reporting through configuration, and its README lists Sentry among features. Operators can configure or disable parts of that stack.

The dashboard and room model also imply ordinary call metadata. A server may know room identifiers, active room state, participant counts, timestamps, IP-level connection information, browser requests, failed joins and support-payment interactions. Some of that is necessary for a video app to function. The question is what the specific instance logs, retains and exposes.

Nostr adds another public-data layer. If the app or related tools publish events, use relay endpoints or embed Nostr profiles, some identity and activity context may become visible outside the room. A public npub and Lightning address are not private. A scheduled room or active-room listing can reveal community patterns even if the media itself is not archived.

The safest user posture is to assume public or semi-public context unless the instance operator proves otherwise. Use a browser profile that fits the risk. Deny microphone and camera until needed. Avoid screen sharing private windows. If you use Nostr login, read the signer prompt. If you use zaps, assume the payment metadata may be visible to the app, wallet provider or relevant Lightning path.

Security and release signals

The latest Vanilla release visible during research was v0.0.5, published on June 1, 2026. Its release notes are unusually useful because they show maintenance work rather than only product optimism. The release removed the `ngrok` dependency because of a high severity command-injection vulnerability with no patched version available, forced `serialize-javascript` to a safer version, adjusted UUID versions and updated dependencies.

The same release notes mention CI/CD fixes, axios, nodemailer, DOMPurify, WebSocket and Socket.IO-related dependency updates, optional ngrok fallback, default API secret adjustments, links changed from `hivetalk.org` to `vanilla.hivetalk.org`, Vanilla branding, Honey links, fixed dead endpoints and updated `nostr.json` configurations. That is a strong sign that the maintainers are reacting to real operational and security issues.

Security work is good, but it also tells you what the risk class is. A video conferencing app with server-side Node code, HTML parsing, WebSocket communication, REST APIs, payment endpoints and browser imports has a wide dependency surface. Even if the Nostr layer is small, the web app layer is not.

If you self-host, do not freeze a clone and forget it. Track releases, run dependency audits, rotate secrets, update Docker images, review environment variables and keep the ability to roll back. If you use a hosted HiveTalk surface, understand that you are relying on the operator to do that maintenance for you.

Self-hosting Vanilla

Vanilla's README gives a normal Node path: clone the repository, copy `app/src/config.template.js` to `app/src/config.js`, install dependencies and run `npm start`, with port 3010 as the default. It also documents Docker and REST API examples. The repository includes a Dockerfile, install script, Docker Compose template, SSL docs and API docs derived from MiroTalk SFU.

The dependency list tells you what you are taking on. Express serves the app. Socket.IO handles real-time signaling. mediasoup handles SFU behavior. OpenID Connect and JWT handle authentication features. DOMPurify and xss-related client code help sanitize surfaces. Sentry can capture errors. ZBD and Lightning Address or Bitcoin Connect code can move payment flows around the app.

Self-hosting therefore needs more than one command. You need TLS, media ports, domain routing, firewall rules, secrets, API keys, room policy, payment provider keys, monitoring, backups and an update plan. If you expose RTMP, recording, file sharing or AI features, the blast radius grows. If you enable support zaps or ZBD charge creation, money-related secrets enter the deployment.

For a small Nostr community, self-hosting can still be attractive. You can choose room policy, keep branding local, avoid relying entirely on a commercial video platform and integrate Nostr identity in a familiar context. Just treat the instance like communications infrastructure. A broken update before a live event is more damaging than a broken blog page.

What to test before joining

Start with the surface. If the URL is `hivetalk.org`, expect a redirect to Honey. If it is `honey.hivetalk.org`, you are in the hosted beta. If it is `vanilla.hivetalk.org`, note that this host was not reachable from the local check on June 13, 2026 even though the repository still points to it. If it is `swarm.hivetalk.org`, you are looking at relay and Blossom infrastructure, not the call room.

Then test permissions. Open the room without immediately granting camera, microphone or screen access. If you only need to listen, keep microphone denied until needed. If you screen share, close unrelated windows and browser tabs first. Watch whether the app asks for notification, clipboard, camera, microphone or display-capture privileges.

Next, test Nostr login with a low-risk key or a signer you trust. A login prompt should be understandable. If a site asks for a broad signature, a raw private key or a permission you do not understand, stop and inspect. If the room displays your npub, open the profile icon and confirm it points to the expected public profile.

Finally, test payments with tiny amounts. If the room zap flow uses a Lightning Address, confirm the recipient. If a support button uses a zap goal or ZBD invoice, confirm the amount and invoice. Do not attach a high-value wallet to a video-room beta. A social payment should be reversible in your habits even when Lightning itself is not reversible.

What to test before hosting

If you host a Honey room, rehearse the exact room type before inviting people. Test a public permanent room with Lock and Lobby, a private permanent room and an ephemeral room. Verify who can join as a guest, who needs Nostr login, who can approve lobby requests, who can promote moderators and what happens when an approved guest returns later.

If you self-host Vanilla, run through the boring infrastructure checks first. Confirm HTTPS, server ports, media quality, browser support, mobile support, firewall behavior, CPU, memory, disk, logs, restart behavior, backups and update procedures. If you enable recording or file sharing, write down what is stored and where. If you enable RTMP, test it before the event.

If you enable Nostr-related access, do not rely on comments. Verify the actual path. Does NIP-98 block unauthenticated requests? Does `/nauth` validate anything? Does a direct-join `nip98` parameter do what you expect? Does the app show npubs correctly? Does it prevent spoofed room authority? If the code is still TODO, design your event around host, lobby and JWT controls instead.

If you enable Lightning, separate operational funds. Use low-value wallets, restricted API keys, limited providers and clear support language. Test Lightning Address payments, ZBD charge creation, zap-goal display and failure behavior. A payment feature that fails quietly during a live event will confuse users and create support work.

When HiveTalk is a good fit

HiveTalk is a good fit when a Nostr group wants video calls with less platform baggage than a closed meeting account and more Nostr context than a generic WebRTC room. It is especially interesting for public town halls, builder sessions, protocol workshops, Nostr meetups, creator calls, project office hours and events where participants already know each other by npub.

It is also useful as a study object. Vanilla shows how a MiroTalk SFU base can be extended with Nostr profile fields, npub display, Lightning Address zaps, Bitcoin Connect payments, ZBD charges and a NIP-98 design trail. Honey shows how the product direction is moving toward permanent rooms, schedules, active rooms and Nostr login. Swarm shows the team-relay and Blossom side of the same ecosystem.

HiveTalk is a weaker fit if you need audited enterprise confidentiality, mature compliance controls, guaranteed support, published source for every current hosted component, high-value wallet automation or proven NIP-98 room authentication today. It may become stronger in some of those areas, but you should not assume them from the name.

The healthy expectation is this: use HiveTalk where live community presence, Nostr identity and small Lightning support make the room better. For sensitive meetings, treat it like any other video stack and evaluate the operator, code, media path, logging, access control and update discipline before you rely on it.

The reader takeaway

HiveTalk is one of the more interesting live-media projects in the Nostr orbit because it is not trying to make a feed slightly different. It is trying to make real-time rooms feel native to a Nostr community: people join by room link, show public identity, manage persistent or ephemeral spaces and send small value around the live moment.

The project is also messy in the way real software is messy. Honey is current and beta. Vanilla is open source and inspectable. Swarm is related infrastructure. NIP-98 is serious in Swarm and unfinished in parts of Vanilla. Lightning appears through multiple payment paths. WebRTC still carries the call. Those distinctions make the article longer, but they keep the product honest.

For a user, the main advice is to join deliberately: check the domain, understand the room type, read the signer prompt, guard camera and screen permissions, and use tiny payment limits. For a host, the advice is to rehearse: test room authority, media quality, Nostr login, privacy settings, payment flows and update behavior before the public room starts.

If those checks pass, HiveTalk can be a lively bridge between Nostr identity and real-time conversation. It lets an npub be more than a profile on a timeline. It can become a person in a room, a speaker in a live event and a recipient of a small zap. That is a good reason to pay attention, with the same caution you would bring to any live communication tool.

Sources worth opening

Start with hivetalk.org, the Honey dashboard, the HiveTalk GitHub organization, Vanilla HiveTalk README, release v0.0.5, Honey issue tracker, Swarm relay page and the code paths for RoomClient, Server, NIP-98 samples and Bitcoin Connect payments. Then compare NIP-01, NIP-07, NIP-11, NIP-47, NIP-53, NIP-98, WebRTC, mediasoup, MiroTalk SFU and Blossom/Khatru references.

• HiveTalk live entry point
• HiveTalk Honey dashboard
• Vanilla HiveTalk live URL
• HiveTalk GitHub organization
• HiveTalk/hivetalksfu repository
• Vanilla HiveTalk README
• Vanilla HiveTalk release v0.0.5
• Vanilla HiveTalk releases
• Vanilla HiveTalk package metadata
• Vanilla HiveTalk server code
• Vanilla HiveTalk RoomClient code
• Vanilla HiveTalk Room HTML
• Vanilla HiveTalk landing payment code
• Vanilla HiveTalk Landing.js
• Vanilla HiveTalk zap goal page
• Vanilla HiveTalk REST API notes
• Vanilla HiveTalk NIP-98 client sample
• Vanilla HiveTalk NIP-98 server sample
• Vanilla HiveTalk ServerApi peer data
• Vanilla HiveTalk Peer model
• Vanilla HiveTalk security policy
• Vanilla HiveTalk Docker Compose template
• Vanilla HiveTalk install script
• HiveTalk Honey issue tracker
• Honey issue: How is HiveTalk different
• Honey issue: How it works
• Swarm Relay live page
• HiveTalk Swarm repository
• HiveTalk quick relay install
• MiroTalk SFU upstream
• MiroTalk SFU docs
• mediasoup project
• MDN WebRTC API
• Bitcoin Connect package
• Alby Lightning tools package
• ZBD API documentation
• Awesome NWC list
• NIP-01 basic protocol flow
• NIP-07 browser signer capability
• NIP-11 relay information document
• NIP-47 Nostr Wallet Connect
• NIP-53 live activities
• NIP-98 HTTP auth
• Khatru relay framework
• Khatru Blossom docs