Describe the bug
During first-run onboarding, selecting Create a community opens Builderlab authentication in the browser. The authentication endpoint fails before any signup UI loads:
login.builderlab.xyz → ERR_SSL_PROTOCOL_ERROR
Buzz remains indefinitely on Waiting for your browser… and provides no error, retry guidance, hosted-service status, or self-hosted alternative.
I reproduced the TLS failure outside the browser as well. A TLS request to login.builderlab.xyz receives a protocol-version alert, while app.builderlab.xyz/api/goose/v1/auth/login responds and redirects into the failing login host.
To reproduce
- Install and launch Buzz as a new user.
- Complete initial identity onboarding.
- Select Create a community.
- Select Sign in to continue.
- The browser opens a redacted URL beginning with:https://login.builderlab.xyz/authorize?...
- Observe ERR_SSL_PROTOCOL_ERROR.
- Return to Buzz and observe that it remains on Waiting for your browser….
Visiting https://builderlab.xyz/ also produced a Cloudflare block page during this attempt.
Expected behavior
Builderlab authentication should load and return the user to Buzz.
If the hosted provider is unavailable, Buzz should promptly detect the failed or abandoned flow and offer:
- Retry hosted setup
- Create a self-hosted community
- Connect to an existing relay
- Service-status or support information
Impact
This blocks a brand-new user at the first community-creation step. Because Create a community currently exposes only the hosted Builderlab route, users cannot discover Buzz’s supported self-hosted path from the failure screen.
Environment
- OS: macOS Golden Gate 27
- Buzz version: 0.4.23 (0.4.23)
- Browser: Chrome Version 150.0.7871.181 (Official Build) (arm64)
Additional context
The complete OAuth URL has intentionally been omitted because it contained temporary state, nonce, and PKCE parameters.
The broader hosted-versus-self-hosted onboarding gap is already tracked in #2312.
Describe the bug
During first-run onboarding, selecting Create a community opens Builderlab authentication in the browser. The authentication endpoint fails before any signup UI loads:
login.builderlab.xyz → ERR_SSL_PROTOCOL_ERROR
Buzz remains indefinitely on Waiting for your browser… and provides no error, retry guidance, hosted-service status, or self-hosted alternative.
I reproduced the TLS failure outside the browser as well. A TLS request to login.builderlab.xyz receives a protocol-version alert, while app.builderlab.xyz/api/goose/v1/auth/login responds and redirects into the failing login host.
To reproduce
Visiting https://builderlab.xyz/ also produced a Cloudflare block page during this attempt.
Expected behavior
Builderlab authentication should load and return the user to Buzz.
If the hosted provider is unavailable, Buzz should promptly detect the failed or abandoned flow and offer:
Impact
This blocks a brand-new user at the first community-creation step. Because Create a community currently exposes only the hosted Builderlab route, users cannot discover Buzz’s supported self-hosted path from the failure screen.
Environment
Additional context
The complete OAuth URL has intentionally been omitted because it contained temporary state, nonce, and PKCE parameters.
The broader hosted-versus-self-hosted onboarding gap is already tracked in #2312.