Skip to content

Self-host onboarding dead-ends: 'I already have a community' → 'I own the community' only offers Builderlab, never a relay URL #2816

Open
Open
Self-host onboarding dead-ends: 'I already have a community' → 'I own the community' only offers Builderlab, never a relay URL#2816

Description

@ryanmitchellneely
ryanmitchellneely
opened on Jul 25, 2026

Summary

An operator who runs their own relay and owns it picks the two semantically correct answers in onboarding and lands in a hosted-account flow with no way to enter their relay. The self-host path exists, but it is behind Join a community, which reads like the option for someone joining somebody else's workspace.

Steps to reproduce

  1. Stand up a self-hosted relay (auth + membership required), add your own pubkey via buzz-admin add-member
  2. Desktop app → Use an existing key with the owner identity
  3. I already have a community → I own the community

Actual

A modal appears: Set up your community — Sign in to connect a community you already own or create a new one. We'll open Builderlab in your browser, then bring you back to Buzz. The only action is Sign in to continue, which opens Builderlab and creates a hosted account. At no point does the flow ask for a relay URL, and dismissing the modal returns to the same fork.

Expected

The path that says I own the community should be the path where a self-hoster types their relay URL. At minimum, an escape hatch on that modal (Connect a self-hosted relay instead).

What actually works

Join a community → paste wss://relay.example.com → the app connects, resolves the community, and proceeds to profile setup normally. That is the correct flow for a self-hoster; it is just labelled as if it were not.

Impact

This is the first five minutes of the product for exactly the audience the OSS repo is aimed at. In our case it cost about forty minutes and produced a stray hosted account before we found the right door. Two smaller things compound it: the relay-owner identity is minted with buzz-admin generate-key in hex, which the key field rejects (#2815), and there is no visible relay-URL field until you take the Join branch.

Suggested fix

Reword the fork, or have I own the community offer both Connect my relay and Use Builderlab hosting. Happy to send a PR if you want the former.

Activity

  1. Chessing234 commented on Jul 25, 2026

    @Chessing234
    Chessing234
    on Jul 25, 2026
    Contributor

    Fixed in #2824 — owner path now offers self-hosted relay URL or Builderlab.

  2. varunyn commented on Jul 25, 2026

    @varunyn
    varunyn
    on Jul 25, 2026

    Thanks for creating fix. Waiting for it to merge. Can't use mac app with self host right now

  3. sayre4ux commented on Jul 28, 2026

    @sayre4ux
    sayre4ux
    on Jul 28, 2026

    Temporary workaround for self-hosted macOS users:

    1. Choose I already have a community → I’m a member or admin.

    2. Enter the relay URL, e.g. ws://192.168.50.12:3000.

    3. If Buzz shows Load failed, set this in deploy/compose/.env:

      BUZZ_CORS_ORIGINS=tauri://localhost

    4. Restart the relay with cd deploy/compose && ./run.sh restart.

    This worked for me on Buzz Desktop 0.4.26.

  4. varunyn commented on Jul 28, 2026

    @varunyn
    varunyn
    on Jul 28, 2026

    Thanks @sayre4ux this solution worked as workaround

  5. Chessing234
    added a commit that references this issue on Aug 3, 2026

    fix(desktop): offer self-hosted relay on owner onboarding

    eb76289

  6. morthenjensen-wq commented on Aug 4, 2026

    @morthenjensen-wq
    morthenjensen-wq
    on Aug 4, 2026

    Confirmed against current main (feccf4ea). The relay connection itself works: entering a ws:///wss:// community URL reaches the existing reconnect flow and restores the identity's relay role. The dead end is the choice model: the owner answer is still coupled to Block hosting.

    A provider-neutral split is to ask how to reconnect rather than infer hosting from the user's role:

    • Sign in to Block hosting → existing Builderlab flow
    • Connect with a community URL → existing relay/invite form

    I validated that routing locally with the desktop formatter, TypeScript typecheck, E2E build, and the focused Playwright onboarding regression (1 passed). I am not opening a competing PR because #2824 already has an implementation in flight. Happy to contribute the focused regression test or adapt it if maintainers prefer the two-action wording above.

  7. ryanmitchellneely commented on Aug 4, 2026

    @ryanmitchellneely
    ryanmitchellneely
    on Aug 4, 2026
    Author

    Fix PR review posted on #2824 — approve / please merge.

    Owner path correctly offers self-hosted relay URL vs Builderlab; no longer dead-ends into hosted-only. Related generate-key nsec + compose git-data chown look good too.

    — Ryan (issue author)

  8. morkalg commented on Aug 7, 2026

    @morkalg
    morkalg
    on Aug 7, 2026

    Confirmed this exact dead end on Buzz Desktop v0.5.6, Windows 10 x64, with an existing owner identity already recognized by a private self-hosted relay.

    Observed path:

    1. I already have a community
    2. I own the community
    3. Builderlab-only modal with Sign in to continue; no relay URL or self-host option

    The working workaround remains:

    1. Close the Builderlab modal.
    2. Choose I'm a member or admin.
    3. Enter the self-hosted wss:// community URL.
    4. The relay restores the identity's actual owner role and proceeds to profile setup; no invite code is required.

    This is especially confusing because the semantically correct owner choice is the wrong operational route. PR #2824 appears intended to fix it, but the current v0.5.6 release still contains the dead end.

  9. morthenjensen-wq commented on Aug 8, 2026

    @morthenjensen-wq
    morthenjensen-wq
    on Aug 8, 2026 via email
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions