[loganj]

🤖

Summary

• Before: creating a hosted community in Settings → Plugins → Builderlab → Create community only copied the new address to the clipboard. The person was not joined, and the community did not appear in their community list until they pasted the address into Join a community themselves.
• Now: after the community is created, the app opens the join dialog for it at once. The dialog connects to the new address without asking for it, so the person goes straight to the remaining join steps (access, when the community asks for it, then profile). When they finish, the app switches to the new community and it shows in the community list.
• If the app cannot open the join (no signed-in identity yet), the card falls back to the old behavior and copies the address.
• This matches first-run onboarding, where Create a community already looks up the new address and joins it without asking for it again. Settings now does the same, through the join dialog that the community picker uses.

create-community-join.mp4

Before create	Create form	Join opens by itself	Listed and selected

Details

• Plugins get a new optional host capability, communityJoin.open(address). It feeds the same invite intent that invite links and the community picker use, marked as already submitted, so the join dialog skips its Community URL step and starts connecting. It does not bypass admission or profile setup, and it returns false when no identity is ready. The plugin authoring guide documents it.
• Deep links cannot set the "already submitted" mark: invite links are parsed into an explicit address and code, so auto-connect stays limited to calls from inside the app.
• A create that finishes after the Settings card closed, or after the card's operation was replaced, does not open the join.
• Which join steps appear depends on the build. With federated identity on a hosted community, the account's consent covers the access step, so it is skipped, as in first-run onboarding. In other builds (such as the development broker) the dialog shows the access step first, while first-run onboarding skips it for a just-created community when the community asks for no age or terms confirmation. The profile step offers Continue when the person already has a profile on that relay and Publish otherwise.

Testing

• New browser case (+1/−0), tests/browser/hosted-create-join.spec.mjs: create from the picker's Create community flow, join opens without the address step, the person continues, the app switches to the new community and the picker lists it. It passes in Chromium and WebKit, and fails in both when the join call is removed. The recording and screenshots above come from this case.
• The browser case uses a viewer that already has a profile on the new relay. Publishing a first profile and the access step are covered by the existing join dialog tests, not by this case.
• Unit tests cover the card's join, the copy fallback, and a late create after the card retires or unmounts.
• Not run: a native desktop build against a real hosted community service.

Known limits

• If the identity changes while a create is in flight on the development broker, the join can open for the new identity. Signed-in builds remount the card on identity change, so this applies to the broker path only.
• If the created address is already in the person's list (for example, a deleted community that was created again), the app selects the saved entry instead of running the join steps.
• After the person dismisses the join dialog, the card offers no join button; they can use Copy address and then Join a community.

🤖 Generated with Claude Code

[wesbillman]

🤖 Star Lord automated source review via Wes’s account, with independent Rocket, Mantis and Groot coverage.

Follow-up reviewed at e4671cb5303c0b61a1207cc042aee1d2a7932d35, target/merge-base 70a8aebdc9656bd808f791d91b283937ec37cec9, focusing on the five-file delta since 5217b85c99950bd217d5e9a88d3cbddae58ed083.

No new actionable findings in this delta. Invalid origins now return false before invite state changes, enabling the caller’s existing copy fallback; the optional Context declaration and documentation now agree. Builderlab still explicitly requires injection, so its activation requirements are unchanged.

The prior navigation P2 remains unchanged and acknowledged/deferred to the separate all-entry-points follow-up described in the author’s reply. This revision does not repair that gap.

Source-only: no tests, builds, app or auth flows run. The delta adds no regression tests for these contract changes. PR description and attachment URLs are unchanged; prior inspection covered four screenshots and sampled recording frames, not the full recording. Native hosted provisioning and runtime identity timing remain unverified.

[tellaho]

🤖 Taylor’s follow-up: LGTM; no further follow-up planned.

Review context: earlier review at 5217b85c9995 (2026-11-07).

[kazemek21]

Kyle reviewed this PR and the Nexus review-tracker notes and approved with no comments.

Posted by Codex (gpt-6.1-sol) on behalf of kylez