[SashaMIT]

Chat in Home shows the invite, join and access controls again. This is the "URI for connecting peer to peer" that went missing. Draft for review on feat/0.7.1-models, independent of the phone PR.

What was wrong

Since bf7e14586 (direct and shared conversation UI, Aug 10), chat_control_policy has shown the access toggle, the Access panel with Create join link, the join box and pending join requests only when the room is not in Home (!shell_mode). Their handlers refuse everywhere except Home:

• create_conversation_join_invite: "conversation links are only available from Home"
• join_conversation_from_invite: "conversation links must be opened from Home"

So in Home the controls were hidden, and anywhere else they were visible but refused. Before bf7e14586 these controls were Home-only (is_shell_mode()), so this looks like an inverted condition rather than a design decision.

Join/leave lines are written per Runtime (room_service.rs), so they only appear once two Homes share a room. Without the invite link there was no way to get there, which is why no join messages showed.

Change

• chat_control_policy: the access toggle, Access panel, join box and join requests show in Home again (room_mode_known && shell_mode && !configured). Send and attach are unchanged.
• The join button is enabled whenever the join box shows. Before, it followed the gateway-controls flag, which needs an active session, and the join box only shows without one.
• Rebuilt chat_room_ui.js / chat_room_ui_bg.wasm with scripts/build-chat-room-ui.sh, updated .chat_room_ui_source.sha256, and bumped the asset version to chat-room-ui-20260929a.
• Tests: four policy cases flipped to the Home-only rule (shell_isolated, gateway_isolated, unconfigured_gateway, unconfigured_shell) and shell_isolated_unjoined added.

Question for review

I kept !configured: when collaboration is configured, these controls stay hidden in Home as they are today. If configured rooms should also offer the invite link, that's a one-term change.

Gates

• cargo test in capsules/chat-room-ui (30 pass) and cargo fmt --check.
• home-entropy-check, chat behaviour and layout smokes, source gate 14/14.
• Not yet checked with two Homes sharing a room; that is the end-to-end test for the join lines.

Made with Cursor

Part of #86

[irzhywau]

This PR is tracked in the #86 implementation checklist: #86 (comment)

Two points from that plan affect this PR:

• The server join step still refuses. invites/join and invites/claim in api/gateway_room.rs answer "Room join claims are unavailable through this legacy transport path", so a second Home cannot join from the link yet. The two-Home test will show this.
• G3 Community chat: Chat and People with Home #86 moves every Home onto the shared Community network by default. Those Homes are configured, so !configured hides these controls for them again. The plan treats that as a decision for this PR: finish the legacy join path, or move the invite link onto the configured network.

The #86 work branch also changes the Chat UI and its built files, so it will rebase on this PR after it merges and rebuild Chat once.

[andersalm]

Agreed with @irzhywau: this stays a draft until the server join step works (see #86). Invite links come with that work in 0.7.2. Nothing broken or confusing ships.

[SashaMIT]

Closing as agreed with Anders. Invite links and QR codes stay out of the first user release (0.8.0), and the server currently refuses room joins (409), so these controls would only lead to a refusal. Invites come back as stages 2 and 3 of #86 once there is a server join path. The branch fix/chat-invite-in-home-0.7.1-models is kept.