Feature/register Support new account creation/registration

[TigerInYourDream]

Summary

Implemented a complete user registration flow for Matrix accounts with support for both password-based and SSO registration methods.

Key Features

• Full registration screen UI with modern design
• Dual registration methods:
  • Password-based registration for custom homeservers
  • SSO registration via Google OAuth for matrix.org
• Smart homeserver selection with automatic mode switching
• Comprehensive form validation:
  • Username requirement checking
  • Password minimum length (8 characters)
  • Password confirmation matching
  • Custom homeserver URL validation
• Registration status modal with real-time feedback
• SSO state management synchronized with login screen
• Clean error handling with user-friendly notifications

Technical Implementation

• Follows Element's approach: SSO flow shared between login and registration
• Matrix server automatically handles account creation vs login based on OAuth identity
• Integrated with existing authentication infrastructure
• Consistent UX patterns with login screen
• Simplified UIA handling (supports m.login.dummy flow)

UI/UX Improvements

• Clear visual feedback during registration process
• Disabled button states to prevent duplicate submissions
• Informative status messages during SSO flow
• Responsive modal dialogs for registration status
• Consistent styling with existing Robrix design language

[Copilot]

Pull Request Overview

This PR implements a comprehensive user registration feature for Matrix accounts, supporting both password-based registration for custom homeservers and SSO registration (via Google OAuth) for matrix.org. The implementation follows Element's approach where the SSO flow is shared between login and registration, with the Matrix server automatically determining whether to create a new account or log in an existing user.

Key Changes

• New registration screen with dual registration modes (password/SSO) and homeserver selection
• Registration logic with UIA (User-Interactive Authentication) handling for m.login.dummy and m.login.registration_token flows
• SSO flow enhancement to support both login and registration contexts with dedicated action types

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 16 comments.

Show a summary per file

File	Description
src/sliding_sync.rs	Adds register_user() function for password registration with UIA support, new MatrixRequest::Register variant, and enhances spawn_sso_server() to handle both login and registration
src/register/register_screen.rs	Complete registration UI with homeserver selection, form validation, password/SSO modes, and state management
src/register/register_status_modal.rs	Modal dialog for displaying registration progress with cancel functionality
src/register/mod.rs	Module definition for registration components
src/app.rs	Navigation handling between login/register screens and registration success flow
src/login/login_screen.rs	Replaces external signup URL with navigation to new register screen
src/lib.rs	Adds register module declaration
src/home/main_desktop_ui.rs	Adds state reset to prevent dock restoration issue
src/home/rooms_list_header.rs	Refines offline notification logic to avoid spurious error popups

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

[nitpick] Inconsistent comment: The comment on lines 337-338 states "Don't save the session here - it will be saved when we convert to LoginBySSOSuccess". However, this comment is placed in the password-based registration flow, not the SSO flow.

The password registration returns a client/session that gets passed to LoginBySSOSuccess on line 709, so the comment makes sense in context but could be clearer. Consider moving or clarifying this comment to explain that session persistence happens in the login flow that follows.

Suggested change

	// Don't save the session here - it will be saved when we convert to LoginBySSOSuccess
	// This avoids duplicate session persistence
	// Don't save the session here—session persistence is handled in the login flow that follows
	// (e.g., when passing to LoginBySSOSuccess). This avoids duplicate session persistence.

[TigerInYourDream]

State Transition: Registration → Login

Background

In the Matrix SDK, successful registration also means successful login. This is documented in https://docs.rs/matrix-sdk/0.16.0/matrix_sdk/authentication/matrix/struct.MatrixAuth.html#method.register and verified by
Element's behavior—after registration, users go directly to the chat interface.

The Challenge

Robrix uses different action types for registration (RegisterAction) and login (LoginAction). After successful registration, we need to initialize all global state (CLIENT, SLIDING_SYNC, room lists, etc.) which is already
implemented in the login flow.

Solution

We reuse LoginBySSOSuccess to handle post-registration initialization:

// After successful registration, trigger the login success flow
Cx::post_action(LoginAction::LoginBySSOSuccess(client));

Why LoginBySSOSuccess instead of LoginByPasswordResult?

Aspect	LoginByPasswordResult	LoginBySSOSuccess
Makes network request	Yes (calls login())	No
Expects authenticated client	No	Yes
Use case	Username/password auth	Pre-authenticated client

Registration already authenticates us—we have a valid client and session. LoginBySSOSuccess simply:

1. Saves the session locally
2. Initializes global state (CLIENT, SLIDING_SYNC, etc.)
3. Navigates to the main app

The name LoginBySSOSuccess is somewhat misleading—it's effectively a "UseAuthenticatedClient" action that works for any pre-authenticated client (SSO, registration, restored session, etc.).

[kevinaboos]

Hi @TigerInYourDream, just wanted to let you know that I did see this PR is ready for review, but it'll probably be a while before I can get to it due to the comparatively low priority of this feature. I do appreciate your work here though!

in the meantime, can you fully prepare it for review by addressing all existing comments (marking the completed ones as resolved, and leaving replies/comments on the ones that aren't resolved yet), as well as fixing the conflicts? thanks.

[TigerInYourDream]

Hi @TigerInYourDream, just wanted to let you know that I did see this PR is ready for review, but it'll probably be a while before I can get to it due to the comparatively low priority of this feature. I do appreciate your work here though!

in the meantime, can you fully prepare it for review by addressing all existing comments (marking the completed ones as resolved, and leaving replies/comments on the ones that aren't resolved yet), as well as fixing the conflicts? thanks.

Hi @kevinaboos,

Thanks for the update I completely understand the priority considerations.

I've just resolved the merge conflicts with the latest main branch. I'll go through all the existing review comments now and:

• Mark the completed ones as resolved
• Add replies to any that need clarification or further discussion

The PR should be fully ready for review whenever you have time. No rush at all - I appreciate you taking the time to review this when you can.