Can't send invites to a self hosted relay

[RooSoft]

Describe the bug
Running Buzz on MacOS, with a buzz relay running on NixOS.

Trying to copy the invite link fails with Couldn’t copy the invite link. Try again.

Steps to reproduce

1. Go to Settings/Invites
2. Click on Invite to Community
3. Click Copy link
4. Couldn’t copy the invite link. Try again.
5. Feeling lonely in the community :(

Expected behavior
Needed a link to invite collaborators, got to the link interface, got no link.

Version and platform
Find your version at the bottom of the Settings sidebar. Write "unknown" if you can't determine it.

• Buzz version: Buzz v0.4.46
• OS: MacOS on a Macbook Pro M1

Logs / additional context
No idea where logs are, would love to know

[mesasix]

same issue here

Buzz Version 0.4.26 (0.4.26)
PS: Mac OS On Mac Studio M4 Max

[mesasix]

actually, thanks to Hermes:

I found and fixed the cause: Spark 1’s relay was blocking the Buzz Desktop app’s Tauri origin through its CORS configuration, so the invite request never reached the server.

I added the required desktop origins, restarted Buzz, and verified:

Relay is healthy
HTTPS endpoint is live
Tauri invite preflight now returns HTTP 200
tauri://localhost is explicitly allowed

just tried it, and it works @RooSoft

[RooSoft]

@mesasix seems to work just fine, thank you very very much!

Will leave the issue dangling for Block to notice, in case they want to do something about it.

[nerdynigel]

Confirmed same issue for me that was resolved by Codex

[0x3639]

Confirmed this same issue and the recommended fix worked for me. Thank you

[derekgdicamillo]

Hit the same failure ("Couldn't create invite link") on a self-hosted relay (deploy/compose bundle, desktop 0.5.8 on Windows) and tracked down the root cause — it's CORS, and it matches what's described in #2872 / #3490:

Root cause: the desktop app mints invites via a webview fetch() to POST /api/invites (desktop/src/shared/api/invites.ts), which is subject to the browser's CORS check. deploy/compose/.env.example sets BUZZ_CORS_ORIGINS to only the relay's public origin, so the Tauri webview origin (http://tauri.localhost on Windows WebView2; tauri://localhost on macOS — which would be your case) is rejected at preflight. The request never reaches the relay, so nothing shows in relay logs, and the desktop surfaces it as a generic invite/clipboard failure.

Workaround that fixed it for me — add the Tauri origins to the allowlist in your relay env:

BUZZ_CORS_ORIGINS=https://<your-host>,http://tauri.localhost,https://tauri.localhost,tauri://localhost

then restart the relay. Invite creation worked immediately afterward.

Repro from a clean default config: self-host via deploy/compose with the stock .env.example, join as owner from desktop, open Invites, click create link → "Couldn't create invite link", zero relay-side signal (see #3636 for why it's invisible in logs). Block-hosted relays don't exhibit this, presumably because they allowlist the desktop origins — so it bites self-hosters specifically.

Proper fixes are already open: #2888 (add the Tauri origins to the compose .env.example default) and #3595 (relay always admits the desktop webview origins when an allowlist is set). Either would resolve this issue.